An audit that has never returned no is not an audit. The refusal rule is the gate that lets an engagement end before the build, and why it must exist.
Contents6 sections
The structural problem with every automation audit
The party running the diagnostic is the party who gets paid to build whatever the diagnostic finds.
This is not a scandal, it is just the shape of the industry, and everybody in it knows the shape. It is also why a free audit is priced the way it is: it is a sales meeting with a deliverable attached, and its conclusion is known before it starts.
The only correction that actually works is a stated condition under which the answer is no, decided in advance and checkable afterwards.
The rule
A workflow gets built only after a written ROI estimate, signed by the operator, clears positive at conservative inputs.
If it does not clear, the reasons are written up and the engagement ends.
That is the entire rule. Its value is not in its sophistication. It is in being said out loud before the numbers are known.
What conservative means, specifically
Three choices, all made before anyone sees the answer.
- Volume from a low month. A return that only works at peak throughput is a return that vanishes in January.
- Labour at loaded cost. What the hour costs the business to provide, not what appears on the payslip.
- Build cost at the top of its range, including the tuning that always follows go-live rather than the figure that would hold if nothing went wrong.
None of these is clever. Together they are the difference between an estimate that survives the finance function and one that was written to be approved.
What the client gets when the answer is no
Everything produced so far: the map, the signed baseline, the priority matrix, and the written reasoning.
That last document is the one operators actually use. It names the candidates considered, what each would have cost, and what would have to change for the answer to become yes - a volume threshold crossed, a data-quality problem fixed, a system replaced first. It is frequently used internally to stop a project somebody else was pushing.
Which is a better outcome than a build that never pays for itself, at a small fraction of the price. The reasoning behind pricing an audit this way is in how to read an automation quote.
What breaks without the rule
Every audit returns yes.
Not because anyone lied, but because a process with no stopping condition does not stop. The candidates get generous volume assumptions. The build estimate is the good case. The payback lands just inside the acceptable window. And the client, who cannot check any of it, approves.
Then the automation ships, works, and is abandoned in month eight when its sponsor changes role - and the conclusion the client draws is not that this project was mis-scoped. It is that automation does not work for companies like theirs. The pattern is common enough to have its own literature, some of it in why your last chatbot failed.
Where it sits
The refusal rule belongs to Cut, the fourth of six stages, and it depends on everything before it being real: a measured baseline, an honest map, a scope that stopped moving. The other half of Cut - what gets deleted and in what order the rest ships - is in choosing what ships first. The arithmetic itself is in ROI math for automation projects.
Frequently Asked Questions
Why would a consultancy build a rule that costs it work?
Because the alternative costs more, later and less visibly. An automation that should not have been built does not fail quickly. It ships, it works, it is used for a few months, and then it is quietly abandoned when the person who championed it changes role, and the client concludes that automation does not work for them. That client does not come back, does not refer anyone, and tells the story at conferences. The refusal rule trades a build now for the ability to be believed later, and it is only credible if it has actually fired - which is why the reasons get written up rather than delivered verbally and forgotten.
What counts as conservative inputs?
Three specific choices, made before the answer is known. Volume comes from a low month rather than a good one, because a return that only works at peak throughput is a return that disappears in January. Labour is priced at loaded cost, which is what the hour costs the business to provide rather than what appears on a payslip. And the build is estimated at the top of its range including the tuning that always follows go-live, not at the number that would be true if nothing went wrong. Each of these on its own is unremarkable. Together they are the difference between an estimate that survives contact with the finance function and one that was written to be approved.
What does the client actually get when the answer is no?
Every artefact produced up to that point: the process map, the signed baseline, the priority matrix, and the written reasoning for the refusal. That last document is the valuable one, because it says which candidates were considered, what each would have cost, and what would have to change for the answer to become yes - a volume threshold, a data-quality fix, a system that has to be replaced first. Operators use it to decide what to do next, and often to argue internally against a project somebody else was pushing. It is a better outcome than a build that does not pay for itself, and it costs a fraction as much.
Does the rule not just move the bias earlier, into the estimate?
It would, if the estimate were the vendor's alone. That is what the operator signature is for: the inputs to the arithmetic - the volumes, the hourly cost, what counts as time actually saved rather than time redistributed - are agreed with the client before the calculation runs, not presented afterwards as a conclusion. The vendor still owns the build estimate, and that side does carry an incentive, which is why it is stated at the top of its range. None of this makes the process bias-free. It makes the bias visible and located, which is the most anyone can honestly offer.
