Overview

You have 50 workflow steps. You can't automate all of them. You need a scoring framework to answer the question: which steps should get AI first? This lesson teaches you how to evaluate and rank every step in your IT operations.

Purpose

Not all workflow steps are equally ready for AI. Some are obvious candidates (password resets, low complexity, high volume, clear patterns). Others are clearly not ready (approving security policy exceptions, high judgment, low volume, real-world consequences). Most fall in the middle.

Without a systematic framework, you make ad-hoc decisions. "This feels like AI could help." Or you defer to whoever's loudest. You end up deploying AI where it creates marginal value while ignoring opportunities for massive ROI.

This lesson gives you a decision framework: five dimensions, a scoring rubric, and a prioritization matrix. You'll apply this to any IT workflow step and get a defensible answer about whether it's ready for AI and how urgently you should prioritize it.

Why This Matters

Wrong priorities waste money. A CIO once decided to automate firewall rule approval with AI because it seemed "cutting-edge." High visibility project, board-level interest. Six months later, the AI system approved a risky rule that led to a lateral movement attack. Security team lost all trust in AI, and the initiative was shelved.

Meanwhile, the help desk was drowning in 500+ password reset tickets per month, each costing 4 minutes of manual work. That step would have been an easy AI win, obvious patterns, zero security risk, massive ROI. But it wasn't sexy, so it was ignored.

A good scoring framework answers this question before you commit resources: Is this step ready for AI right now? If not, what would make it ready? You prioritize based on readiness + impact, not hype.

Core Concepts

Key insight: Five dimensions determine AI-readiness

Every workflow step exists in five dimensions. Score each dimension 0-10. Steps that score high (7+) on most dimensions are AI-ready now. Steps that score low on some dimensions are candidates for future automation, pending changes.

Dimension 1: Data Availability (0-10)

What's the input data quality and accessibility?

• 
  10: Input data is structured, complete, in a system you control, available via API. Example: "Route this ticket based on category field, which is pre-selected by the user with a dropdown."
• 
  7: Input data is structured and mostly available, but might have gaps. Example: "Route based on ticket description and category, description is free-text (harder to parse), category is structured (easier)."
• 
  5: Input data is partially structured, requires some parsing or enrichment. Example: "Classify alert by alert message text and metric name, both require NLP, not straightforward."
• 
  2: Input data is unstructured, sparse, requires significant transformation. Example: "Determine if this on-call engineer is overloaded based on Slack channel activity, sprint board, and manager intuition."
• 
  0: Input data doesn't exist, would require new data collection. Example: "Make security decisions based on 'organizational context' that no system currently captures."

Dimension 2: Decision Complexity (0-10)

How complex is the decision logic?

• 
  10: Simple rules: IF-THEN, deterministic. Example: "IF ticket category = 'Password Reset' THEN assign to tier-1 help desk."
• 
  7: Rules with conditions: IF (A AND B) OR C THEN X. Example: "IF (error rate >10% AND affected users >100) OR (response time >10s AND duration >5 min) THEN severity = Critical."
• 
  5: Rules that require ranking or scoring multiple factors. Example: "Route based on team capacity (3 factors), expertise match (4 factors), and SLA requirements (2 factors). Score each, pick highest."
• 
  2: Requires contextual judgment or domain knowledge. Example: "Is this change request asking for something that violates our security posture?" (Requires understanding of your security architecture, threat landscape, compliance obligations.)
• 
  0: Requires judgment that changes based on unquantifiable factors. Example: "Is this a creative solution that should be celebrated, or a corner-cut that should be rejected?" (Judgment, organizational culture, leadership values.)

Dimension 3: Risk Tolerance (0-10)

What's the cost of AI error?

• 
  10: Error has minimal impact, easily caught and corrected downstream. Example: "AI misclassifies a ticket, help desk re-routes it in 5 minutes. No real damage."
• 
  7: Error has minor impact, but repeated errors erode trust. Example: "AI misclassifies a ticket, sends to wrong team. Happens once a week. Frustrating, but contained."
