You Cannot Automate a Process That Only Exists in Someone’s Head
Most small businesses that fail at automation did not choose the wrong tool. They tried to automate a process that had never been written down — and you cannot connect a system to something that only exists in somebody’s memory.
There is a conversation we have often enough that we can now predict how it goes. A business owner has read that automation will save their team days a month. They are right. They ask us to automate their quoting process, or their onboarding, or the thing that happens when an order comes in.
So we ask the obvious question: how does that process work at the moment?
And the answer, almost always, is some version of: well, it depends. It depends who is doing it. It depends how busy they are. Marta does it one way, and when Marta is on holiday it does not really happen. The information is in an email somewhere, or a WhatsApp message, or a notebook, or in the head of the person who has been there longest.
That is not a failure of management. It is what happens naturally when a business grows by doing rather than by planning. But it does mean that the automation project being discussed cannot start yet — and understanding why saves a lot of money.
Automation is a connector, not a creator
An automation moves information between systems and acts on rules. That is genuinely all it does, however clever the AI on top of it is. Which means it needs two things that many small businesses do not yet have:
- Information that exists somewhere a machine can read. Not in a conversation, not in an inbox thread, not in somebody’s judgement.
- A rule that holds most of the time. Not a rigid one — good automations handle exceptions — but a default that is actually the default.
If a process fails both tests, automating it does not produce a faster process. It produces a fast, confident, automated version of the confusion you already had. That is measurably worse than doing nothing, because now the confusion runs at scale and nobody is watching it.
A bad process automated is not an improved process. It is the same mistake, made faster and with more conviction.
The four states a process can be in
It helps to be honest about where each of your processes actually sits. In our experience they fall into four states, and only the last one is ready.
State one: it lives in a person
Nothing is written down. The process runs because a specific human knows how it goes. It works — until that person is ill, busy, or leaves. Ask yourself: if this person were unavailable for two weeks, what would break?
State two: it is written down, but nowhere useful
There is a document. It is in someone’s Drive, it was accurate eighteen months ago, and nobody has opened it since the induction it was written for. This is better than state one, because at least the knowledge survives a resignation. It is still invisible to software.
State three: it is in systems, but the systems are strangers
The information is genuinely digital — it is in the CRM, the accounting package, the shared spreadsheet, the email inbox. But those tools have no relationship with one another, so a person is the integration. This is where most growing businesses actually are, and it is the state that feels most like being nearly ready while still not being ready.
State four: it is digital, structured and connected
Information lands in a defined place, in a consistent shape, and the rules for what happens next can be stated in a sentence. Now automation has something to grip.
Pick your most painful process. Try to write it as a numbered list of steps, where each step says who does it, what information they need, where that information lives, and what they do with it. If you cannot finish the list without writing “it depends” more than twice, you are in state one or two.
The step before automating, and it is smaller than it sounds
The word “digitisation” makes people think of expensive software projects. In practice, for a small business, the step before automating usually looks like four unglamorous pieces of work.
- Write the process down as it actually happens. Not as it is supposed to happen. Follow one real case from start to finish and record every step, including the annoying ones where somebody has to ask a colleague something. This alone often exposes the real bottleneck.
- Decide where each piece of information is going to live. One place per thing. If customer details live in the CRM, they live in the CRM — not in the CRM and also in a spreadsheet that Javier maintains. This is the step people skip, and it is the one that determines whether automation is possible later.
- Make the inputs structured. A form instead of an email. A dropdown instead of a free-text field. This feels like bureaucracy and is actually the single highest-leverage change, because structured input is the raw material every automation needs.
- Run it manually, on purpose, for a few weeks. Follow your own written process by hand. You will find the exceptions you forgot, and you will find them while they are cheap to fix rather than after they are encoded into software.
None of that requires buying anything significant. Most of it can be done with tools a business already pays for. What it requires is somebody deciding it matters enough to spend a few days on.
What this buys you, even if you never automate
Here is the part that makes this worth doing regardless. A business whose processes are written down and structured is a better business immediately, for reasons that have nothing to do with software:
- New people become useful in days rather than months.
- Holidays and illness stop being operational risks.
- Quality stops depending on who happened to pick the job up.
- You can finally see where time goes, which is usually a surprise.
- The business becomes sellable, because it is no longer a group of people improvising.
Automation then becomes an optimisation of something that already works, rather than a rescue attempt for something that does not. That is a much better project to be paying for.
How to tell you are actually ready
You are ready to automate a process when you can answer these five questions without hesitating:
- What triggers this process? A specific, observable event.
- Where does the information arrive, and in what shape?
- What are the steps, in order, and what decides between them?
- Which systems hold the data at each point?
- What should happen when something goes wrong?
If you can answer all five, an automation can be built and it will hold. If you cannot answer question two or four, the work in front of you is digitisation, not automation — and anyone who tells you otherwise is selling you something that will not survive first contact with your business.
Start with the smallest painful thing
The temptation is to fix the biggest, most broken process first. It is usually the wrong choice, because it is the biggest and most broken for a reason: it is complicated, political, and touches everything.
Pick instead the smallest process that genuinely annoys somebody every week. Write it down. Structure its inputs. Run it manually. Then automate it. You will learn how your business responds to this kind of change while the stakes are low, and you will have a working example to point at when you propose the larger one.
The question is not “which tool should we use?” It is “could a competent stranger run this process tomorrow using only what is written down?” Until the answer is yes, no tool will help — and once the answer is yes, the tool matters far less than you would think.
We would rather tell a business this at the start than three weeks into a build that was never going to work. If you are not sure which state your processes are in, that is exactly the kind of thing a short conversation sorts out.
Not sure whether you are ready to automate?
Book a free 30-minute conversation. We will look at how your business runs and tell you honestly whether the next step is automation or the thing that comes before it.