Quick answer: an automation can only reproduce the process you describe to it. If nobody in the business can describe that process, the automation will faithfully copy the workarounds, the guesswork and the steps that get forgotten. So write the process down first — one page, five questions: what starts it, what happens and who does each step, what goes in and out, what usually goes wrong, and what counts as done. For a typical small-business process this takes one focused sitting, and the document itself often shows you do not need AI at all. When you do, it becomes the test any build has to pass.
Automations copy what is there — including the mess
Whether it is a no-code workflow, an AI agent or a script someone's nephew wrote, an automation follows the instructions it was given. It has no way of knowing that "check the diary" actually means "look at the photo of the paper diary on your phone", or that the Friday person always adds the delivery notes the Monday person forgets.
If your "process" is really one person's memory plus a few private habits, that is what gets encoded. The usual symptoms afterwards: confirmations that go out before anyone has checked availability, exceptions that fall into a void, and a build that works perfectly for the case nobody actually has. Ask an AI assistant to "automate my bookings" and it will confidently build exactly what you described — which is rarely what you meant.
There is a cheaper way to find this out than a failed build. Describe the process in ordinary sentences first. The places where the description gets vague are precisely the places an automation will fail.
The five questions to answer
One page per process. Write it with the people who actually do the work, not from memory, and answer five questions in order:
1. What starts the process? The trigger, named precisely: "a message arrives on WhatsApp or Instagram, at any hour", not "when we get an enquiry". Half of all automation confusion is two people disagreeing about what counts as the start.
2. What happens next, in order, and who does each step? The real sequence, including the unofficial steps — the diary that lives in someone's head, the colleague who double-checks prices. If a step has no named owner, write "nobody", because that is what the automation will inherit.
3. What goes in, and what comes out? Inputs: the information each step needs (dog size, postcode, invoice number). Outputs: what exists at the end that did not exist before (a diary entry, a sent confirmation, an updated spreadsheet row). Automations can only move and transform these; naming them tells you what the tool would actually have to touch.
4. What usually goes wrong? The exceptions, listed honestly: no reply within a day, the requested slot is taken, the customer asks for something outside the normal scope. Exceptions are where automations die quietly, because they are exactly the cases nobody thought to describe.
5. What counts as done? The observable end state: "the appointment is in the shared calendar AND the client has the confirmation". Until both are true, it is not done — and if an automation cannot reach that state while handling your exceptions, it is not finished, whatever the demo showed.
If facing the blank page is the hard part, describe the process out loud to a general-purpose assistant such as ChatGPT or Claude and tidy up the transcript. The assistant is only restructuring what you already know; the facts, and the responsibility for checking them, stay yours.
A worked example (constructed)
Here is the whole document for a fictional one-person mobile dog grooming business, constructed for illustration:
Trigger: a message arrives on WhatsApp or Instagram, at any hour. Steps: (1) reply asking dog size, coat condition and postcode; (2) check the paper diary; (3) propose a slot; (4) on agreement, write it in the diary and send a confirmation with price; (5) the day before, send the address and parking notes. Inputs: breed and size, coat condition, postcode. Exceptions: no reply in 24 hours → one follow-up message, then drop it; slot taken → offer two alternatives; a dog that needs special handling → the owner decides personally and never automates this. Done: the appointment is in the diary AND the confirmation has been sent. Until both are true, the slot is not booked.
Writing this took the fictional owner fifteen minutes, and it immediately exposed a detail that would have broken a naive automation: "checking the diary" meant looking at a photo of the diary on her phone. Any tool built before noticing that would have been built against an imaginary process. It also showed the genuinely repetitive part — step 5, the day-before message — which is a sensible candidate for automation with a person checking each message before it goes.
What the document usually reveals
In practice, the one page leads to one of three outcomes:
- The process is fine; a small, boring fix removes most of the pain. A written price list, a shared calendar instead of a photographed one, one named owner per step. No AI involved — and nothing to maintain.
- One bounded step is genuinely repetitive — the confirmation message, the day-before reminder, the spreadsheet update. That step is a sensible first automation, small enough to test properly, with a person reviewing the output. If you get that far, building your first no-code automation is the natural next read.
- "The process" is really three processes glued together. Split them, document the clearest one, and automate that first — if at all.
The document has a second use people overlook: it is the acceptance test for any build. When a tool claims to have automated the process, you check its output against your five answers — especially the exceptions and the "done" state. You find the gaps in testing, in private, rather than in front of a client.
The honest limitations
Writing a process down does not automate anything by itself, does not make a bad process good, and takes real time — more than fifteen minutes once several people and systems are involved. Documents also decay: if the process changes weekly, or the work is genuinely different every time, leave it unwritten and spend the effort elsewhere. And like any internal document, this one needs an owner who keeps it current, for the same reasons an AI usage policy does. The payoff is narrower but real: decisions stop living in one head, and any tool you later buy is judged against what your business actually does.
Where a second pair of eyes helps
Choosing which of your processes deserve this treatment — and whether AI belongs in the answer at all — is the judgement call. That is what the Business Process & AI Diagnostic is for: a short discovery interview about how the work is done today, up to three named, bounded processes reviewed, and plain-language written findings you keep, with a prioritised list of improvements — including the ordinary process fixes where AI is unnecessary. It costs £349 (399 € in Portugal), one-off, with nothing further to commit to.
Prefer to talk first? Book a free 30-minute call — no preparation needed, and if a diagnostic is not the right fit, we will say so.
Related reading: an AI readiness audit you can do in under an hour, the real cost of AI for a small business and does your small business need an AI usage policy?.
Last updated: 28 October 2026