• 
  5: Error has moderate impact, requires remediation effort. Example: "AI approves a low-risk change that goes wrong. Requires rollback. 30 minutes downtime."
• 
  2: Error has serious impact, costly to remediate. Example: "AI approves a firewall rule change that opens a vulnerability. Requires security investigation, remediation, incident review. Costs 8+ hours."
• 
  0: Error is unacceptable, could result in major incident, compliance violation, data breach. Example: "AI deletes a VM without approval." This step should not be automated, period.

Dimension 4: Human Judgment Requirements (0-10)

How much human judgment is truly required?

• 
  10: Pure data work, no judgment needed. Example: "Format alert details into a ticket." The AI just transforms data.
• 
  7: Some pattern recognition, but patterns are learnable. Example: "Route ticket based on keywords and category, AI can learn these patterns from feedback."
• 
  5: Judgment is required, but it's learnable judgment. Example: "Is this a real incident or a false positive? Patterns exist, but some cases are genuinely ambiguous."
• 
  2: Judgment requires domain expertise or organizational context. Example: "Should we approve this change? Requires understanding of service criticality, team capacity, and change windows."
• 
  0: Judgment requires wisdom or subjective values. Example: "Is this the right time to make this organizational change?" (Requires understanding of current momentum, team morale, organizational priorities, subjective.)

Dimension 5: Volume and Impact (0-10)

How much does automating this step actually matter?

• 
  10: High volume, high cost. Example: "300 password resets per week × 4 min each = 20 hours of manual work per week."
• 
  7: Medium-high volume or high cost. Example: "50 change requests per week × 1 hour CAB review = 50 hours per week." OR "20 incidents per week × 45 min MTTR = 15 hours impact on business."
• 
  5: Medium volume and cost. Example: "10 onboarding requests per week × 2 hours = 20 hours per week."
• 
  2: Low volume or low cost. Example: "2 firewall rule requests per week × 30 min review = 1.5 hours per week."
• 
  0: Negligible volume or cost, not worth automating. Example: "Once a year, someone needs approval to exceed budget. Not worth building an AI system for."

Key insight: The AI-Readiness Scoring Matrix

Create a table. Score each workflow step on all five dimensions. A step is AI-ready if it scores 7+ on at least 3-4 dimensions, especially Dimensions 1, 2, and 5.

Step
Data Avail.
Complexity
Risk Tolerance
Human Judgment
Volume/Impact
TOTAL
Ready?

Password Reset
10
10
10
10
9
49
YES

Ticket Routing (simple)
9
8
8
7
9
41
YES

Ticket Routing (complex)
5
4
6
4
8
27
NO

Change Approval
7
4
2
2
7
22
NO

Incident Severity Classification
8
7
6
6
8
35
MAYBE

Firewall Rule Approval
6
2
1
1
2
12
NO

Decision rules:

• Score >40: AI-ready now. Deploy with confidence >85%.
• Score 30-40: AI-ready, but with guardrails. Deploy with lower confidence (70-80%) and human review.
• Score 20-30: AI can assist, but humans must decide. Build AI as advisory tool, not autonomous.
• Score <20: Not AI-ready. Keep fully human, or redesign the process first.

Key insight: Common IT processes, scored and analyzed

Here are scores for common IT operations steps:

Password Reset (Score: 49/50)

• Data: 10 (structured, in AD)
• Complexity: 10 (pure if-then rules)
• Risk: 10 (error caught immediately by user)
• Judgment: 10 (no judgment needed)
• Volume: 9 (300+/week, 20 hours)
• Verdict: Automate immediately, 95%+ confidence threshold.

Account Unlock (Score: 47/50)

• Data: 10 (structured, in AD)
• Complexity: 10 (if locked for >N minutes, unlock)
• Risk: 9 (low risk, but check security flags first)
• Judgment: 9 (mostly pattern-based, except security hold cases)
• Volume: 8 (100+/week, 6 hours)
• Verdict: Automate 95% of cases. Escalate if account has security flag.

Ticket Routing (Simple) (Score: 41/50)

