Productise Consulting Services: The Repeatability Map

To productise consulting services is to identify the repeatable skeleton inside your bespoke delivery, and build software around that skeleton while leaving genuinely complex judgment to the humans who are paid for it. Most specialist consultancies have both: a set of steps that run the same way every engagement, and a set of decisions that require experience, context, and nuance that no current system can reliably replicate. The mistake is treating the whole practice as one or the other.

Why consultancies misjudge what is actually repeatable

The standard objection to productising a consultancy goes like this: "Every client situation is different, so there is nothing to automate." That is almost always wrong, but it is wrong in an understandable way. When you are inside the work, the parts that feel difficult are the interesting, judgment-heavy parts. The repetitive scaffolding around them becomes invisible precisely because it is routine.

There is a useful parallel here from a different domain. MIT Technology Review recently covered Anthropic's finding that Claude, when working on hard problems, appears to operate in a kind of intermediate representational space, puzzling through concepts before settling on an output. The interesting observation is not that the model thinks like a human, but that even a system built from statistical patterns has identifiable layers: some mechanical, some genuinely complex. The same layering exists in any expert practice. The question is whether you have ever mapped yours.

A structural engineer assessing unusual foundations is doing something irreducibly expert. The same engineer completing a standard site report, applying consistent criteria to consistent inputs, is doing something a well-designed system could handle. Both happen in the same engagement. Only one of them should end up in software.

How do you draw the line between repeatable and expert?

The repeatability map is not a complicated artefact. It is a discipline of asking three questions about every distinct step in your delivery process.

First: if ten different clients triggered this step, would the inputs look substantially similar? If yes, the step is a candidate for automation. If every client brings genuinely novel inputs that require fresh interpretation, it is not.

Second: if a competent but inexperienced person followed a written rule, would they get the right answer at least ninety percent of the time? If yes, the knowledge is transferable to software. If the edge cases are where all the value is, they are not.

Third: does the client pay for this step specifically, or for the outcome it contributes to? Steps that are invisible to the client, pure operational overhead, are usually the best candidates for automation regardless of how complex they feel internally. A surveying business might spend hours reformatting data between systems. That is not expertise, it is friction, and friction is exactly what software should eat.

Work through your delivery process end to end with those three questions and you will usually find that somewhere between a third and two thirds of the steps could be systematised. The exact proportion does not matter much. What matters is that you know which steps belong in which category before you scope any software.

What breaks when you get the scoping wrong

Two failure modes are common, and they are mirror images of each other.

The first is automating too much. A consultancy builds a tool that tries to replicate its expert judgment, produces confident-sounding outputs, and then discovers that the edge cases, where the real value was, are exactly where the tool fails. Clients notice. Trust erodes faster than it built.

The second is automating too little. The business builds a document repository or a client portal and calls it a product. There is not enough genuine automation to change the unit economics, so the tool becomes an expensive overhead rather than a scalable asset. This is the more common failure because it feels safer at the time.

The repeatability map protects against both. If you are honest about which steps genuinely require human judgment, you will not try to automate them. And if you are honest about which steps are pure repetition dressed up as expertise, you will not leave them as manual overhead.

Does the map change when AI is in the picture?

Yes, and this is where it gets interesting. The line between what software can handle and what requires human judgment has shifted materially in the last three years. Tasks that would have required expert human time in 2021, classifying documents, extracting structured data from unstructured text, drafting first-pass analyses against a rubric, are now automatable with reasonable reliability.

That does not mean every consultancy should rebuild itself around AI. It means the repeatability map needs to be drawn with current capability in mind, not capability from five years ago. A few things that felt irreducibly expert are now genuinely within reach of a well-designed system. A larger number of things that people assume AI can handle reliably still cannot, particularly anything requiring contextual judgment about novel situations or genuine stakeholder negotiation.

Our work on the property tech document AI case study is a reasonable illustration of this. The repeatable part, extracting and classifying data from a consistent document type, was automatable. The downstream decisions about what to do with that data remained with the humans who understood the business context. Separating those two things was the whole game.

The economics of getting the map right

Here is the practical case. If your consultancy delivers a methodology that works, the constraint on revenue is almost always delivery capacity. You can only take on as many clients as your team can serve. That is not a sales problem or a marketing problem. It is a structural problem, and the only structural solutions are hiring more people or making each person more productive.

Software solves the structural problem in a way that hiring does not, because software does not have a marginal cost that rises with every additional client. But software only solves it if you have correctly identified which parts of delivery to put into the software. Get that wrong and you have built an expensive tool that still requires the same amount of human time per engagement. The only way to genuinely scale a consultancy without hiring is to be precise about where the leverage actually is.

If your consulting methodology maps cleanly to a repeatable process with clear inputs and outputs, that is the raw material for a product. The delivery is already proven. The market already exists. The remaining question is whether you want to build the software layer that lets you serve ten times the clients without ten times the headcount.

If the answer is yes, our SaaS Product Build partnership is designed for exactly this situation. We co-build the software with you and share in the upside, so we are incentivised to get the scoping right rather than to maximise development hours. The repeatability map is where that conversation starts.