A business process automation consultant who starts with the process, not the tool

Most automation projects fail in the same order. Someone picks a platform, builds a workflow that fires on the happy path, and then discovers that the process it was meant to replace has six exceptions, two approvals, and a person who quietly fixes things nobody documented. The automation works. The process it modelled did not exist.

So we start the other way round. Before anything is built, we sit with the people doing the work and write down what actually happens, including the exceptions. That usually finds two things: a couple of steps that automate cleanly and pay for themselves quickly, and a couple that look automatable and should stay human. Both are useful answers.

The number that decides everything is what the current process actually costs: how many people touch it, how long each step takes, how often it is redone because something was wrong, and what it costs when a mistake gets through. Almost nobody has this written down, and it takes a couple of days to get.

Once you have it, the decisions become easy and occasionally uncomfortable. Some processes everyone complains about turn out to cost four hours a month and are not worth touching. Others nobody mentions consume a day a week. The teardown exists to find that out before anyone builds anything.

Any workflow can be automated for the case where everything is correct. The reason automation projects overrun is that the real process is mostly the other cases: the invoice with no purchase order, the customer who replies to the wrong thread, the file that arrives as a photograph of a screen.

We ask for those first, because they determine the design. Some get handled automatically. Some get detected and routed to a person with the context attached, which is usually the right answer and much cheaper than making software judge them. What we will not build is something that silently does the wrong thing when reality does not match the diagram.

Language models are genuinely good at a specific set of steps in an operational workflow: reading an unstructured document and pulling fields out of it, classifying an incoming message, drafting a reply for someone to approve, summarising a long thread. Those steps used to require a person and now mostly do not.

They are a bad fit for anything that has to be exactly right every time and cannot be checked: arithmetic, moving money, and irreversible decisions. Our default is a model where it removes reading and typing, deterministic code where correctness matters, and a human approval step wherever an error would be expensive to undo.