Automating a broken process just produces broken output faster.
Don’t automate an unstable process, a process only one person understands, anything where a mistake is expensive and hard to detect, or work your customers value precisely because a human does it. Automating a broken process just produces broken output faster.
Unstable processes
If the steps changed last month and will change again next month, automation locks in a snapshot of something that was never settled. You then spend the next year paying to change the automation every time the process moves.
The test is simple: could you write the steps down today and have them still be right in three months? If not, the process is still being invented. Let it finish.
There is a version of this that looks like progress and is not: automating the stable eighty per cent and leaving the volatile twenty to a human. It sounds sensible. In practice the twenty per cent is where all the judgement lives, so you have automated the easy part and left a person doing only the hard part, all day, with no context from the steps the machine now handles invisibly.
Processes nobody has documented
When one person knows how it works and it lives in their head, automating it means encoding one person’s undocumented judgement. What actually gets built is their version of a good day.
This is the most expensive failure on the list, because it looks like success until the edge case arrives. Write it down first — badly, on one page. That hour is the cheapest risk reduction available.
The tell is usually a sentence like "Sharon just knows which ones to hold". Sharon does know. What Sharon has is a rule she has never articulated, built from years of noticing. Automate around her and the rule quietly stops being applied, and nobody can say when it stopped, because it was never written down to begin with.
This is also the case where the documentation is worth more than the automation. Half the businesses we do this with decide not to build anything, because writing the process down was what they actually needed. That is a good outcome and we say so on how an engagement runs.
Where errors are expensive and invisible
Two conditions together, not one. An expensive error you notice immediately is survivable — you catch it and fix it. A cheap error you never notice is survivable too.
The combination is what hurts: a wrong figure that flows into an invoice, gets paid, and surfaces at the end of the quarter. Automation increases both throughput and the time before anyone looks, so it multiplies exactly this failure.
If you cannot describe how you would detect the error, do not automate the step. Build the detection first.
Work customers value because it’s human
Some contact is the product. The call where you talk someone through a bad result. The quote conversation where the real scope emerges. The apology.
Automating these does not save money; it moves the cost to churn, where you will not see it attributed. If a customer would be annoyed to learn a machine did it, that is your answer.
The test is not whether a machine could do it adequately. It usually could. The test is what the interaction is for. If a customer is buying reassurance, competence delivered by software is not the same product, and the gap shows up months later in renewals rather than immediately in complaints.
Low-frequency, high-judgement tasks
Something you do four times a year, differently each time, that needs somebody to think — automation will cost more to build and maintain than the twelve hours a year it saves.
Frequency is what makes automation pay. Judgement is what makes it hard. Low frequency plus high judgement is the worst quadrant, and it is the one people most often ask us to build in.
What to do with these instead
Document, standardise, then reconsider. Most of the list above becomes automatable later, once the underlying process settles — and the documentation is worth having regardless.
For the human-contact work: leave it alone, and automate the admin that surrounds it so the person has more time for the part that matters. That is usually the better trade anyway. Most of what we build is exactly that — the paperwork around the conversation, not the conversation.
If a process clears this page and you are still unsure whether to buy a product or build something, the build-vs-buy framework is the next hour to spend. And if you want the shorter argument, custom vs off-the-shelf gets to the same place faster.
- KNDR·01UnstableLet it settle. Revisit in a quarter.
- KNDR·02UndocumentedOne page, written badly, this week. Then look again.
- KNDR·03Invisible errorsBuild the check before the automation.
- KNDR·04Human-valuedAutomate around it, not through it.
- KNDR·05Rare and judgement-heavyLeave it. The sums do not work.
How to tell which category you’re in
Five questions, honestly answered. This runs in your browser and nothing is sent anywhere.
Answer about one specific process. A "no" here is a useful result — it saves you a build you would have regretted.
- Are the steps the same today as six months ago?
- Could someone else run it from written instructions?
- Would you notice within a day if it produced a wrong result?
- Would customers be fine knowing a machine did this part?
- Does it happen at least weekly?
0 of 5 answered. The result appears once you have answered them all.
If it says don’t, that is the answer we would give you in the meeting too — see <a href="/how-we-work">how an engagement runs</a>.
The questions people actually ask.
01Aren’t you arguing against your own service?
Against the half of it that goes badly, yes. An automation built on an unstable process generates change requests forever and a client who resents the bill. We would rather lose that job at the quoting stage.
02How do we stabilise a process first?
Write it on one page, run it that way for a month, and note every time reality differed. Fix the page, not the people. When the page stops changing, the process is stable enough to automate.
Stop bending.
Start shipping.
Bring the one flow that keeps costing you a Tuesday afternoon. We map it live and tell you what we'd build, what we wouldn't, and what it costs.