Automate the safest 20% first, then widen

How automation projects die

I’ve sat in the post-mortem for this project more than once. A vendor demos 90% automation. It launches across the whole workflow at once. Week one, an edge case posts something it shouldn’t. By week three, operations has stopped trusting anything the system touched and is re-checking all of it, which means the team now runs the old manual process plus a supervision shift for a robot nobody believes. Within a quarter the project is shelved, and the next automation pitch at that company starts twenty points behind.

The failure wasn’t the technology. It was the rollout: betting the whole process on day-one coverage of cases nobody had enumerated yet.

The staged rollout

The version I run instead is less exciting on a slide and much better by month three:

1. Define explicit automation conditions. Not “the system handles invoices” but “the system handles invoices that match these criteria.” Written down, reviewable, versioned.
2. Automate only what matches. Items that meet the conditions process end to end, touchless.
3. Route everything else to people, unchanged. Not a degraded path, not a new queue to learn: the exact workflow the team already runs. Out-of-scope items never know the automation exists.
4. Instrument every run. Logged, auditable, reviewable. When someone asks “did the system do this?”, the answer takes seconds.
5. Widen by release. Each release adds conditions and captures more volume. The coverage number climbs, visibly.

Start with the lowest-risk segment: clean data, unambiguous rules, small blast radius when wrong. That’s deliberately the easiest 20%, not the most impressive 80%.

Why this works

Trust compounds instead of shattering. Operations watches the automation handle its slice flawlessly while their own work is untouched. By release three, the team that big-bang would have turned into skeptics is asking which conditions are coming next.

Edge cases get learned, not guessed. Every item the conditions reject is information: a real case, in production, with zero damage done. The roadmap for release N+1 writes itself out of the rejects of release N.

Rollback is a config change. A condition misbehaves, you remove that condition. Big-bang rollback is a crisis meeting.

The number is the proof. A coverage percentage that climbs release over release does more for executive confidence than any projection, because executives have seen promised percentages before. A number that moved from 12 to 20 since the last steering meeting lands differently than a forecast.

Running it as an operating rhythm

The playbook only works as a cadence, not a one-time launch:

• Publish the coverage number internally. It belongs in the same weekly ops review as everything else, next to what’s targeted for the following release.
• Review rejects on a schedule, not when someone remembers. The items that didn’t qualify are the backlog. Group them, size them, and promote the next condition set deliberately, with an owner and a date.
• Keep the human path sacred. The moment the manual fallback degrades, you’ve silently converted to big-bang.
• Tie releases to evidence. A condition ships when its segment has been observed, not when the calendar says so.

The receipts

We run this play in production. A fuel carrier’s TMW invoicing had no API and 1,200 invoices a day; release one automated the safest conditions and 200+ invoices a day now process touchless, about 20% of volume, with the team’s workflow for everything else unchanged. Each release widens the conditions, and the number on that page goes up.

Big-bang sounds faster. It isn’t, because you only get one launch and big-bang spends it on your hardest cases. Start with the safest slice, run the cadence, and let the climbing number make the argument for you.

If you have a workflow that deserves this treatment, Agentic AI is the practice behind it.