Why Small Business Automation Fails
A law firm brings in a contractor to automate client intake. Three weeks later there is something working. New enquiries land in a shared folder, get logged, and trigger an email. Everyone is pleased. The contractor moves on.
Fourteen months later the email provider changes something in an API, and the whole thing stops. Nobody notices for nine days, because nothing announces the failure. When someone finally looks, the automation is a set of connected steps with no notes, no test cases, and no explanation of why any of it works the way it does. The person who built it is unreachable. The firm rebuilds intake by hand and quietly writes off the money.
That story is not unusual. It is close to the default outcome, and none of the reasons for it involve bad code.
Nothing was written down before it was built
The most common failure happens before anyone opens a laptop. Somebody describes the process out loud in a meeting, everyone nods, and the builder starts building from the version they remember.
The trouble is that the spoken version is always the happy path. It leaves out what happens when two enquiries arrive from the same person, when a required field is empty, when a client replies to an automated message with a question, when someone submits the form at 2am on a bank holiday. Those cases are not exotic. They arrive within the first fortnight.
A written specification is not paperwork for its own sake. It is the document where the awkward cases surface early, while they are still cheap to handle. Writing “when a duplicate enquiry is detected, the system does X” costs ten minutes at the specification stage. Discovering the same case in production costs a confused client and an afternoon.
If you take one thing from this piece: no automation should be built from a conversation. It should be built from a document that both sides have read and agreed on.
Nobody owns it after handover
Ask most businesses who owns their automations and you get a pause. The builder is gone. The person who requested it has moved role. The office manager knows how to use it but not how it works.
An automation without an owner is not maintained. It is not monitored, its exceptions are not reviewed, and when a connected system changes its behaviour the failure sits there silently. Ownership does not have to be technical. It means one named person knows the automation exists, knows what normal looks like, and knows who to call when it stops.
It was built around one person’s head
Small business automation often gets built by the most capable person available. Sometimes that is an outside contractor, sometimes it is the operations manager who is good with software, sometimes it is the owner on a weekend.
The build usually works. The problem is that the reasoning behind it never left that person’s head. Why does the follow-up wait two hours instead of going straight out? Why does this branch skip returning clients? Nobody else knows, so nobody else can safely change anything. The automation becomes untouchable, then it becomes an obstacle, then someone rips it out.
It was never tested against real data
There is a large gap between “it worked when I tried it” and “it works”. A builder testing their own work uses clean, well-formed examples, because those are the ones they have in mind.
Real data is not clean. Phone numbers arrive in five formats. People put their full address in the name field. Someone pastes an entire email thread into a message box. Names carry apostrophes and accents that break naive matching. Testing means running the automation against a real sample of your actual historical enquiries, including the ugly ones, and confirming the output is right in each case before it goes anywhere near a live client.
This is also where you decide what should happen when the automation cannot handle something. The correct answer is almost never “carry on regardless”. It is to stop, flag the case, and put it in front of a person. An automation that fails loudly is safe. One that fails silently invents its own version of your process while you are not looking.
No documentation at handover
Handover is often a phone call and a login. Six months later, all that survives is the login.
Useful documentation is short. What this automation does, in plain language. What triggers it. What it touches. What normal looks like, so anyone can tell when it is off. The three most likely failure modes and what to do about each. Who to contact. That is a couple of pages, and it is the difference between a nine day outage and a fifteen minute fix.
What rigor actually looks like
None of this is complicated, and none of it is expensive relative to rebuilding. Specify it in writing before building. Test it against real data before shipping. Document it before handover. Name an owner. Make failures visible.
That is how systems are built in fields where a quiet failure is unacceptable, and there is no good reason your client intake should be held to a looser standard than the software running your accounting. The reason most automation work in this market is not built this way is simply that nobody insists on it. It is fair to insist on it.
If you have an automation running that nobody can currently explain, that is worth a conversation. You can book a free 30 minute call at https://calendly.com/brad-bravoautomate/30min.