Back-office automation for work that crosses three systems and a person in the middle.
We map where the work actually stops, then automate the handoffs that are costing you time rather than the tasks that are easiest to automate.
- Ref
- PO-4192
- Supplier
- Ardenne Ltd
- Amount
- £4,280
- Ref
- PO-4192
- Supplier
- Ardenne Ltd
- Amount
- £4,280
- Ref
- PO-4192
- Supplier
- Ardenne Ltd
- Amount
- £4,280
Both the delay and the source of most errors.
Shape of a record, illustrative. No figure on this page is read off this drawing.
The work is not slow. It is waiting.
In most back-office processes the work takes minutes. What takes days is the gap between one person finishing and the next starting, and no system measures that.
- Coordination
A request arrives in one place
Email, a form, a shared inbox or a message. It is now someone's job to notice it.
- Work
Someone re-keys it into a system
The same information typed a second time, which is both the delay and the source of most errors.
- Coordination
It waits for an approval
Often for someone who does not know it is waiting, because nothing told them.
- Work
A second system needs the same data
Entered again, or exported and imported, or reconciled later by whoever notices the mismatch.
- Coordination
Someone checks it was done
A person whose actual job is confirming that other people did theirs.
Five steps, of which two are work and three are coordination. Automation applied to the wrong three changes nothing.
Four handoffs that cost more than the tasks around them.
The solid blocks either side are the work. The hatched span between them is the handoff, drawn wider where the wait is longer, relative to each other only.
- Intakesystem
Intake to system
- What it looks like
- Someone reads a request and types it somewhere else
- What it actually costs
- Delay measured in hours, plus the error rate of manual entry
- Systemapprover
System to approver
- What it looks like
- A record waits for a decision by someone not watching for it
- What it actually costs
- The largest single delay in most processes, and invisible in task-time reporting
- Systemsystem
System to system
- What it looks like
- The same data entered twice, or exported and imported on a schedule
- What it actually costs
- Reconciliation work, and a window where two systems disagree
- Doneconfirmed
Done to confirmed
- What it looks like
- A person checks that the previous steps happened
- What it actually costs
- A full role in some organisations, created entirely by the gaps above
We measure these four before proposing anything, because which one dominates decides what is worth building.
What the process looks like afterwards.
The target is not a fully automatic process. It is a process where the waiting is removed and a person is still in the decisions that need one.
Intake captured once
Whatever arrives is read and entered by the system, with the original kept for reference.
Records created directly
No re-keying. Where a system cannot be reached, that is named as a constraint rather than absorbed by a person.
Approvals routed and chased
The approver is told, reminded, and the record shows what is waiting on whom.
Systems reconciled continuously
Rather than a weekly exercise in finding out where two systems disagree.
Exceptions raised, not buried
The unusual cases go to a person with the context attached, instead of stopping silently.
Confirmation becomes a report
The checking role becomes a dashboard, and the person does something else.
Where the constraint turns out to be document handling rather than coordination, finance and document workflows is the closer fit.
Finance and document workflowsWhat changes, and what we will not promise.
We can say what typically changes in shape. We will not attach a percentage to your process, because we have no published result and inventing one would be worse.
- Falls first
Elapsed time falls before task time does
The saving comes from removing waiting, which is why measuring task duration understates it.
- At intake
Error rate falls at the intake point
Because the most common source of error is the same information entered twice.
- Once measured
Exceptions become visible
Which usually reveals that the exception rate was higher than anyone believed.
- Last to move
Headcount moves rather than disappears
The checking role is the one that changes, and in every engagement we have run that person moves to work that needed doing anyway.
How the work runs.
Where a number matters, the honest route is to measure your current handoffs first, using data your systems already hold. That is what the assessment is for.
Measure the four handoffs
From real records rather than from a workshop, because recollection consistently underestimates waiting.
Pick the one that dominates
Automating the others first feels productive and changes the elapsed time very little.
Build the narrow path end to end
One request type, all the way through, in real use before the second one is added.
Keep a person in the decisions
The approval and the exceptions stay human. The coordination around them does not.
Widen once it holds
Further request types on the same foundation, added by your team where possible.
The closest published evidence we have.
No published Viithiisys case study is a back-office automation engagement. The nearest evidence is operational work where coordination was the constraint.
Vizitor
Workplace operations.Arrival, contractor and access coordination across multiple sites, where the handoffs were the work.
Read the case studyMilo
Fleet operations.Trip acceptance coordination between dispatch and drivers.
Read the case study
Both are operational coordination rather than back-office administration. We are showing them as the closest available evidence, not as equivalent work.See all case studies
How the systems get connected, and what happens when one cannot be.
Back-office automation lives or dies on integration, and the honest constraint is that not every system will cooperate.
A documented interface
When it applies. The system offers a supported way in
What it means for the design. The straightforward case. Changes survive the vendor's upgrades.
An undocumented interface
When it applies. One exists but is not officially supported
What it means for the design. Usable, with the risk named: a vendor update can break it, so monitoring matters more.
File exchange
When it applies. The system can export and import on a schedule
What it means for the design. Workable, but it introduces a window where two systems disagree. That window gets designed rather than ignored.
No route at all
When it applies. A closed system with no interface and no export
What it means for the design. This step stays manual. We say so at the design stage rather than discovering it in build.
The fourth row is the one that changes plans. A process with a closed system in the middle can still be improved, but not by pretending that step will be automated.
What we will not automate.
Two of these four point at a process change rather than a build, which is a legitimate outcome of the first conversation.
A decision that needs judgement
Approvals involving discretion stay with a person. Automating the routing around them is the win, not replacing them.
A process nobody has settled
Automating a process still being argued about encodes the argument and makes it harder to change.
Something that happens twice a month
Low-frequency work rarely repays the build and the maintenance that follows it.
A step that exists because of a broken upstream system
Fixing the upstream cause is cheaper than automating the correction, and we will say which applies.
Who we need from your side.
Where the second person does not exist, that is worth knowing first. Approval policy is the single most common blocker on this work and it is not ours to change.
The handoffs live with the people doing the work today.
Whoever does the work now
The four handoffs and every undocumented exception live with them, and no system record captures those.
Someone who can change the approval rule
Because the largest delay is usually an approval, and shortening it is a policy decision rather than a technical one.
Access to the systems involved
Read access early, so the connection type above is established before anything is designed.
Someone who owns the outcome
A process improvement with no owner reverts, usually within a quarter.
Show us the request that takes three days and twenty minutes of work.
Describe one thing your back office processes regularly. We will tell you which handoff dominates, and whether automation or a process change is the better answer.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.