When transaction counts grow faster than revenue, every new volume demands another hire. Here is what processes, robots and an assistant take off the desk — and what they will never take.
layers of back-office automation
processes and robots keep running
lines of code to launch a process
Volume grows linearly; back-office work grows faster, because every transaction has a tail of exceptions.
A payout above the limit, a refund on a disputed transaction, onboarding a merchant — each needs a chain of approvals, and the chain lives in email threads.
Export from the provider portal, drop it in a folder, load it into the accounting system. Work in which a person acts as a connecting cable.
Where the money for this transaction is, why it was declined, how to issue a refund. The answer is in the system, but finding it is rarely faster than asking a colleague.
Different tasks need different tools. Confusing them is expensive: a robot cannot replace a process, and an assistant cannot replace a robot.
Approvals, escalations and deadlines are drawn as a diagram: who approves, what happens above a limit, where a task goes if nobody answers within a day. The system executes the diagram, not somebody's memory.
Where a counterparty has no API, a robot does what a person did: signs into the portal, takes the export, puts the file where it belongs. On a schedule, and it does not forget.
It answers questions against your own organisation's data: transaction status, decline reason, change history. It saves not the transaction but the minutes of searching — which add up to an hour a day.
Back-office automation is usually sold as a single tool, and that is its main weakness. A robot pointed at an approval process becomes a brittle construction: change the order of approvals and the robot breaks. A process meant to replace file shuffling runs into the fact that the counterparty has no API. The right division is simple: the process describes decisions, the robot performs actions, the assistant answers questions.
The second difference is who authors the automation. A classic rollout needs a vendor and a project of several months, after which every change needs the vendor again. Here the process is assembled in the operator dashboard by the same person who works inside it — the one who knows best where the time is actually lost. The cost of a change drops to half an hour, and the automation stops going stale.
And an honest boundary. Automation will not take over investigating a disputed transaction, negotiating fees with a provider, or deciding whether to release money to a questionable recipient. That is what back-office work substantially is. The point of the three layers is that your people spend their day on that, instead of copying rows between windows.
Three setup wizards. The operator goes through them alone — no development needed.
Steps, roles, transition conditions, deadlines and escalations. A process starts on a transaction event or by hand.
Scenario, schedule, credentials and failure behaviour: retry, postpone, or hand over to a person.
The data scope available to the assistant, the user roles, and the boundaries: what it answers and what it hands off.
Start with the process, not the robot: until the order of approvals is written down, a robot will automate the mess and cost more than doing it by hand.
Register and build your first process yourself — the diagram runs without development. Robots and the assistant come as the next steps.
Get started