Articles
Which expert processes are worth specifying first
The most common question in a first meeting is this: what would be the best use case for us? It is the wrong question, because it assumes the answer depends on the AI. The answer depends on the work. Two organisations in the same industry, of the same size and with the same tools, end up in different places, because their work is organised differently. We have written separately about why individual prompting does not speed up an organisation: the process belongs to ten people's ten habits rather than to the unit. This article answers what to do about it first. The choice is settled on two axes and one filter. You can work through them yourselves, without anyone external, and the result is a shortlist you can already make decisions with.
The first axis: recurrence
Recurrence does not mean sameness. This is the misunderstanding that stops most conversations within the first five minutes, and it usually sounds like this: every assignment we take on is different. Usually that is true, and usually it does not matter. The difference is in the content, not in the structure. A condition survey, a due diligence, a permit application, or a tender calculation produces a different result every time, but the stages are the same, the decision points are the same, and the acceptance criteria are the same. That is precisely what makes them good candidates. Here is the test. If two experienced practitioners each sketched the stages of the work on a flip chart separately, how similar would the two sketches be? If the stages line up and only the content varies, the work is recurring in the sense that matters here.
The second axis: degree of productisation
The second axis is a scale with the artisan model at one end and a standard process at the other. In the artisan model, quality lives in the person. An experienced specialist does excellent work, but they do it their own way, and nobody outside can say precisely what it is they do. This is real mastery. It simply does not scale, it does not transfer to a new practitioner, and it does not survive a retirement. In a standard process, quality lives in the structure. The practitioner can change without the result changing. Neither end is morally better, and plenty of organisations sit at the artisan end for good reasons. But only one end can be described to a machine, and the degree of productisation is almost always a decision rather than a property of the work. Most often an organisation sits at the artisan end because nobody ever decided otherwise.
Four quadrants and what to do in each
Combining the axes gives a grid that tells you where to start. High recurrence, low productisation: largest return. The work already recurs, but everyone does it their own way. Specification delivers most here, because it addresses both variation and speed. It also demands the most from your own specialists, because the knowledge is in them. High recurrence, high productisation: fastest win. The process is already documented and agreed. Specification is largely a matter of translating what exists into a form a machine can execute. A good first target if you need a result quickly. Low recurrence, low productisation: do not start here. Settle the business question first: do you actually want this work to recur? If the answer is no, automation is not a solution but a more expensive way of making the same decision later. Low recurrence, high productisation: specify, but wait for volume. The description is valuable in itself, because it preserves the expertise. Whether automation pays off is decided once volume grows. A practical rule of thumb: start from the top row. Which of the two quadrants you pick depends on whether you need fast evidence or large impact.
The third filter: verifiability
Once two or three candidates remain, run them through a single question. Does the correctness of the result matter, and can it be checked? If the answer to both is yes, the process is worth specifying. Acceptance criteria can be written down, and that is in practice the core of the whole exercise. If correctness matters but cannot be checked, this is not an automation question but a design problem. It has to be solved before automation, not after. A process whose output nobody can evaluate is a risk whether a human or a machine performs it. The machine simply produces the risk faster. If correctness does not matter, it is worth asking why the work is done at all.
Why "we do not have the data" is not an obstacle
This is the other conversation stopper, and it usually works the opposite way round from what people expect. The most interesting candidates are precisely those processes with no structured data. The work has happened in people's heads, in email, in meetings, and in attachments, leaving no trace in any system. That is exactly why no earlier technology could reach it. Once the process is described, data starts to appear as a by-product. Every stage, decision, and approval leaves a record. Data is not a precondition for specification. It is a result of it. The reverse also holds. If a process already has good structured data, it has most likely been automated by conventional means already. The remaining upside is smaller there than where nothing exists.
When not to specify
For the sake of honesty, the other direction as well. Specification is not worth it for a one-off analysis, a personal aid for a single individual, or light automation for a handful of users. These are solved faster and more cheaply with an off-the-shelf product, and they should not be turned into a project. The line runs roughly here: does the result need to be the same regardless of who produces it? If not, a ready-made tool is enough.
A five-question self-test
Take this into a management meeting and answer out loud. What are your three most frequently recurring assignment types, and how many of each do you handle in a year? Would two experienced practitioners describe their stages the same way? Where does someone approve something, and how do they know the result is acceptable? If the work goes wrong, is it noticed, and at which stage? Who in the house knows most about this work, and how many years do they have left? If question two is a yes and the answer to question three is anything other than experience, you have a candidate. If the answer to question five is one name and a small number, you are in a hurry.
On scale
One practical observation to support the choice. When an expert process is broken down into implementable steps, there are typically between forty and sixty of them. That sounds like a lot, but the majority are technical tasks that recur from one process to the next. In a larger programme, where several dozen workflows have been modelled with more than three hundred specialists, this shows up as follows: the first process is clearly the heaviest and the ones after it get lighter. Part of the specification work is organisation-specific and done once rather than every time. Which is why the first target is worth choosing carefully and the rest can be chosen faster.
Next step
If you now have one or two names on the list, the next step is a 30-minute discovery conversation. We go through the candidates together and assess which one delivers most first. No implementation commitment.
Frequently asked questions
Q:How many processes should go into the first batch?
One process is enough, but it is worth breaking into a few workflows rather than treating it as one. Three workflows from a single process has proven a workable first batch: broad enough to show the whole, bounded enough to finish.
Q:How do we know whether our work is too variable?
Ask two experienced practitioners separately what the stages of the work are. If the answers largely match, the work is not too variable. If they differ substantially, that is not an obstacle either, but it tells you that you first need to agree how the work is done. That is a business decision, not a technical question.
Q:Do we need to document the process ourselves before getting in touch?
No. Existing documentation helps if you have it, but its absence is not an obstacle. Describing the work is exactly the task that should not be done twice at two different levels of precision.
Q:What if the process changes constantly?
A changing process is more common than a static one, and it is not a problem. A specification is a versioned document, not a rule carved in stone. The problem only arises if nobody knows which version is current, because then change is not change but drift.