Ninety days to roll out AI automation in a company that has never done it
Not a strategy deck. A sequence: find the work, ship one thing that matters, build the platform underneath it, then let other people build. What goes wrong at each stage and how to tell if it is working.
Most AI automation programmes fail in one of two ways. Either they start with a platform decision and spend two months choosing a tool before automating anything, or they start with forty enthusiastic pilots and end with forty unowned workflows in somebody's personal account.
The sequence below avoids both. It assumes a company of fifty to five hundred people with no existing automation practice.
Days 1 to 15: find the work, honestly
Do not run an ideas workshop. You will get a list of things people find annoying, which correlates weakly with things worth automating.
Instead, count. For each candidate process: how many times a month does it happen, how many minutes does it take, how many people do it, what does a mistake cost, and does the input arrive in a structured form. Volume times duration is your saving; input structure is your feasibility; error cost is your risk tier.
The candidates that win are almost always high-volume, low-judgement, structured-input work at the seams between systems — where a human reads from one screen and types into another. The candidates that lose, despite being the ones people nominate, are the low-volume processes that are painful because they are rare and therefore require thought each time.
Pick one. One, not three. Document the current process precisely enough that you could measure it — that document is also your acceptance criterion, and writing it usually surfaces that nobody agreed on what the process actually is.
Days 16 to 45: ship it end to end
Build the chosen automation completely, including the parts that are not fun: the error path, the exception queue, the human approval placement, the run log, the alert.
Run it in shadow mode first — it processes real inputs, produces real outputs, and a human does the work as usual. Compare for a week. This tells you the real accuracy before anything depends on it, and it produces your first evaluation set for free.
Then go live with the exception queue wide open: escalate anything the automation is not confident about, even if that is half the volume. Tighten the threshold with evidence over the following weeks. Going live conservatively and tightening beats going live optimistically and firefighting, and it costs about two weeks of partial savings.
Resist the pull to build a platform this month. One automation in a slightly-wrong tool teaches you more about your requirements than any evaluation matrix.
Days 46 to 70: build the thin platform
Now you know what you need. Build only the shared pieces the second automation would otherwise duplicate:
A place to run things with queue-mode reliability. A credentials store, not credentials in workflow configuration. The run log table and one dashboard. A prompt repository with versions. A dead letter queue and a replay script. An alerting channel with a named owner.
Notice what is not on the list: a governance board, a catalogue, a chargeback model. Those become necessary at forty automations and are pure overhead at two.
Make the platform decision here, with a real workload to test against — n8n, Make or Zapier is decided by volume, data residency and whether you have engineers, and you now know all three.
Days 71 to 90: let other people build, with rails
The programme only pays off if it stops depending on the person who started it. Three things make that safe:
A tiering rule. Low-risk automations — internal, reversible, no customer data — anyone can build. Medium — touches customer data or external communication — needs a review. High — moves money, changes production, sends on behalf of the company — needs an owner and a design review. Write the three tiers on one page.
A template. A starter workflow with the error route, the logging and the alert already wired, so the boring parts are the default rather than an act of discipline.
An owner per automation, named, in a list. The single highest-value artefact of the whole quarter. An unowned automation becomes an outage with no one to call, and it takes about eight months.
How to tell it is working
At day 90 you should have: one automation in production with measured accuracy and a real saving you can state in hours, a second one built by somebody other than the original team, a run log you can query, and a list of owners. You should not have: twenty pilots, a platform nobody has put load on, or a slide about transformation.
What to do this week
Do the counting exercise for five processes. Volume, minutes, people, error cost, input structure. It takes an afternoon of conversations and it will contradict at least one thing everyone assumed about where the time goes.