Automation has become one of the most talked-about levers in IT service management. Every tool demo promises it. Every roadmap includes it. Every improvement initiative seems to end with, “and then we’ll automate it.”
But here’s the uncomfortable truth:
Automation doesn’t fix broken processes. It accelerates them.
I’ve seen organizations automate chaos at scale; faster ticket misrouting, faster rework loops, faster escalation noise, all while proudly declaring progress because the tool is “doing more.”
The problem isn’t automation.
The problem is what we automate, and when.
How do I know a process is ready for automation?
A process is usually ready for automation when it is already working reasonably well without automation. That may sound obvious, but it is often skipped. If a process is inconsistent, relies on tribal knowledge, has too many exceptions, or requires people to regularly work around it, automating it often just locks those issues in place. I tend to look for a few simple signs. Is the work repeatable? Are the steps understood? Is there enough consistency in inputs and outcomes that a workflow can actually make decisions? Is there clear ownership for the process? If no one owns the process today, automation will not fix that. In many cases, the best first step is not automation at all, it is simplifying the work. Remove unnecessary steps, clarify decisions, reduce variation, and then ask whether automation can support the process. Automation tends to work best when it supports a stable practice, not when it is expected to create one.
What should we automate first, and what should we avoid automating?
I generally start with low-risk, repeatable tasks that create friction but do not require heavy judgment. Routing, notifications, approvals based on clear rules, common request fulfillment steps, and repetitive handoffs are often good places to begin. These are usually areas where automation reduces cognitive load and gives people time back. I would be much more cautious automating work that depends on interpretation, exception handling, or business context that shifts often. Problem analysis, nuanced prioritization, or anything involving customer empathy usually deserves a human in the loop. A simple question I often ask is whether the automation is removing waste or removing thinking. Those are very different things. Removing waste is usually good. Removing necessary thinking can be risky. Start where automation can make the work easier and more consistent, not where it tries to replace judgment.
How do you measure whether automation improved outcomes instead of just efficiency?
I would not start by asking whether automation made something faster. I would ask whether it made service better. Faster is only one part of the story.
Did it reduce rework?
Did it improve consistency?
Did it reduce handoffs or ticket bouncing?
Are customers getting what they need with less effort?
Are teams spending less time on repetitive activity and more time on work that requires attention?
Those are better questions. Efficiency metrics matter, but they can mislead if taken alone. You can automate something and lower handling time while making the experience worse. I have seen that happen. Good automation should improve outcomes, not just numbers. In many cases the best measures are a blend of operational metrics, quality indicators, and feedback from the people doing and receiving the work. If the process is faster but more confusing, you have not really improved it. You have just accelerated it.
I’m curious:
Where has automation genuinely improved outcomes in your ITSM practice, not just speed or volume, but clarity, quality, or experience?
That’s the conversation worth having.