Most organisations deploying automation into the back office this year are treating it as a capacity question: how much of the existing volume can the software take, and what does that do to headcount. The organisations getting better results are asking a different question — what is each party good at — and building a division of labour rather than a substitution plan. The distinction sounds semantic. It produces materially different operating models, and only one of them survives contact with a difficult month.
Automation is excellent at doing the same thing a thousand times and poor at knowing when the thousandth time is different. People are the reverse, and an operating model that ignores that asymmetry wastes both
Designing the split deliberately is the work. Here is how it divides.
What each side is genuinely better at
Software wins on volume without fatigue, consistency of treatment, tirelessly complete documentation, patience with tedious matching, and availability at three in the morning on the last day of the month. People win on recognising that something is wrong before knowing why, holding context that was never written down, judging when a rule should not apply, negotiating, and absorbing accountability. That last item is not a soft skill; it is a structural requirement, because somebody has to be answerable. The design principle that follows: give the machine the volume and the person the boundary. The value is created at the boundary, so staff it properly.
Four working patterns
Machine prepares, human commits. The default and the most defensible. Captures most of the productivity and keeps accountability intact. Effective only if the human has genuine time per item — otherwise it is theatre. Machine acts, human samples. For high-volume, low-value, reversible work. Requires real sampling discipline and monitoring rather than an occasional glance. Human decides, machine executes. Underrated. The judgement is human and the tedious multi-system execution is automated. Often the highest-value pattern and the least demonstrated, because it does not look impressive. Machine escalates, human owns. For the residual population that is genuinely hard. Needs your best people, not your cheapest. Most processes need two or three of these at different stages. Applying one pattern across a whole function is the commonest design error.
| Pattern | Human responsibility |
|---|---|
| Machine prepares | Review and authorise commitment |
| Machine acts | Monitor and sample eligible reversible work |
| Human decides | Approve the decision before machine execution |
| Machine escalates | Own and resolve difficult exceptions |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The role that has to exist and usually does not
Somebody has to own the automated process: understand why it behaves as it does, notice when its behaviour shifts, maintain it when the underlying system changes, and explain it to auditors. This is not a technology role and it is not a clerical role. It is closest to a process engineer with accounting knowledge, and almost no organisation has hired one. Without that role, an automated process degrades invisibly over about eighteen months as the business changes around a configuration nobody is maintaining.
Practical Guidance for Design Your Human+Agent Back Office Model
- Map each process step to one of the four patterns explicitly.
- Give the machine volume, the person the boundary.
- Staff the exception desk with strong people, not spare capacity.
- Create a named process owner role and fund it.
- Ensure reviewers have real time per item or drop the review.
- Use human-decides-machine-executes more than you think.
- Re-examine the split quarterly as capability changes.
- Keep accountability with a person at every stage.
The Regional Angle
The first design factor here is language, and it works in both directions. A regional back office deals with documents in Arabic and English, supplier names transliterated inconsistently, and correspondence in whatever language the counterparty uses. Automation is now good enough to read and draft across those languages, which removes a real bottleneck — the team no longer needs the one person who handles Arabic correspondence to be present for work to flow. But the judgement about whether a translated commercial term means what it appears to mean remains human, particularly in contracts and government correspondence where the Arabic version is the governing text. Automate the reading and the drafting; keep a human on the interpretation. The second concerns the process owner role, which is harder to fill in this region and therefore needs planning rather than recruiting. The combination required — accounting knowledge, regional statutory understanding, comfort with configuration, and enough seniority to be heard — is scarce in the Gulf market and expensive when found. The practical route is internal: the person who currently knows why your reconciliation works the way it does is usually already on the team, and developing them into the owner role is faster and cheaper than hiring. Doing that deliberately also solves a retention problem, because it gives your most knowledgeable transactional staff somewhere to go as their existing work is automated. The third is about how work actually gets distributed across time zones in regional operations. A Gulf-based finance function frequently coordinates with an offshore processing centre in South Asia, a group head office in Europe, and operations across several Gulf states whose working weeks and public holidays do not align — with Ramadan hours, Friday and Saturday weekends in some countries, and Eid dates that move. Automation is genuinely valuable here for a reason that has nothing to do with cost: it fills the gaps when nobody is working. The design that exploits this puts machine processing in the overnight and holiday windows and human decision points in the hours when the relevant people are actually available, which requires mapping your process against the working calendar rather than against a notional eight-hour day.
The objection worth taking seriously
The strongest objection is that this is an elaborate way to avoid the conclusion the numbers point to. If automation can process ninety per cent of transactions, the honest operating model is a smaller team, and designing a careful division of labour is what organisations do when they want the productivity benefit without the uncomfortable conversation. The boundary work is real but small, the process owner role is one person rather than a function, and the practical outcome of all this design thinking is usually the same headcount doing less work. That is a fair challenge, and in organisations where the automation genuinely covers the volume, the team should indeed be smaller. Where it misreads the situation is in treating the boundary population as fixed. It is not: as the machine takes more volume, the residual cases become harder and more consequential, because the easy ones were the ones that automated. A team half the size handling only the difficult tail needs more capability per person, not less, and organisations that reduced headcount by selecting on cost rather than on capability have found the exception queue growing and the error rate rising about two quarters later. The argument is not against a smaller team. It is against assuming that the people who remain can be the cheapest ones, and against leaving the process ownership unfunded because it was never a line in the old structure.
Common Questions
Which pattern should we start with?
Machine prepares, human commits, in one high-volume process. It is the safest, it produces measurable results in a quarter, and the override rate tells you whether you can progress.
Is the process owner a technology role?
No. It requires accounting and process knowledge with enough technical comfort to read a configuration. Placing it in the technology function is a common mistake and it separates ownership from consequence.
How do we keep review from becoming a rubber stamp?
Measure time per item and override rate. If either collapses, the review is nominal — replace it with sampling plus a preventive limit, which at least is honest.
What should we expect over the next twelve months?
Expect vendors to pitch substitution while the better outcomes come from division of labour. Expect the process owner role to start appearing in job advertisements under various names. Expect exception-desk capability to emerge as the real differentiator between deployments that worked and those that did not. And expect the human-decides-machine-executes pattern to be quietly where most of the durable value lands.
Design Your Human+Agent Back Office Model — we map each step to the party that is actually better at it, then staff the boundary where the value is made.