• Data: 9 (category, description, priority are structured; team assignments semi-structured)
• Complexity: 8 (learnable patterns: password → tier-1, database performance → DBA team)
• Risk: 8 (wrong route is caught in queue, re-routed in 30 min)
• Judgment: 7 (patterns are learnable, but requires feedback to improve)
• Volume: 9 (1000+ tickets/month, 40+ hours of manual routing)
• Verdict: Automate, confidence threshold 75%. Route ambiguous tickets to triage queue.

Incident Severity Classification (Score: 35/50)

• Data: 8 (metric data available; impact data sometimes missing)
• Complexity: 7 (learnable patterns, but edge cases exist)
• Risk: 6 (mis-severity wastes resources or under-responds)
• Judgment: 6 (patterns are learnable, but some incidents are genuinely ambiguous)
• Volume: 8 (100+ incidents/week, 5+ hours of triage time)
• Verdict: Automate with human review. AI predicts severity, incident commander reviews critical ones.

Change Approval (Score: 22/50)

• Data: 7 (change details available, but risk context often missing)
• Complexity: 4 (requires judgment about risk, dependencies, timing)
• Risk: 2 (wrong approval causes incident, downtime, compliance violation)
• Judgment: 2 (requires deep understanding of service architecture, change history, risk tolerance)
• Volume: 7 (50 changes/week, 50 hours of CAB review)
• Verdict: AI assists (flag risky changes, check completeness), but humans approve. Not ready for autonomous approval.

Firewall Rule Change Approval (Score: 12/50)

• Data: 6 (rule details available, but security context often missing)
• Complexity: 2 (requires security expertise, threat intelligence, policy knowledge)
• Risk: 1 (wrong approval can enable lateral movement, data exfiltration)
• Judgment: 1 (requires security domain expertise)
• Volume: 2 (5-10 requests/week, <2 hours review)
• Verdict: Not AI-ready. Keep human-driven. AI can assist by flagging suspicious patterns.

Capacity Planning (Score: 18/50)

• Data: 5 (usage data available, but predictability varies)
• Complexity: 2 (requires forecasting, trend analysis, business context)
• Risk: 5 (over-provision wastes money; under-provision causes outages)
• Judgment: 2 (requires business context: are we growing? hiring? launching new features?)
• Volume: 3 (quarterly planning, ~40 hours of work)
• Verdict: AI assists by analyzing trends and generating forecasts. Humans incorporate business context and make final decisions.

Backup and Disaster Recovery Testing (Score: 31/50)

• Data: 8 (system configurations available, backup status available)
• Complexity: 6 (requires checking multiple systems, validating recovery procedures)
• Risk: 6 (bad test procedure could corrupt backups or miss coverage)
• Judgment: 5 (which systems to test? how often? requires business continuity knowledge)
• Volume: 5 (monthly/quarterly testing cycles, high planning and execution effort)
• Verdict: AI can schedule tests, generate test plans, validate recovery procedures. Humans review test scope and approve plans.

Compliance Auditing (internal) (Score: 28/50)

• Data: 7 (audit criteria available, but audit evidence often scattered)
• Complexity: 5 (requires checking multiple controls, correlating evidence)
• Risk: 5 (bad audit misses problems, creates false confidence)
• Judgment: 4 (requires understanding of control objectives, risk tolerance)
• Volume: 6 (quarterly audits, 100+ hours of work)
• Verdict: AI can gather evidence, check consistency, flag anomalies. Humans review findings and make judgments about control effectiveness.

Practical Use Cases

Use Case 1: Building a Prioritization Matrix for a Help Desk

You're an IT Service Manager at a 500-person company. You have 10 workflows you want to automate:

Workflows to Consider:
1. Password reset
2. Account unlock
3. Ticket routing to specialist
4. License assignment
5. Software provisioning
6. Onboarding account setup
7. Hardware device registration
8. VPN access request approval
9. Room booking request routing
10. Time-off request approval

You score each workflow:

Workflow
Data
Complexity
Risk
Judgment
Volume
TOTAL
Priority

Password Reset
10
10
10
10
9
49
1 (Deploy Now)

