Documenting a Workflow So It Can Actually Be Automated: A Field Guide

I have written up the structure I use to document a workflow well enough that AI can run it: name the trigger, list every input, map the decision points, define the exception path before the happy path, name the exit criteria. That structure is correct, and I use it on every build. What it does not fully convey is what actually happens in the room while a lawyer and I are building that document together, which is where the real difficulty lives, not in the structure itself.

The four-minute version is always confident, and always wrong-sized

Every intake process I have ever documented starts the same way. A partner describes it to me in a few minutes, fluently, with total confidence, because they have run it, or watched it run, hundreds of times. It sounds complete. It is never complete. The four-minute version is a summary optimised for a listener who already shares the partner's context, and I do not share that context, which is exactly why the four-minute version falls apart the moment I start asking what happens when.

I remember one trusts and estates build where the partner described intake as, roughly, "we get the initial call, gather some basic information, and schedule the first meeting." That sentence has, buried inside it, at least four separate decision points: who screens the initial call, what specific information actually needs to be gathered before scheduling makes sense, what happens if the prospective client cannot articulate what they need yet, and who decides whether this is even a matter type the firm takes. None of those four things were mentioned in the four-minute version, not because the partner was hiding anything, but because those decisions had become so automatic to a person who had made them a thousand times that they no longer registered as decisions at all.

Every 'usually' is a decision hiding from you

The single most useful habit I have built into how I run these sessions is stopping, out loud, every single time someone says "usually" or "generally" or "it depends," and asking them to finish the sentence. Not gently, and not just once. "It depends on what, exactly? Walk me through the two cases." This feels repetitive and slightly annoying to the person being interviewed, and I have learned to warn them in advance that I am going to do it constantly, because otherwise it reads as pedantry rather than the actual method. It is the method. Every one of those hedged words is a place where a real rule exists in someone's head but has never been written down as a rule, and a workflow document that leaves it as a hedge is a document a machine cannot execute, because a machine has no "it depends" to fall back on. It will either guess or fail, and neither is acceptable in a client's actual matter.

Exceptions first, not last, because that is where the real process lives

I deliberately ask about the exception path before I let anyone describe the smooth, happy-path version of a workflow, and this order surprises people every time, because it inverts how anyone naturally wants to explain their own work. But the smooth path, described first, tends to get treated as the whole story, with exceptions bolted on afterward as footnotes, and footnotes are exactly what gets handled wrong when a system encounters them for real. Asking "what happens when a document is missing" or "what happens when the client goes silent for three weeks" before asking about the ordinary case surfaces the actual texture of the work faster, because those are the situations that reveal what the firm's real judgment is protecting against.

The moment the document actually becomes useful

There is a specific, recognisable moment partway through these sessions where the tone in the room changes. It usually happens once we have mapped three or four decision points that the partner had genuinely never articulated before, even to themselves, and I watch them realise that different people in their own firm have been handling the same situation differently for years, without anyone noticing the drift, because nothing was ever written down precisely enough to compare. That moment is not a side effect of the documentation exercise. It is often the actual value of it, independent of whatever automation gets built afterward, because a firm that finally sees its own inconsistency in writing can choose to fix it deliberately, rather than discovering it accidentally, later, in front of a client.

Why I still do this the slow way

It would be faster, in the moment, to skip straight to building against the four-minute version and fix problems as they surface during testing. I do not do this, because every problem discovered during testing costs real time against a real matter, and every problem discovered during documentation costs a slightly awkward extra question in a conversation that was already happening. The eleven pages that came out of that four-minute description were not eleven pages of overhead. They were the actual specification of the work, and the build that followed took a fraction of the time the documentation did, precisely because there was almost nothing left ambiguous by the time the build started. That trade, a slow, occasionally uncomfortable documentation session in exchange for a fast, predictable build, is the whole method, and it holds up every single time I have actually run it properly.