AI and automation get pitched as a blanket cost-cutting tool. In practice, they reduce cost reliably in a narrow set of situations and disappoint almost everywhere else. The difference usually comes down to how the candidate process was chosen, not the sophistication of the model.
What makes a good automation candidate
Before evaluating any specific tool or model, it helps to score the process itself against a few structural traits. Processes that score well on most of these are worth pursuing; processes that score poorly rarely pay off, regardless of how good the underlying AI is.
- Volume: does it happen often enough that improving it matters?
- Repetition: is the work structurally similar each time, or does every instance require fresh judgment?
- Decision rules: can the decision be described as a rule set, even a messy one, or does it depend on tacit expertise?
- Data quality: is the input data complete, consistent, and available where the process needs it?
- Exception rate: how often does the process hit a case that needs a human anyway?
- Risk: what happens when the process gets it wrong, and how expensive is that mistake?
Baseline before you automate
It's difficult to prove savings if you don't know your starting point. Before building anything, capture the current cost, time, and error rate for the process as it exists today—including the manual rework and exception-handling time that rarely shows up in a process diagram.
This baseline becomes the yardstick for the pilot. Without it, teams tend to declare success based on how the new system feels to use, not on whether it actually reduced cost or defects.
Keep a human in the loop where it matters
Full automation isn't always the goal, and treating it as the goal is a common source of failed projects. For processes with real consequences for getting it wrong, a better target is often augmentation: the system handles the routine cases and routes anything ambiguous, high-risk, or low-confidence to a person.
Designing that handoff well—clear confidence thresholds, a usable review interface, a way to feed corrections back into the system—usually matters more to the outcome than the underlying model choice.
Choosing a pilot and measuring benefit
Pick a pilot that is narrow enough to ship quickly but large enough to matter if it works. Define the success measure before you start—cost per transaction, cycle time, error rate, or a combination—and measure it against the baseline you already captured.
A pilot that can't show a measurable before/after isn't ready to scale, no matter how promising it looks in a demo.
Why automation projects fail
Most failures trace back to one of a small number of root causes:
- The process was chosen because it was interesting to automate, not because it scored well on volume, repetition, and data quality.
- There was no baseline, so nobody could tell whether the new system actually improved anything.
- The exception rate was higher than expected, and the fallback path to a human was never designed.
- The team optimized for full automation instead of a workable human-in-the-loop design.
- The pilot never had a clear owner accountable for the outcome after launch.
| Quick wins — high value, manageable risk | Strategic bets — high value, higher risk; plan carefully |
| Low priority — limited value, low risk | Reconsider — limited value, high risk |
Vertical axis: business value (low at bottom, high at top)
Key takeaways
- Score candidate processes on volume, repetition, decision rules, data quality, exception rate, and risk before picking a pilot.
- Capture a real baseline (cost, time, error rate) before you build anything.
- Design the human-in-the-loop path deliberately; don't treat it as an afterthought.
- A pilot without a measurable before/after isn't ready to scale.
Want to talk through how this applies to your organization?
Assess an automation opportunity