Account Unlock
10
10
9
9
8
46
2 (Deploy Now)

License Assignment
9
9
8
8
8
42
3 (Deploy Soon)

Software Provisioning
8
7
7
7
8
37
4 (Deploy with Guardrails)

Onboarding Setup
8
8
8
7
7
38
5 (Deploy with Review)

Ticket Routing
9
8
8
7
9
41
6 (Deploy Soon)

Hardware Registration
7
8
8
8
6
37
7 (Deploy with Guardrails)

VPN Access Approval
6
4
5
4
5
24
8 (AI Assists)

Room Booking Routing
8
8
9
8
4
37
9 (Deploy with Guardrails)

Time-Off Request Approval
5
3
3
2
5
18
10 (Keep Human)

Deploy order:

1. Phase 1 (Month 1): Password Reset, Account Unlock. High confidence (90%+), high ROI, zero risk.
2. Phase 2 (Month 2): Ticket Routing, License Assignment. Moderate complexity, but learnable from feedback.
3. Phase 3 (Month 3): Onboarding Setup, Software Provisioning. Require guardrails and human review.
4. Future: VPN Approval (AI advisor), skip Time-Off Approval (not worth it).

Results after 3 months:

• Password Reset: 300 tickets/week → 95% auto-resolved. Manual effort: 10 hours/week → 1 hour/week.
• Account Unlock: 100 tickets/week → 98% auto-resolved. Effort: 6 hours/week → 0.5 hours/week.
• Ticket Routing: 1000 tickets/month → 70% auto-routed (simple issues), 30% routed to triage. Effort: 40 hours/week → 20 hours/week.
• Onboarding: 20 employees/month → 90% account provisioning automated, 10% requiring exception handling. Effort: 10 hours/week → 1.5 hours/week.

Total impact: 56 hours/week saved, equivalent to 1.4 FTE. ROI: Implemented in 3 months, pays for itself in month 2.

Use Case 2: Change Approval System, AI Assistant, Not Autonomous

You want to improve change approval velocity. CAB reviews 50 changes per week, taking 2 hours each. That's 100 hours of review time.

You score change approval: 22/50. Not ready for autonomous approval.

Instead, you build AI as an assistant:

Change Approval Workflow (AI-Assisted)

Change submitted
↓
[STEP 1: AI Analysis] (not AI-ready in dimensions 2, 3, 4)
AI gathers context:
- Recent changes to affected services (change history)
- Current incident rate for affected services
- Affected team's change window availability
- Related deployments or maintenance windows

Output: AI risk assessment (not a decision, just context)
Examples:
- "Low risk: Similar change succeeded 15x last year. No incidents on affected services in 30 days."
- "Medium risk: Affected service had 2 incidents in last 30 days (both unrelated). Change window conflicts with deployment from team-b."
- "High risk: No similar changes in history. Affected service is critical path for Q1 launch. Multiple changes planned for this week."

↓
[STEP 2: CAB Reviews] (human decision required)
CAB reviews:
- Change details
- AI risk assessment
- Change history
- Team feedback

Decides: Approve, Approve with conditions, or Reject

Why not fully automated?
- Risk tolerance (dimension 3: score 2) requires human judgment
- Complex judgment (dimension 4: score 2) requires expertise
- Low volume (dimension 5: score 2) means less pressure to automate

↓
[STEP 3: Schedule or Execute]
If approved → schedule in change window
If rejected → return to requester with feedback

[FEEDBACK LOOP: Improve AI]
Capture: What did AI predict? What did CAB decide? What happened?
Learn: If CAB overrode AI risk assessment, understand why
Example: "AI said low risk, CAB said moderate risk. Change went well.
Learn: CAB values caution more than AI. Adjust risk threshold upward."

Impact: CAB still reviews all changes (required by policy). But with AI context upfront:

• CAB meetings are 25% shorter (less time spent gathering context)
• CAB makes better decisions (AI flags patterns humans miss)
• Requester gets faster feedback (AI assessment provided immediately; CAB prioritizes high-risk changes)

