Before you automate anything, ask what a mistake costs

A client recently wanted to fully automate customer refunds. Request comes in, system checks the rules, money goes out. Sounds great. Then I asked what happens if it refunds the wrong amount to the wrong person. Long pause. That pause is the whole point of this article.

I now ask that question before every project, well before we talk about tools or hours saved. The saved time is the reward. The cost of a mistake is the risk. An automation that ignores the risk will save you a few hours a week and eventually cost you a customer or an awkward call from your accountant.

Hours saved tell you nothing about risk

Most automation requests arrive sorted by time. "This eats five hours a week." Fair, but it is the wrong sort order. Two tasks can each cost five hours and carry wildly different risk.

Task one: someone copies order data from an email into a spreadsheet every week. If the automation slips, a number lands in the wrong cell. Annoying, fixed in two minutes.

Task two: a system sends payment reminders to overdue customers. If that slips, a loyal customer gets a dunning notice for an invoice they paid weeks ago. That does not cost two minutes. It costs trust, and you cannot reset trust with a button.

Same time saved, completely different exposure. So I do not rank work by effort. I rank it by one question: how expensive is it when the automation gets it wrong?

Two axes decide how far to go

I use two simple axes: how reversible a mistake is, and how far it reaches.

Reversible? A misfiled document is reversible. A sent email, a triggered payment, a deleted record is not.

Reach? Does the mistake stay inside your team, or does it land on a customer, your accountant, your bank? The further out it travels, the more the cleanup costs.

That gives you roughly three tiers.

Low risk, reversible, internal: automate it fully, no hesitation. Sorting data, building reports, internal notifications. If it breaks, nobody outside the team notices.

Medium risk: let the automation do all the prep and keep the final step visible. A quote gets built end to end, and a salesperson releases it with one click. The work is done, the control stays.

High risk, irreversible, outward-facing: I deliberately put a person back in. Not because the tech cannot do it, but because the mistake is too expensive. Paying out money, cancelling contracts, deleting customer data. I automate these right up to the last second and let a human pull the trigger.

Does a human at the end defeat the purpose?

This is the pushback I hear most. If a person still clicks at the end, was the automation pointless? Not even close.

Without it, the employee gathers data, checks conditions, calculates, writes, types. With it, all of that is prepared and they make one decision: yes or no. Thirty minutes of busywork becomes ten seconds of judgment. You automated the work, not the responsibility.

For the refund client, that is exactly what we built. The system checks the rules, proposes an amount, drops everything into an approval queue. Each morning a person sees thirty cases, 28 of them obviously fine, and clears them in two minutes. The two odd ones get a closer look. Those two are exactly what a fully automated flow would have waved through.

This scales from solo to enterprise

Size only changes the scale, not the principle. A solo consultant automating her appointment confirmations uses the same grid as a corporation running three hundred workflows. For the consultant, the expensive spot is the invoice that goes to the client. For one larger client, it was recently a workflow writing supplier master data straight into SAP. Reversible? Barely. Reach? Into the accounting of three subsidiaries. So we put that final step on approval too, enterprise IT department and internal sign-offs and all.

The practical test takes two minutes. Write down the step that happens at the very end of the automation. Ask whether you could undo it within five minutes, and who notices if you cannot. Two checkmarks, automate it fully. A question mark anywhere, put a human in the middle.

The uncomfortable part

Sometimes this means we deliberately do not fully automate the most expensive process. That feels backwards. It is not. The process with the highest failure cost is rarely the one where full automation pays off most. It is the one where a mistake hurts most.

Good automation is not about removing people everywhere. It is about leaving them exactly where their judgment is worth more than their time. So before you score your next project by hours saved, ask the other question first: what does it cost when it is wrong? The answer tells you not just whether to automate, but how far.