The ratio gets quoted as if it were a target. Seventy per cent of back-office work executed by software, thirty per cent by people, and a slide showing the transition as a smooth curve. The number is roughly right for transaction volume in a well-run function and almost meaningless as a design instruction, because the thirty per cent is not a remainder. It is a set of roles that have to be deliberately constructed. The organisations doing this well did not automate seventy per cent of the work. They redesigned the whole function and discovered that seventy per cent of it no longer required a person.
Nobody ends up with a good thirty per cent by accident. What is left after automation is whatever nobody thought to specify, which is not the same as what actually needs a human
Here is how to design the human side on purpose.
The four human roles that have to exist
The exception specialist, who resolves what the automation escalates and who needs more experience than the job title usually suggests. The configuration owner, who holds the accounting logic expressed as system behaviour and can explain why each rule is set where it is. The population reviewer, who asks periodically whether the automated output as a whole is right, which no per-item control replaces. The relationship holder, who talks to the supplier, the customer, the auditor and the bank, and whose value is almost entirely outside the transaction record. Most functions create the first by default, the second by accident, the third not at all, and the fourth only if it already existed.
What the design gets wrong
The most common failure is treating the human side as supervision of the machine side. Framed that way, the roles become reactive, the good people leave, and the function acquires a queue of work nobody finds interesting. The better framing is that the automation handles the determined cases and the humans own the undetermined ones — which includes the decision about where the boundary should sit. A configuration owner who can move the boundary is doing a substantively different job from one who monitors it.
Where the ratio misleads
Seventy per cent of transactions is not seventy per cent of effort, and it is nowhere near seventy per cent of risk. The residual thirty per cent carries a disproportionate share of both, which is why functions that staff the human side against volume rather than against difficulty keep finding themselves short at exactly the wrong moments. Measure the split by effort and by risk. Both numbers will be uncomfortable and both are more useful than the transaction ratio.
| Human responsibility | Work to design |
|---|---|
| Exception specialist | Resolve cases outside normal processing |
| Configuration owner | Control rules, tolerances and changes |
| Population reviewer | Review aggregate outcomes and omissions |
| Relationship holder | Retain context and commercial judgement |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Designing Your AI-Human Back Office
- Construct the four roles explicitly rather than letting them form.
- Give the configuration owner authority to move the boundary.
- Staff against difficulty, not transaction share.
- Create the population review; it rarely appears on its own.
- Protect the relationship roles from being measured on volume.
- Write down the boundary and review it quarterly.
- Make the human side the interesting side, or lose the people.
- Re-measure effort and risk, not just throughput.
The Regional Angle
The first regional consideration is that this design decision arrives in the Gulf alongside a workforce policy decision, and the two should be taken together. National employment targets are much easier to meet with four skilled, permanent, professionally interesting roles than with twenty transactional ones, and the role structure described here is a better match for graduate expectations in Riyadh and Abu Dhabi than the processing jobs it replaces. Organisations treating automation and nationalisation as separate programmes are missing the one place where they clearly reinforce each other. The second concerns the relationship role, which carries more weight here than the generic model allows. Dealings with government entities, banks and major suppliers in this region are conducted person to person, often in Arabic, and often by someone whose standing depends on years of continuity. That role cannot be rotated casually and should not be measured on transaction throughput; it is closer to a commercial function than an administrative one, and functions that grade it as back-office support lose the people who do it well. The third is about knowledge continuity under regional mobility. A four-role structure concentrates institutional understanding in very few heads, and in a market where a significant portion of the finance team may leave the country within a few years, that concentration is the main operational risk of the model. Deliberate documentation, deliberate overlap on the configuration role, and a standing external relationship that can cover a gap are not optional refinements here. They are the price of running the structure at all.
The objection worth taking seriously
The strongest objection is that the ratio is being sold rather than observed. Seventy-thirty appears in vendor decks because it is memorable, not because anyone has measured it consistently across comparable functions, and the definitions underneath it are elastic enough to produce any number you want — count transactions and it looks like seventy, count time and it looks like forty, count the cases that actually mattered and it might be ten. Designing an operating model around a number with no agreed denominator is how organisations end up restructuring toward a benchmark that does not describe anyone. That is a fair description of how the figure is used, and it should not be treated as a target. The defensible part is not the ratio but the role structure, which holds regardless of where your own split lands. Whether your automation handles ninety per cent of transactions or forty, the same four human functions have to exist and the same three failure modes appear when they do not: exceptions staffed by juniors, configuration held by one person, and population review owned by nobody. Use the number as a rough indication that the shape of the function has changed, then throw it away and measure your own effort and risk distribution. The organisations that get this wrong are not the ones with the wrong ratio; they are the ones who never built the third role.
Common Questions
Is seventy-thirty a realistic target?
As a description of transaction volume in a mature function, it is plausible. As a design target it is not useful, because it says nothing about which thirty.
Can one person hold two of the four roles?
Commonly, in smaller functions. Configuration and population review combine reasonably. Exception handling and relationship work generally do not, because the time pressures conflict.
How do we keep good people in these roles?
By giving them authority over the boundary rather than responsibility for the output. The difference is visible to candidates within one interview.
What should we expect over the next twelve months?
Expect the ratio to keep being quoted and rarely defined. Expect population review to emerge as an audit expectation. Expect competition for experienced exception handlers. And expect a second wave of organisations rebuilding the roles they removed in the first.
Design Your AI-Human Back Office — we build the four human roles deliberately, starting with the one you almost certainly do not have.