Key insight: Not all workflows should be automated. Some should have AI in an advisory role. The scoring framework helps you identify which role (autonomous vs. advisory) is appropriate for each step.

Use Case 3: Incident Severity Classification, Confidence Thresholds

You score incident severity classification: 35/50. It's AI-ready, but with guardrails.

You decide:

• AI confidence >85% → Auto-classify and page team
• AI confidence 70-85% → Classify but require incident commander review before paging
• AI confidence <70% → Flag for incident commander to classify manually

Example decisions:

Alert: Error rate 15%, affected users: 800, duration: 3 min
AI analysis: Error rate is high, users affected, sustained duration
AI confidence: 90%
AI prediction: High severity
Incident commander review? No (confidence >85%)
Action: Auto-page team, create incident ticket, set severity to High

Alert: Error rate 5%, affected users: 50, duration: 20 sec, but service is critical path
AI analysis: Error rate is moderate, few users, but service criticality adds context
AI confidence: 72%
AI prediction: Medium severity
Incident commander review? Yes (confidence 70-85%)
Action: Create incident ticket, set severity to Medium (tentatively), alert incident commander
Incident commander decides: "This is critical path. Escalate to High."

Alert: Database replication lag 500ms, customer-facing query latency +200ms
AI analysis: Unclear if this indicates a real problem or expected variance
AI confidence: 55%
AI prediction: Low severity (uncertain)
Incident commander review? Yes (confidence <70%)
Action: Alert incident commander, let them classify
Incident commander: "This happens on Fridays during backups. Suppress until backup completes."

Tuning over time:

After 4 weeks, you look at data:

• Confidence >85%: AI correct 98% of the time. Keep threshold.
• Confidence 70-85%: AI correct 82% of the time. Good, incident commander catches the 18%.
• Confidence <70%: Too many incidents here. Maybe lower threshold to 65% if you're willing to accept 5% more errors.

Result: Incident classification goes from 100% manual (30 min/day triage) to 70% automated (2 min/day, just monitoring AI), with confidence thresholds matching your risk tolerance.

Anti-Patterns

Anti-Pattern 1: "We'll just score everything as high and deploy it all"

You're excited about AI. You score your workflows and decide they're all "important" and "ready." You deploy AI to 10 processes at once, all with 60% confidence thresholds, because you want "maximum impact."

In production, the AI system makes mistakes across multiple workflows. Some mistakes are caught downstream, others aren't. Your help desk loses trust. "The AI system is broken." You rip it all out.

Why it fails: Too much automation at once means too many opportunities for AI to break something. One bad handoff, one missed edge case, and the whole system loses credibility.

How to avoid it: Start with your highest-scoring workflows (45+/50). Deploy those first. Prove the approach works for 2-4 weeks. *Then* expand to next tier (35-45/50). This builds confidence and catches systemic issues before you scale.

Anti-Pattern 2: "Confidence thresholds don't matter; the AI is the expert"

You deploy incident classification with a 50% confidence threshold because "the AI knows what it's doing." Why wait for human review?

The AI classifies a P4 (low-priority) alert as P1 (critical) and pages the team at 2 AM. False alarm. Then it does this again, twice more in a week. Your on-call team stops responding to pages.

When a real critical incident happens, nobody notices the page because they've stopped trusting the system.

Why it fails: Confidence thresholds exist to match human risk tolerance. A 50% confidence decision is a coin flip. On low-risk decisions, that's fine (ticket routing). On high-risk decisions (incident severity, security approval), it's unacceptable.

How to avoid it: Set confidence thresholds based on the cost of error, not on maximizing automation. Low-risk steps: 60%+. Medium-risk: 80%+. High-risk: 95%+. Document these thresholds and review them monthly.

Anti-Pattern 3: "We scored it once, we're done"

You score your IT workflows in January. You score password reset as 49/50, very ready. You deploy it. Then in March, you change your AD infrastructure. Password reset becomes more complex (now requires checking two AD forests). Your original score is stale.

You still run the AI system at the old confidence level, assuming it's still 49/50 ready. Mistakes increase.

