The process a client describes to you is the process as it was designed. The process their team runs is the one that survived contact with Tuesday. They are rarely the same, and an automation built from the first will quietly fail the second.

This is not anyone's fault. The owner describes the work as they believe it happens. The manager describes it as it is supposed to happen. Neither is lying. Both are a few steps removed from the person who opens the spreadsheet, spots that the customer reference is wrong, rings someone, fixes it and moves on without writing any of that down. That fix is part of the process. It is also the part an automation will not have.

Where the gap comes from

Most of what makes a process work is invisible to the people who own it. The experienced member of staff who knows that one supplier always sends the file late. The workaround for the system that cannot handle a part payment. The unwritten rule that anything over a certain value goes past the owner first. Each one is a decision, made by a person, dozens of times a month, and each one is absent from the diagram on the wall.

The more capable the person, the more of the process lives in their head. Which means the people you most need to talk to are the ones whose work looks effortless, and the ones least likely to be asked.

What automation does with a gap

An automation does exactly what it was told. That is its virtue and its limit. Built from the tidy version, it runs the tidy version, and the exceptions that used to be absorbed by a person now arrive somewhere with nobody ready for them. They pile up in an error queue, or they pass through silently and surface as a customer complaint three weeks later.

The usual response is to blame the build. It is almost always the brief. The workflow did what the description said, and the description was incomplete in a way nobody could have seen from the front of the room.

Ask the people doing the work

The fix is old and unglamorous: ask the person who does the job how they do it, and ask in a way that does not feel like an audit. The question that works is not "what is your process?", which gets the official answer. It is "talk me through the last time you did this", which gets the real one, with its detours.

Three things make the conversation worth having. Ask about the last time, not the usual time, because the last time contains the exception. Ask what they check that nobody has asked them to check. And ask what they would be nervous about handing to a machine, because that answer is a list of the judgement calls in the job, and those are the parts to leave with the person.

The honesty a client needs

People answer differently when they think they are being measured. If the team believes the interview is a step towards cutting their hours, they will describe a process with nothing in it that a machine could do, and you will learn nothing. The conversation has to be about the work, not the worker, and the client has to say so before it starts and mean it afterwards.

That is a design position as well as a courtesy. abi. Clone interviews a client's team to build the map, and it is built around the work: it asks how the job really gets done, and it does not score the people answering. Where the map shows something it read from a document rather than something a person said, it marks it as from the document, so you can see which parts rest on testimony and which on paper.

What to do on Monday

Pick one process a client wants automated. Before you design anything, sit with the person who does it and ask them to talk you through the last time. Write down every point where they stopped, checked, rang someone or made a call. Those are the steps the diagram does not have. Decide, for each, whether it belongs to a machine, to a person, or to a machine with a person watching.

You will have a shorter, truer list than the one you started with, and an automation that fits the work as it is done. The client will notice, because the first thing they will say when they see it is that it understands how they actually do it, and that is what an automation sounds like when it was built from the real process.