Most automation projects fail before any code is written, because nobody wrote down what the process actually is. Not the version in the process document. The version people are really doing, including the spreadsheet somebody keeps on their own machine and the message they send to a colleague to unblock step four.
Mapping that honestly takes an afternoon. Skipping it costs weeks.
Follow the handoffs, not the steps
Ask a team to describe a process and you get a list of tasks. That list is rarely where the pain is. The pain sits in the gaps between tasks, where work waits for somebody to notice it.
So map handoffs instead. Every point where work changes hands, changes system, or changes format is a handoff. For each one, write down three things:
- Who is waiting, and how do they find out it is their turn
- How long does it typically sit there
- What does somebody retype that already exists somewhere else
Retyping is the loudest signal in the whole exercise. Any data a human copies from one screen to another is data that two systems already hold and cannot pass between themselves. That is almost always the highest value thing to fix first, and the easiest to justify.
Ask what breaks, not what happens
The happy path is the easy part. Automations fall over on the exceptions, so collect them before you design anything.
For each step, ask the person who does it: what is the weirdest version of this you have seen this month? You will hear about the supplier who sends invoices as photographs, the client who replies to the wrong thread, the order that arrives with the quantity in the notes field. Every one of those is a branch your automation will meet in its first week.
You do not have to handle all of them automatically. You do have to decide, for each one, whether it is handled, rejected loudly, or routed to a human. An automation with no answer for an exception does the worst possible thing, which is to process it wrongly and silently.
Decide what happens at 2am
Software fails at inconvenient times. An API is down, a disk is full, a token expired. The question is not whether that happens, it is what the system does when it does.
Two properties are worth insisting on.
Retries have to be safe to repeat. If a step can run twice without doing damage, retrying is free and you can be aggressive about it. If running it twice sends two invoices or charges a card twice, you need a key that identifies the work so the second attempt recognises it as already done. Decide which of those you have for every step that touches the outside world.
Nothing fails quietly. A failure that nobody sees is worse than no automation at all, because the team stops checking. Failures should land somewhere a human looks daily, with enough context to act on.
The lead capture behind the voice agent on this site is a small example of taking that seriously. When a call produces a lead, the record is written to a file that is locked while it is being updated, and the new version is written to a temporary file and then renamed into place. The rename is the trick: it is atomic, so a reader either sees the whole old file or the whole new one, never a half-written file. Two calls finishing at the same moment cannot corrupt each other, and a crash mid-write cannot leave a broken file behind.
That is a lot of care for a small feature. It is also why nobody has to think about it again.
Keep a human on anything you cannot undo
Automate the gathering, the routing, the formatting and the reminding. Be much more careful about automating the deciding, especially where the decision is expensive to reverse.
Sending money, deleting records, cancelling an order, emailing a customer something you cannot retract: these are worth a confirmation step even when the machine is right almost every time. Almost every time is precisely the problem, because the rare wrong case is the one that costs you a client.
A good pattern is to have the automation do all the work and stop just short of the irreversible action, presenting a human with a single decision and everything needed to make it. You still get most of the time saving, and you keep a person accountable for the part that matters. The same principle runs through how we build AI agents: the routine is automatic, the judgment is not.
Some things should stay manual
Not everything deserves automating. Three cases where it is usually a mistake:
- It happens rarely. Something that runs four times a year is not worth a system nobody will remember how to maintain by the third time.
- The rules keep changing. If the logic is genuinely still being figured out, automating it just makes the rules harder to change.
- The manual step is doing hidden quality control. Sometimes the person in the middle is quietly catching problems that nobody has written down. Automate them away and the problems reach your customer instead.
Being able to say what you are deliberately not automating is a sign the mapping was done properly.
Measure the thing you actually cared about
Decide the number before you build, and take a baseline while the process is still manual. Otherwise you will end up comparing a system to a memory.
Pick the measure that matches the complaint. If the complaint was speed, measure how long work sits between handoffs. If it was errors, count the corrections. If it was that a person spends every Friday afternoon on reporting, measure Friday afternoons. Volume processed is a comfortable number to report and usually not the one anybody was upset about.
Then measure again after a month of real use, exceptions included. The honest number is the one that includes the week everything went wrong.
Where to start
Take the process that annoys people most, map its handoffs on one page, mark the three worst waits, and check whether any of them is just data being retyped between two systems. That is usually a small, self-contained first project with a result you can point at.
If you want a hand with the mapping itself, tell us where it hurts and what you have already tried. We do AI automation work that starts here rather than at the tooling, and if the answer is that you do not need automation for this, we would rather say so.