Why it fails: Real IT environments change. Your tools change, your organizational structure changes, your data availability changes. A score that was accurate in January might be wrong in June.

How to avoid it: Re-score workflows quarterly. After major infrastructure changes, re-score immediately. Make re-scoring part of your continuous improvement practice.

Anti-Pattern 4: "We can't score this workflow, it's too complex"

You try to score "change approval" and realize it has dozens of variables: service criticality, team capacity, change window, regulatory compliance, stakeholder impact, etc. Too complex to score. You give up.

By not scoring it, you avoid making a decision about whether AI is appropriate. So you don't deploy anything. And you don't benefit from AI's ability to assist (even if autonomous approval isn't possible).

Why it fails: Complex workflows don't need to be fully automated. They need AI in an advisory role. The scoring framework is still useful. It tells you that this workflow should be "AI assists, human decides," not "AI decides autonomously."

How to avoid it: Score conservatively on complex workflows. If you can't assign a number confidently, go lower (6 instead of 7). Then deploy AI as an assistant, not decision-maker. The assistant role is still valuable. It gives humans context upfront, saves them research time, helps them make better decisions faster.

Anti-Pattern 5: "Scoring is a one-person exercise"

Your IT director scores all the workflows. They decide password reset is 49/50, ready for automation. They decide change approval is 20/50, not ready. They decree it and move on.

Later, the help desk finds out the director doesn't understand their workflow. They know there are 10 edge cases in password reset (disabled accounts, security holds, contractor terminations) that the director didn't mention. The director's 49/50 score is wrong.

Why it fails: The people closest to the workflow have context that leadership doesn't. If you score without their input, you miss important complexity or risk.

How to avoid it: Scoring is a team exercise. Include the people who actually perform the workflow. Include the people who manage the systems. Include the people who care about risk (security, compliance). Let each group score independently, then discuss disagreements. The discussion often surfaces important context.

Human Judgment Checkpoints

Before you deploy AI to an "AI-ready" workflow:

• 
  Confidence threshold review: Have you set thresholds that match the risk level of this step? (Low risk → 60%+, medium → 80%+, high → 95%+)
• 
  Feedback loop review: Can you capture what the AI predicted and what actually happened? If not, you can't improve the system or detect if performance degrades.
• 
  Escalation path review: If the AI makes a mistake, where does the problem go? Is there a human to catch it? Or does it cascade?
• 
  Score validity review: Did you score this with input from people who actually do this work? Or did leadership guess?
• 
  Edge case inventory: For this "simple" workflow, what are the 10+ edge cases that break the pattern? Does your AI system handle them, or escalate?

Key Takeaways

Score workflows before you deploy. Use five dimensions (data, complexity, risk, judgment, volume). A systematic score prevents hype-driven decisions and focuses effort on high-ROI opportunities.

Score conservatively on risk dimensions. If you're unsure whether an error is acceptable, score lower (6 instead of 7). Err on the side of caution. You can always lower thresholds later when you have confidence.

Deploy by priority, not in parallel. Start with your highest-scoring workflows (45+/50). Prove the approach on 2-3 processes, build organizational trust, then expand. Deploying 10 processes at once increases risk and erodes trust.

Set confidence thresholds matched to risk level. Low-risk decisions (ticket routing) can have 60%+ confidence. High-risk decisions (firewall approval) need 95%+. Document thresholds before you deploy.

Use AI in advisory roles for complex workflows. Some workflows (change approval, capacity planning) aren't ready for AI to decide, but AI can assist by providing context upfront. The scoring framework helps you identify the appropriate role: autonomous vs. advisory.

Capture feedback loops. For every AI decision, log what the AI predicted and what the human decided. Use this feedback to improve the AI system over time, or to detect if performance degrades.

Re-score quarterly. Your IT environment changes. Infrastructure changes, organizational changes, tool changes all affect the score. Make re-scoring part of your rhythm.

Involve the people who do the work. Don't score workflows in a conference room without input from the help desk, operations team, or engineers who actually perform the steps. Their context is critical for accurate scoring.