How to automate your business with AI - the actual process

Most writing about business automation is about tools - which platform, which model, which vendor. Tools are the easy part. What actually decides whether an automation project works is the order of operations, and that part rarely gets written down.

This is the sequence I use. It's not secret and it's not magic - you could run it with any competent builder, or partly on your own. Each step exists because skipping it produces a specific, predictable failure.

Step 1: Map the workflow as it actually runs

Not as it's documented - as it's lived. Sit with the people doing the work. Get into the CRM, the ERP, the shared inbox. Write down the exceptions, the workarounds, the judgment calls that exist only in someone's head. The documented process is never the real process, and every later step builds on what this one finds.

While you're there, capture the numbers: how many cases a week, how long each takes, where the pile-ups happen. That's your baseline - without it, "did this work?" has no answer later.

Skip it and: you automate the clean version of the process, your team meets the real version daily, and within months a shadow process is running next to your automation.

Step 2: Triage - decide what deserves automation at all

With the real map in hand, sort every step: rules go to plain code, genuine judgment calls are model candidates, and some things stay manual or stay untouched - too risky, too little volume, or already working fine. Rank what's left by volume times pain. The output is two lists: what gets built, in what order, and what gets left alone, with reasons.

Skip it and: you build the exciting use case instead of the valuable one, and put a model on steps a cron job handles better.

Step 3: Design the split

For each workflow that made the cut, decide the architecture in plain language before any code: which steps run as deterministic software, where the model acts, where a person approves, and where the result lands. Two defaults are worth stealing: a human gate in front of anything irreversible, and results written into the systems you already run - the automation should end in your CRM, not in a new tab.

The typical healthy shape: mostly ordinary software, a model at two or three judgment points, a person at one gate.

Skip it and: the model becomes the whole system, and you inherit its every mood at every step.

Step 4: Build for the exceptions, prove with evals

The build itself: structured outputs with validation, the exception list from step 1 handled case by case, retries where safe, routing to a person where not. Then the proof - an evaluation suite built from your historical cases, with failures attributed to causes, not just counted. This is also where the audit trail goes in: every decision the system makes, inspectable later.

Skip it and: you get the systems that pass demo and quietly break three weeks in.

Step 5: Roll out in stages

No switch-flipping. Shadow mode first: the system does the work in parallel while its output goes nowhere, and you compare it with reality. Then assisted mode - drafts a person approves. Then autonomy for the case types that earned it, with everything else still routed to people. Each stage generates the evidence that justifies the next.

Skip it and: the failure modes get discovered in production, with live customers, and one visible early mistake costs the team's trust in the whole project.

Step 6: Measure against the baseline

Back to the numbers from step 1. Results land in three buckets: time and cost (hours the team stopped spending), risk (error rates, missed cases, things caught before they went out), and revenue (leads answered in minutes instead of days, capacity that turned into throughput). Every claimed result should land in one of the three, measured against the baseline. If it doesn't fit any bucket, it's an anecdote.

Skip it and: six months later the automation is "probably helping" and nobody can defend its running costs.

Step 7: Loop

Here's the part that surprises people: the second automation is cheaper and more obvious than the first.

Fix one bottleneck and the constraint moves - the next slow step is suddenly visible, often measurably, because the process around it sped up. And the next build reuses what the first one paid for: the integrations already exist, the eval infrastructure is standing, the team already trusts the rollout pattern. Companies rarely automate one workflow. They automate one workflow, see the numbers, and then work down the list the first project revealed - each round faster than the last.

So the honest framing isn't "an automation project." It's a capability you install once and then run: map, triage, build, prove, stage, measure, repeat.

That's the whole process. Nothing in it requires believing any hype - each step is just the thing that prevents the failure the step after it would otherwise hit. It's also, not coincidentally, what the people with the fancy new job title actually do all day.

You can run this yourself, and some companies do. If you'd rather run it with someone who has the scars already - the mapping, the build, the rollout, or the whole loop - that's what I'm for. Start by telling me which workflow hurts most.