Which parts of consulting delivery are actually repeatable?

A repeatability map is a step-by-step account of how your consultancy delivers its work, marking which steps run the same way every engagement and which genuinely need an expert's judgement. It is the thing to draw before you scope any software, because nearly every expert practice has both kinds of work, and the expensive mistakes come from treating the whole practice as one or the other.

Part of our guide to productisation.

The usual objection arrives within a minute of raising the subject: every client situation is different, so there is nothing here to automate. It is almost always wrong, but it is wrong in an entirely understandable way. From inside the work, the parts that feel difficult are the interesting, judgement-heavy ones, and the routine scaffolding around them stops registering precisely because it is routine. So the people best placed to describe the practice are often the least able to see which of it could run without them.

In this blog, Elliott Prince, Managing Director at Ferrous Labs, explains why the repeatable parts of expert delivery are so easy to miss, how to separate them from the judgement clients actually pay for, and why getting that line right decides everything that follows.

Why the routine parts are the hardest to see

There is an unexpected parallel in recent research on how language models work. In July, MIT Technology Review's Will Douglas Heaven reported on a tool Anthropic built to look inside Claude Opus 4.6, which surfaces what the model is working with part-way between reading a question and answering it. On a maths problem, it shows intermediate results that are not part of what the model eventually says. Those steps were there all along; it took a purpose-built instrument to see them, and the researchers describe even that instrument as "a flashlight rather than an overhead lamp", showing what you point it at rather than everything at once.

Expert delivery has the same shape. The finished report shows the conclusions, and the dozens of routine steps that produced them appear nowhere in it. A structural engineer assessing an unusual foundation 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 inside one engagement, the client sees only the result, and unless somebody deliberately goes looking, nobody separates the two. The repeatability map is that deliberate look, and like the flashlight, it only shows you the parts of the practice you point it at.

How do you draw the line between repeatable and expert?

The map is not a complicated artefact. It is the discipline of walking through your delivery step by step and asking three questions of each one.

Would ten different clients bring substantially similar inputs to this step? If they would, the step is a candidate for automation. If every client arrives with material that needs fresh interpretation, it is not.

Would a competent but less experienced person, following a written rule, get it right nine times in ten? If so, the knowledge can be transferred to software. If the value sits in the exceptions, and the rule would be right precisely when it did not matter, it cannot.

Does the client pay for this step, or only for the outcome it feeds? Steps a client never sees, the pure operational overhead, are usually the best candidates of all, however complicated they feel from inside. A surveying business can spend hours each week reformatting data between systems; that is not expertise, it is friction, and friction is exactly what software is good at removing.

When we run this exercise with clients, somewhere between a third and two thirds of the steps usually turn out to be systematisable. The exact share matters less than people expect. What matters is knowing which steps sit on which side of the line before anybody scopes a build, because that single decision shapes the cost, the product and whether clients will trust what comes out of it.

Two ways to get it wrong, pointing in opposite directions

The mistakes that come from skipping the map are mirror images of each other, which is part of what makes them hard to avoid by instinct.

The first is automating too much. A consultancy builds a tool that tries to replicate its expert judgement, it produces confident, fluent output, and then the edge cases, which were where the real value lived, turn out to be exactly where it goes wrong. Clients notice quickly, and trust in a professional context is lost far faster than it was earned.

The second is automating too little, and it is the more common of the two because it feels safer at the time. The business builds a document repository or a client portal and calls it a product, but there is not enough genuine automation in it to change how much human time each client needs. The tool becomes an overhead to maintain rather than an asset that scales, and it is usually abandoned within a year without anybody deciding to abandon it.

An honest map guards against both. Be straight about which steps need a person and you will not try to automate them; be equally straight about which steps are repetition dressed up as expertise and you will not leave them as manual work either.

Does the map change when AI is in the picture?

It does, and this is where it gets interesting. The line between what software can handle and what needs a person has moved a long way in a few years. Classifying documents, pulling structured data out of unstructured text, drafting a first-pass analysis against a rubric: tasks that needed expert time not long ago are now automatable with reasonable reliability.

That does not mean every consultancy should rebuild itself around AI. It means the map has to be drawn against what the technology can do now rather than what it could do five years ago. A few things that felt irreducibly expert are genuinely within reach of a well-designed system. A larger number of things people assume AI can handle still cannot be trusted to it, particularly anything that turns on judgement about an unfamiliar situation or a negotiation with the people involved.

Our property-tech document AI work is a reasonable illustration. The repeatable part, extracting and classifying information from a consistent type of legal document, was automatable, and we took each document from hours of manual review to under a minute. The decisions about what to do with that information stayed with the people who understood the business around it. Separating those two things cleanly was most of the job.

Where the economics actually come from

If your consultancy has a method that works, the constraint on revenue is almost always delivery capacity: you can take on as many clients as your team can serve, and no more. That is a structural limit rather than a sales problem, and there are only two ways past it, which are more people or more output from each person.

Software is the second route, though not quite in the way it is usually sold. Its marginal cost is low rather than zero. Every step you automate still costs something to run, and every step you leave with a person costs exactly what it did before, again, for every client you add. That residual is what decides whether the numbers hold at scale, and it is the subject of our piece on SaaS unit economics for consultancies. The repeatability map is the input to that calculation, and if the map is wrong, the spreadsheet built on it is fiction however carefully it was put together.

If the map does show enough repeatable work to build on, the next question is how to productise consulting services without losing the judgement clients are paying for, which is largely a question about where the software hands back to a person.

Draw the map before anybody quotes you a build

It is tempting to skip this, because it looks like the unglamorous part and the build looks like the real work. It is also the part that nobody else can do for you: a development partner can build whatever you specify, but only your own team knows which of its steps are genuinely routine, and that knowledge is exactly what the specification needs.

So start with one engagement type rather than the whole practice. Write down every step from the first client contact to the final deliverable, put the three questions to each one, and be honest about the answers, particularly about the steps you would rather believe need you. It is a day or two of senior time, and it will tell you more about whether you have a product than any amount of roadmapping.

What you end up holding is rare and useful: a clear view of which part of your practice could serve ten times the clients without ten times the people, and which part is the judgement that makes the whole thing worth buying. Those are the two halves of any product worth building, and most businesses never separate them clearly enough to find out.