You cannot automate a process you have not written down

Automation does not fix a broken process. It runs the broken process faster, more consistently, and at a volume that makes the breakage obvious to customers before it becomes obvious to you. Before any of it, somebody has to write down what actually happens today. Most businesses have never done that, and it is not a technology problem.

The question under the question

When an owner asks whether AI can answer their phone, the answer is yes and it is not the useful part. The useful question is the one underneath: what happens to a call right now?

Not what is supposed to happen. What happens. Who picks up at four in the afternoon when two people are with clients. Where the message goes. Who is meant to see it. How long they take. What happens when they are on leave and nobody reassigned their inbox.

Almost nobody can answer that at the level of detail an automated system requires, and that is not a criticism. A business runs on a hundred small judgements people make without narrating them. It works because humans improvise. Automation cannot improvise, and asking it to means handing the improvising to something with no judgement at all.

What mapping actually means

Mapping is not a flowchart exercise and it does not need software. It is one document that answers, for a single path through the business, a short list of questions:

• What starts it? A call, a form, a walk-in, a referral.
• Who touches it, in what order, and what does each of them decide?
• Where does it wait? Every queue, inbox and “I’ll get to it later’’ is a place work sits still.
• What has to be true before it moves on?
• Where does it currently fail, and how do you find out?
• What does it cost when it fails?

That last one is the one worth doing first, because it decides whether any of this is worth automating. A path that fails twice a year and costs a coffee is not the path to start with. A path that fails every Saturday and costs a booking is.

You are not documenting the business. You are documenting one path at a time, and the first one should be the one that leaks money.

The seven o’clock call

Take the path most owners mean when they ask about an AI receptionist. Somebody calls at seven in the evening. Write down what happens now.

In most businesses the honest answer is four lines. It rings out. It goes to voicemail. Somebody checks that voicemail in the morning, or does not. If they do, they call back and by then the person has booked with whoever answered first.

Written down like that, three things become obvious that were not obvious when it was a vague feeling of missing calls. There is no owner: nobody is specifically responsible for that voicemail. There is no clock, so nothing says how fast the callback has to happen. And there is no record, so nobody knows how many of those calls there were last month, so nobody can say what the problem is worth.

Notice that none of those three gaps is fixed by buying anything. You could hire a person for that shift and still have no owner, no clock and no record. What the writing-down did was convert a feeling into three specific, cheap decisions. That is the whole of the exercise, and it is why it comes first.

What the machine actually knows

There is a piece of jargon worth taking off people, because underneath it is an idea an owner can use.

When an AI system answers a customer, it is not drawing on some general knowledge of your business. It knows what it was handed at that moment: your hours, your services, your prices, your policy on deposits, who to put through to when somebody is angry. The industry calls assembling that context engineering, and Anthropic’s own definition is “the set of strategies for curating and maintaining the optimal set of… information” the model has in front of it when it answers.

Strip the vocabulary and it is a simple question: what does this thing know, and who decided?

Here is the part that surprises people, and it is the reason this cannot be solved by sending over everything you have. More is not better. Anthropic describes context as “a finite resource with diminishing marginal returns”, and names the failure plainly: “as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.” Tokens is their word for the pieces of text it is holding; the sentence says that the more you give it, the worse it gets at finding any particular thing in the pile. They call it context rot. Hand a system your entire operations manual and it does not become better informed. It becomes less reliable at finding the one line that mattered.

So somebody has to choose. Not everything about the business, and not a thin summary either, but “the smallest possible set of high-signal” facts that let it answer correctly and stop where it should.

That choosing is not a technical task. Nobody outside your business can decide that a deposit is refundable up to forty-eight hours, or that the Saturday shift lead handles complaints rather than the owner, or that you do not quote over the phone for anything structural. Those are the rules you have never written down, and they are exactly what the mapping exercise above produces.

Which is why the order in this article is not a preference. The document you write is the thing the system runs on. Skip it and somebody still writes it — a vendor, guessing, from a template built for a business that is not yours.

Three things, not one

Once the path is written down, most of it turns out not to need artificial intelligence at all, and the split is worth knowing before anyone quotes you.

Gartner’s Anushree Verma puts it in one line: organisations should “start by using AI agents when decisions are needed, automation for routine workflows and AI assistants for simple retrieval.” Three tools, three jobs.

Read against the seven o’clock call, that sorts almost immediately. Routing the call and taking the details is a routine workflow. Looking up whether Tuesday at ten is free is retrieval. Deciding whether an angry caller about a botched job goes to the owner’s mobile tonight or to a queue in the morning is a decision, and it is the only part of that path where the expensive option is the right one.

Get that sorting wrong in the direction everybody gets it wrong, by treating the whole path as one clever agent, and you pay agent prices for retrieval, and you get an unpredictable answer where a fixed rule would have been better. Anthropic’s guidance for people building these things says the same in engineering terms: find “the simplest solution possible, and only increase complexity when needed.”

What this costs, and what it saves

Gartner forecasts that “over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.”

Take it for what it is. A forecast is a considered opinion rather than a measurement, and the poll beneath it covered 3,412 webinar attendees, who are self-selected by definition. It is not a finding about businesses in general.

But look at the three reasons rather than the number. Escalating costs, unclear business value, inadequate risk controls. Every one of those is what it looks like when a project began before anybody wrote down what it was supposed to do. You cannot price work you have not scoped, you cannot show value against a baseline you never measured, and you cannot control risks in a path you never mapped.

Gartner’s own recommendation points the same way: agentic AI should be pursued “only where it delivers clear value or ROI,” and it notes that integrating agents into existing systems “can be technically complex, often disrupting workflows and requiring costly modifications.” In many cases, it says, “rethinking workflows… from the ground up is the ideal path.” Rethinking a workflow requires knowing what the workflow currently is.

Doing it yourself

This is genuinely a thing you can do without us, and you should do at least one before you talk to anybody.

Pick the path that annoys you most. Write the six answers above on one page. Then sit with the version of it that is failing and ask the three questions the seven o’clock call exposed: who owns it, how fast, and how would we know. If you cannot answer those, no software will answer them for you, because they are not software questions.

When the map exists, the shape of the fix is usually obvious and frequently smaller than expected. Sometimes it is a rule and a calendar invite. Sometimes it is an automated receptionist covering the hours nobody staffs. The point is that the map decides, rather than the invoice.

That is also what our audit is: the mapping, done properly, written down, ordered by what each gap costs. Four passes, audit then prioritise then implement then optimise, and the first is not optional, whoever does it.

If the fifteen decisions behind a single answered call are the argument for why the system matters more than the agent, this is the argument for what has to exist before either. Both come back to the same thing: the agent is the visible part, and the visible part was never the work.

Questions people ask