A distributor with sixty staff members automated its purchase-approval process. Purchases below a certain amount were approved immediately, while those above that amount were sent to a manager. The arrangement was sensible, easy to put into place, and it functioned satisfactorily for five months; in the sixth month, however, a supplier was paid three times for a single delivery since the invoice had first come as a PDF, then as a reminder and then as a statement, and each of these versions was below the threshold.
The finance lead tried to find out who decided that "approved" should mean "matches a purchase order number", rather than "matches a purchase order number and has not already been paid". No one had. The person who set up the software wrote the rule on a Tuesday afternoon, using the vendor's standard template. The tool did precisely what it was instructed to do. The only question worth asking was who had given it the instruction.
The article raises that question and argues that automation is seldom a technology issue; it is a management decision that looks like a technical one, so it gets passed to people who don't have the power to make it. The problem is the disguise.
What Three Decisions Does Every Automation Make for You?
If you remove the software, each form of automation has to make three decisions: governance decisions that occur regardless of whether anyone is aware of them.
What becomes fixed? Once something is automated, it stops being a matter of judgement and becomes a rule. Previously, a person would look at the invoice and decide; afterwards, the system applies a condition. This represents a policy change and should therefore be announced, agreed upon and owned. In most businesses, however, none of this takes place; it is merely a checkbox on a configuration screen.
Who has the power to override? All automated procedures must include an exception route, and each exception route involves a delegation of authority. It is now possible for someone to release a payment, reopen an order or approve a shift outside the rules. Most businesses never decide who that someone is; the answer falls back on the person with the admin login, even though that is usually not the individual the board would have selected.
What occurs when it goes wrong? The failure mode has been designed, whether or not this was intended. Does the system halt and ask a question, record it in the logs, or carry on without saying anything? In most tools, silent failure is the default choice because it is the least annoying when demonstrating the product; however, it is the most costly in a production environment because errors accumulate until they're discovered at the end of the month.
By automating a process, you effectively establish policy, since the tool then becomes the rule.
These three decisions determine the way the business operates when no one is looking; that is about as good a definition of governance as I can give. Nevertheless, a vendor's default settings often result in this situation, whether the person involved is an IT contractor working on a day rate or an enthusiastic operations manager who has never been made aware that setting up a workflow is equivalent to setting a policy.
Why The Decision Ends up in the Wrong Hands
The real reason is that the procedure was never written down.
In a growing business, the way operations actually work lives in people's minds. For example, the operations manager knows which suppliers can be paid late and which ones cannot. In contrast, the office manager knows that any timesheet submitted by the night team always has to be checked over again. This kind of information is not recorded because doing so would have made everyone work more slowly, and for many years it made no difference.
When a business chooses to automate, it turns out that the only people who know the rule are those who have carried it out themselves. This results in one of two scenarios: either the vendor creates the rule by modifying an approach that worked for an earlier client, or the operations manager builds his own habits into the tool, some of which he wouldn't be able to defend if asked. Eventually, when he leaves after eighteen months, the business is left operating under a set of guidelines no one can explain, and no one can remember agreeing to.
That is the reason why I think that the first output of any serious automation should be a document rather than software, specifically, a page which explains what will be fixed, who has the authority to override it and when, and what the system will do in cases of uncertainty. It must be written in plain English, given to the owner to read, and then signed. The software is produced as a result. The real management decision is made when the document is put in writing, and it is the only aspect of the project which the owner cannot delegate.
What a Bad Decision Looks Like in Practice
The financial cost of making the three decisions incorrectly is not technical; it is monetary and comes late.
A case that had once existed is now gone. The person responsible for the care had automated the completion of the routine timesheets. Eighty per cent of the shifts agreed with the rota and were therefore sent directly to payroll, which was the aim. The remaining twenty per cent, those involving swapped shifts, overruns, and coverage by agency staff, were placed into a holding queue to be reviewed at the end of the month. Previously, the payroll clerk had reviewed all the shifts and occasionally spotted the odd ones as she went along. After the automation was introduced, she was left only with the odd ones, out of context, three weeks late, and they were included in a batch of two hundred. The number of overpayments increased. The automation had not eliminated the problem; it had simply removed the warning and delayed the bill. No one had decided what to do about the exceptions. The tool had made that decision for them: to hide them until later.
By month-end, things became more hectic. The retailer had automated receipt of stock and the handling of supplier invoices, but as a result, the month-end close took longer than before. Each adjustment made during the close was a decision that should have been made at the time of delivery but wasn't, such as accepting a quantity without counting it or allowing a price difference to go through because the system failed to stop and ask. The finance team was spending the first week of each month reversing policies the business had never agreed to.
The fact that month-end is busy doesn't mean the finance team is diligent; it reflects decisions left undrafted at higher levels.
In each instance, the software functioned, and in each case the business had automated before forming its own view and had paid for the cash gap.
Why is Automation also a Brand Decision?
A version of that argument remains within the finance department and is incomplete. Customers have never seen your brand guidelines; they have only experienced your process. The order that comes through, the correct invoice, the follow-up action: this is what the brand appears to be like when the customer encounters it. An automated step that fails on the customer end represents a policy the business has enacted unintentionally, and customers will judge it on that policy. Companies that treat automation as mere back-office plumbing aren't investing enough in the one aspect customers can actually observe.
What to do Before Anything is Built
It is not a shortlist of tools; it is a page which the owner writes, or at least reads and signs, prior to any configuration taking place.
What has now been resolved: the judgments that turn into rules, in simple terms.
Who has the authority to override and at what times? Use predefined roles, not individual logins, and define the circumstances in which deviation is permitted.
When the system is uncertain, stop and ask, or continue while flagging, or continue without flagging. You should make your choice consciously, since the default option is to continue without flagging.
Specify the cases in which exceptions are made, at what speed, to whom, with what background information, and within what time frame.
Who is responsible for reviewing the rule, and how often? The business will change, but the rule won't unless someone owns it.
The project isn't ready even if the demo is excellent if the owner can't answer these questions. Still, if they can, most of the remaining work is implementation, and implementation is the easier part.
What Happens When You Remove the Technology From an Automation Project?
If you remove the technology, every automation initiative becomes a discussion about authority: who makes the decisions, who can deviate, and who is informed when it fails. This kind of discussion is unpleasant, which is why it is avoided, and the decision is quietly given to a tool. Yet it encompasses the entire project. Companies that address this issue first end up with systems that mirror their own character, while those that omit it end up with systems that mirror their vendor's.
Where Euryka Stands
That is how our processes and automation work, and it's also why it doesn't start with software.
The process starts with an audit, during which we meet the people who are really in charge of it, those on the floor and those in the finance office, and follow the actual way in which the work moves, noting where it is repeated, where it stops, who remembers it, and the costs associated with mistakes. From this we end up with a workflow map and a quantified opportunity, not a tool recommendation.
We agree on the logic; the three decisions mentioned in this article are decided on in writing either by the owner or by the person who has the relevant authority, specifying thereby what will become fixed, who is permitted to override it and under what conditions, what happens in the event of uncertainty, where exceptions are to be directed and how quickly. No action is taken until that page has been signed. This is the longest stage and delivers the greatest cost savings.
We then build an additional layer on top of the system the business is already using, whether it is an accounts package, a spreadsheet, a rostering tool, or an inbox. Approvals, timesheets, invoice matching, stock receipts, order routing, and follow-ups all follow the standard procedure; any exceptions are immediately detected and displayed together with the relevant context, and an audit trail is maintained at each stage so that both parties can see it. The system records the rules in simple English to keep the policy unchanged even if the individual who first put them in place is no longer employed.
We will continue to use the system and conduct a weekly review of its actions, the items it has flagged, and those that have needed human intervention. Each override should have an individual owner rather than a shared login, and we must revisit the rules as the business changes, since a rule that goes beyond its justification is just a new way of being wrong. The business keeps both the system and the documentation, and we keep questioning whether the decisions still make sense.
Talk to Us
We need you to let us know whether you have already automated a process and are unsure who set the rule, or whether you plan to automate it and want to make that decision yourself. Please provide details of the process and name the person who currently has the rule in their mind, since that is generally where we start.
Sources and Further Reading
The article is based on arguments and does not include any statistical assertions; the cases in question are composite examples taken from our client work and have been anonymised. The following background reading on process and governance as the typical reasons for automation failures:
Harvard Business Review, writing on why automation and transformation projects fail for organisational rather than technical reasons
McKinsey and Deloitte conducted surveys on automation adoption and the role of process documentation and ownership.
Euryka, The Financial Case for Business Resilience (2026), on resilience, exceptions and month-end close.
