We Automated the Easy Work First. We May Have Been Solving the Wrong Problem.
Why the biggest ROI in enterprise AI automation might not be sitting in your service catalogue — it might be sitting in your incident queue
For most of the last decade, enterprise automation has followed a predictable order of operations. Password resets. Access requests. User provisioning. Standard changes. Scheduled reports. The playbook made sense: these tasks are repetitive, deterministic, and well understood, so they were the obvious place to start.
I don’t think that playbook was wrong. I think it was just incomplete.
As I’ve worked with enterprises pushing past their first wave of automation wins, I keep arriving at the same conclusion: the next — and possibly larger — opportunity isn’t in the service catalogue at all. It’s in the incident queue.
Not because incidents are easier to automate. They’re not. But because the economics behind them are far more interesting than most automation business cases account for.
The cost of an incident is never just the cost of the fix
Here’s an ordinary production incident, the kind that happens somewhere in every large enterprise every single day.
An application slows down. A ticket gets raised. The service desk runs initial checks and routes it to the application team. The application team suspects the database. A DBA joins the call. CPU looks fine. Memory looks fine. Connections are high. Eventually, the DBA finds a blocking session holding open transactions, terminates it, and the application recovers.
The fix itself took minutes.
Finding those minutes took the better part of an hour — service desk time, application-team time, DBA time, coordination time, escalation time, ticket handling, and very possibly business-user downtime layered on top.
This is the distinction most automation programs miss:
The biggest automation opportunity usually isn’t the final action. It’s the decision chain that precedes it.
Restarting a service is easy. Knowing whether it should be restarted is the hard part — and that’s precisely the layer where AI starts to change the economics.
From executing tasks to resolving problems
Enterprise automation has quietly evolved through a few distinct generations, and it’s worth naming them plainly:
- Task automation — the instruction is known (“restart this service”). A script handles it.
- Workflow automation — the event and the process are both known (“when X arrives, do these six steps”). Orchestration platforms handle this well.
- Diagnostic automation — the symptom is known, the cause is not (“something is wrong — find out what”). This is where AI starts to matter.
- Resolution automation — the system determines what happened, decides the permitted response, executes it, and confirms recovery.
Most enterprise IT still lives in the first two categories. Incidents overwhelmingly live in the last two — and that gap is exactly where the opportunity sits.
A ticket describes a symptom. It rarely describes an action.
A service request tends to be self-explanatory: install Microsoft Teams. The required action is right there in the sentence.
An incident almost never works that way: Teams is not working.
That’s not an instruction. It’s a symptom. The cause could be authentication, licensing, a corrupted client, network connectivity, endpoint configuration, a service outage, or a stale cached credential — and nothing gets automated safely until the system figures out which one it is.
This is why AI and automation only get powerful together, not separately:
AI determines the next best action. Automation performs it. Governance decides whether it’s allowed. Validation confirms it worked.
Drop any one of those four, and you don’t have autonomous operations — you have a script with extra confidence.
The pattern repeats everywhere — the technology changes, the reasoning doesn’t
What convinced me this is a real architectural pattern — not a database-specific trick or a networking-specific trick — is how consistently it shows up across completely different technology towers.
A database incident (“application response time is high”) sends a DBA through CPU, memory, connections, blocking sessions, and tablespace checks before the actual fix — often a single killed session — even gets attempted. A server alert (“CPU at 98%”) tells you almost nothing on its own; a good operator asks which process, whether it’s transient, whether a deployment just happened, before ever touching a restart. A backup failure on Rubrik, NetBackup, or Commvault follows the same shape regardless of vendor: identify the workload, classify the failure, check prerequisites, match a known remediation, retry, verify. A network complaint like “one branch can’t reach SAP” hides behind DNS, VPN, firewall policy, routing, and identity — and even when AI doesn’t auto-remediate, cutting a 40-minute investigation to three minutes is real value on its own. An identity lockout might be a mistyped password or it might be credential compromise, and the right amount of autonomy depends entirely on which. A cloud latency spike might cross compute, containers, autoscaling, and load balancers before the fix turns out to be one line of config.
Six towers. Six toolsets. Six different engineering teams.
One underlying operating loop: observe, diagnose, decide, act, validate, learn.
That reusable pattern — not the individual connectors — is the strategic asset. Enterprises run hundreds of products; nobody can hand-build bespoke intelligence for each one. But the number of recurring operational patterns underneath all of them is far smaller, and far more tractable.
Why the ROI math looks different here
Most automation business cases run on a simple formula: tickets per month × handling time × labor cost. That math works fine for standard requests.
Incidents don’t fit the same formula, because the cost isn’t contained in a single line item. It’s spread across engineering effort at multiple support levels, escalation and bridge-call time, mean-time-to-diagnose, mean-time-to-resolve, avoided downtime, repeat-incident rates, dependency on scarce specialist skills, and out-of-hours recovery speed.
Ten thousand automated tickets may be worth less than eliminating one recurring failure that quietly consumes hundreds of engineering hours a year.
If your automation program is still measuring success purely in ticket-deflection volume, it’s very possibly under-reporting its own best opportunity.
Not every incident should be autonomous — and pretending otherwise is how these programs fail
I want to be direct about this, because it’s the part vendors tend to skip: incidents are inherently less predictable than requests, and treating all of them as equally automatable is a fast way to lose trust in the whole program.
I find it useful to sort incidents into three honest categories:
Known and repeatable — stopped services, familiar disk-space conditions, backup retries, account lockouts, known connectivity failures. Strong candidates for full autonomous resolution.
Diagnosable and bounded — database degradation, abnormal CPU consumption, application connectivity issues. AI can diagnose and recommend confidently; execution may still need a policy check or a human sign-off.
Novel or high-risk — major multi-system outages, anything unusual or business-critical. Here, AI’s job is to help humans go faster — correlating evidence, building timelines, proposing hypotheses — not to act unsupervised.
Automate the known. Accelerate the diagnosable. Assist the novel.
That’s a far more credible roadmap to autonomous IT operations than “AI will handle your incidents,” and it’s the version that actually survives contact with a real production environment.
Governance isn’t a layer on top of this — it’s the architecture
This is the part that, in my experience, separates a real autonomous-operations capability from an LLM bolted onto some scripts.
Every production remediation needs to be able to answer: what evidence triggered it, what diagnosis was reached, how confident the system was, what automation pattern was selected, whether approval was required, what was executed, what result was expected versus what actually happened, and whether recovery was genuinely validated.
That last point matters more than it sounds. A closed ticket is not the same thing as a correct resolution — the action might have looked successful and caused a different problem an hour later, or a human might have quietly stepped in and fixed what the automation got wrong. A system that’s actually learning needs to retain whether an outcome was validated, not just that a ticket was closed.
The architecture, in other words, isn’t “AI → tool call.” It’s closer to:
Signal → Context → Diagnosis → Intent → Decision → Governance → Execution → Validation → Operational Memory.
Skip the governance and memory layers, and you haven’t built autonomous operations — you’ve built a faster way to take unreviewed actions in production.
The measure that actually matters
For years, automation programs have counted bots, workflows, and tickets deflected. Those numbers are easy to report and not particularly meaningful.
The better question, in my view, is simpler and harder to fake:
How much operational reasoning are we removing from repetitive work?
Picture five incidents landing on a Monday morning — a blocked database session, a failed backup, a stopped Windows service, a locked account, a branch losing packets. Five different tools, five different teams, five different root causes. Underneath all of it, the same loop: observe, diagnose, decide, act, validate, learn.
Once an enterprise starts codifying that loop instead of automating each incident type in isolation, something changes. Automation stops being a pile of disconnected workflows and starts becoming an actual operational capability — one that compounds, rather than one that needs to be rebuilt for every new system you bring online.
Where I’d start, if I were you
Not with every incident. Not with every production action. And certainly not with unrestricted autonomy on day one.
Start with the incidents that are frequent, expensive, well understood, diagnostically bounded, and already have a safe, known remediation pattern behind them. Prove the loop works there — observe, diagnose, decide, act, validate — with a governance trail you’d be comfortable showing an auditor. Then widen the aperture.
And measure the right things while you do it: time to diagnose, engineering hours consumed, number of handoffs, time to recover, repeat-occurrence rate, how often a human still had to step in, and how many resolutions were validated well enough to trust the next time around.
For years the question in this industry has been how many tickets can we automate. I think that question has quietly become obsolete.
The one worth asking now is: how many operational decision chains can we safely compress from hours to minutes — and are we building the governance to trust that compression when it matters most?
That’s not a productivity question anymore. It’s an operating-model question. And for most enterprises, the honest answer is still sitting unopened — inside the incident queue.