The wrong question
At some point every year, someone on the board asks how much of the operation is already automated. A number comes back, usually somewhere between 40% and 70%, and the room is satisfied. Two weeks later, quarterly billing stalls because three people have to check a spreadsheet of manual adjustments before invoices can go out.
Both things are true at once, because the original question measures the wrong thing. Percentage automated measures what the firm bought. Workflow maturity measures how much the operation can finish without a person pushing the case along. They are different numbers, and only the second one shows up in the cost line.
Maturity is a property of the process, not of the system. Two firms running exactly the same platform can sit at completely different levels, and inside the same firm it is common for rebalancing to be well up the ladder while onboarding is still at the bottom. That is why a diagnosis made at company level is useless. The useful diagnosis is per process.
This matters because it decides the shape of the cost curve. In a low-maturity operation, serving twice as many clients takes roughly twice as many people, and the only way to protect margin is to raise the minimum account size. In a mature one, the marginal cost of an additional client approaches zero, and the firm can serve segments that previously did not add up. The strategic decision about which segment to serve is, in practice, a consequence of the level the operation sits on. Almost nobody treats the two decisions together.
The five levels
Before the first level there is a state that is not a level at all. The process happens, it delivers, it works, but it lives in people's heads, in inboxes and in local spreadsheets. The clearest sign is not being able to answer a simple question: how many cases are open right now, and how long has each one been sitting there. If nobody can say without opening a file and asking a colleague, there is no process, there is a shared habit.
Level 1, digitised. The flow now exists inside a system, with stages, owners and status. Every step is still executed by a person, and the speed gain is usually modest or nil. The real gain is different: for the first time there is a denominator. Cases can be counted, cycle time can be measured, and it becomes visible where things stop. The level is cleared when the process data sits in structured fields rather than in free text and attachments. As long as the information is written in a notes box, no later automation will have anything to feed on. The classic mistake here is celebrating too early and calling it automation when it is only record-keeping.
Level 2, rule-based. Deterministic steps start running on their own inside a single module. Fee calculation, periodic report generation, drift checks against the model portfolio, maturity and renewal alerts. These are tasks with a clear input, an explicit rule and a verifiable output. The level ends when the process can cross more than one module without someone exporting information on one side and retyping it on the other. The classic mistake is what you might call the automation island: each team automates its own piece, each stretch gets faster in isolation, and the whole process gets slower because new handoffs were created between the islands. Total cycle time gets worse while every local indicator improves.
Level 3, orchestrated. The flow crosses CRM, onboarding, modelling, execution and billing on a single data layer, with shared state. There is a logical owner of the case from end to end, there is reprocessing when a step fails, and there is compensation when a step that already ran needs to be undone. The exit criterion is numerical: a declared share of cases has to complete the whole path with no human touch at all. The classic mistake is orchestrating the happy path and forgetting the rest. When a step fails halfway and nobody defined what happens next, the case drops out of the flow quietly and becomes invisible manual work, which shows up in no report and eats more of the team's time than the formal process does.
Level 4, exception-based. Finishing on its own becomes the default behaviour. A person steps in when the system cannot decide, and those interventions are treated as an object in their own right, with a type, a reason, a response time and a root cause analysis. The difference from the previous level is that the exception stops being an accident and becomes something that is managed. The exit criterion is that the exception rate is measured, broken down by type and falling over time. The classic mistake is the false level 4: everything runs automatically, but someone reviews one hundred percent of cases before release, just to be safe. That is level 2 with extra steps, and it costs more than the original process.
Level 5, agentic with guardrails. Here the software stops executing a predefined sequence and starts deciding the sequence. It investigates, looks for the information that is missing, picks the path and either proposes or executes the outcome. This level only holds on an orchestrated base, because an agent needs reliable data and well-defined actions to call. On a fragmented base it produces plausible, wrong answers, now with a system stamp on them. When it works well, it always comes with limited authority, a controlled environment, the ability to reverse, and a record of the reasoning behind each decision.
Those six levels describe the process from the inside. The module below turns it around: pick a level and it shows what the rest of the firm notices when a process sits there, from the sales desk to the board to compliance, and what happens to headcount when volume doubles.
Outside view of the same six levels. What the firm sees, and what scaling costs.
Reading the two together is the point. If a level sounds right on the inside but the outside view does not match what your sales desk says about you, the honest answer is the lower of the two.
One indicator per level, so the reader can locate a process without relying on self-perception: level 1 measures cycle time, level 2 measures rework, level 3 measures straight-through processing rate, level 4 measures the rate and composition of exceptions, and level 5 measures how many of the agent's decisions get reversed by people.
Why nobody skips a level
The temptation to jump is strong, mostly because the market sells the top of the ladder as an off-the-shelf product. Each jump, though, has a fairly predictable failure mode.
Going from the starting state straight to automated rules produces automation of chaos. The process was never written down, so what gets automated is the version somebody happened to describe in a meeting, and every variation that existed in practice is now treated as an error. The team starts working around the system in order to get anything done, and within six months there is an official process and a real one.
Going from rules to agents without passing through orchestration produces the data problem. The agent needs to know the client's profile, what was agreed in the last meeting, which restriction was recorded two years ago and which portfolio is the current one. If that information is spread across five systems with different definitions of what a client is, the agent will pick one of them and move on with confidence.
There is a subtler jump, which is gaining capability without gaining governance. The operation starts closing a meaningful share of cases on its own, but nobody defined who answers when it closes them wrong. The first incident settles that by force, and the natural reaction is to put everything back under manual review, which drops the process into the false level 4 and burns the credibility of the whole programme for a couple of years.
The pattern behind all three is the same. The previous level is not red tape to be cleared, it is the raw material the next level consumes. A written process feeds a rule. Structured data feeds orchestration. An orchestrated flow feeds exception-based operation. A well-classified history of exceptions is exactly what teaches you what can and cannot be delegated to an agent.
The sequence is not original. Maturity models have been repeating this same rule for thirty years, and the most useful thing about them was never the ladder itself, it was the finding that almost everyone places themselves about two levels above where they actually are. The ladder fits on a single page. The work is looking at the process without defending the answer. It does not take a six-month diagnostic to say where your onboarding sits, it takes the willingness to answer without dressing it up.
The red line
Public discussion about autonomy tends to treat it as a single dial for the whole firm, set either conservatively or aggressively. In a real operation, autonomy is a setting per type of decision, and two questions resolve almost every case. Can the decision be undone? And how much explanation will be demanded of it?
| Explanation demanded | No explanation demanded | |
|---|---|---|
| Reversible | Can reach level 5: meeting preparation, report drafting, document classification, history summaries | Level 4 with sample checking: contact prioritisation, next best action, queue triage |
| Irreversible | Ceiling at level 3, always deterministic: fee calculation, order submission, rule-based rebalancing, settlement | Do not automate: suitability, risk exceptions, mandate changes, credit decisions |
Reversible means the error costs rework, not the client's money and not a regulatory file. High explanation demanded means someone may come back months later and ask you to reconstruct why it was done that way, and the answer has to be traceable to the rule and the data used.
The practical consequence is that a mature firm runs different levels inside the same process, and that is a sign of health rather than inconsistency. In a well-designed onboarding, document reading and classification can be agentic, KYC data checks automatic with sample verification, the suitability decision always human, and account opening itself deterministic and auditable. Four levels, one process.
The bottom right quadrant deserves particular attention. These are decisions that cost a lot when they go wrong and whose criteria nobody can fully write down, because they involve judgement about a person's situation. Not automating them does not mean leaving them manual and disorganised. It means automating everything around them, so that the person making the call receives the case ready, with the information gathered and the history visible, and spends their time only on the judgement itself.
Where the firm stands, and what to measure
Each level has one indicator that only makes sense at that level. At level 1 you measure cycle time, because it is the first time anything can be measured at all. At level 2, rework, because a badly designed rule shows up as cases coming back. At level 3, straight-through processing rate, the share of cases that complete the entire path with no human touch. At level 4, the exception rate and its composition by type, which is what shows whether the operation is learning. At level 5, how many of the agent's decisions get reversed by people, which is the only honest measure of trust.
Using the indicator of a level above the real one produces the wrong conclusion. Measuring automation in a process that has no structured data yet gives a high, empty number.
To locate a specific process, eight questions are enough. How many cases are open right now, and did that answer come from a report or from a person. Is the process information in fields or in free text. When a case gets stuck, is anyone notified automatically. What share of cases went from start to finish with no human touch last quarter. When a step fails halfway, what happens to the case. Are exceptions classified by type. Does anyone look at the composition of exceptions periodically and change the process because of it. Is there a record of who decided what, and on what basis.
The board question worth replacing is the one from the start. Instead of how much is already automated, ask what share of cases reached the end with no human touch at all last quarter, and what exactly stopped the rest from getting there. The first question produces a comfortable number. The second produces a list of work.
