Before we automate anything we measure where the hours actually go. The step that costs the most is rarely the step people complain about, and building on a guess is how automation budgets get spent without anyone noticing a difference.
Touch time against elapsed time
Business process automation redesigns and then automates a complete process rather than isolated tasks. It starts with process mining to find where time actually goes, so the automation lands on the highest-cost step instead of the most visible one.
Almost always traceable to one of these four, and none of them are technology failures. The wider business framing sits under our automation challenge overview.
The team that complained most got automated first. Their process turned out to run forty times a month and take eleven minutes. Meanwhile a silent queue in a different department was absorbing hundreds of hours a quarter because the people in it had simply accepted it. Complaint volume measures tolerance, not cost.
A second approval that exists because a system in 2014 could not enforce a limit. A reconciliation that only checks something no longer possible. Automating those makes them permanent, and they were the cheapest thing on the list to remove. Redesign before you build, always.
Without a baseline, the benefit case after go-live is a story rather than a number. This is why automation programmes struggle to get a second round of funding even when the first round genuinely worked. Measure the same process the same way, before and after, or expect to argue about it.
Everyone described the standard route. Mining showed the standard route covered under half the volume, and the rest went through regional and product-specific detours nobody documented. Building for the described process means most cases fall out as exceptions on day one.
Roughly a third of the effort happens before anybody writes an automation, and that third is what determines whether the other two thirds were worth it.
We pull event timestamps out of the systems a process touches and reconstruct how cases actually flowed. That produces handling time and waiting time per step, the rework loops nobody mentions in a workshop, and the variant breakdown by volume. It is evidence rather than a whiteboard, and it routinely contradicts the version everyone agreed on.
Where systems do not emit usable events, we instrument them or fall back to structured shadowing. Either way, the map is measured.
Every measured process contains steps that exist for reasons that stopped being true years ago. Deleting one of those returns more time than automating it ever will, and it costs nothing to run. We look for those first, and we are happy for that to shrink the build we were hired for.
Candidates ranked on measured impact against honest build effort. The first thing we build is chosen to be defensible in a steering meeting, because that is what funds the second thing.
Orchestration for deterministic steps, robots where there is no API, extraction for documents, models only where judgement is genuinely needed. That mix is what people mean by hyperautomation.
The same process, measured the same way, three months later. It is the only honest benefit case, and occasionally it tells us we were wrong.
A customer onboarding process at a mid-market lender, anonymised. Pick the step you would target. The measured numbers appear after you choose, which is roughly how this goes in a real workshop.
Verdict
Most people choose step 2, because keying documents is visible, tedious and everybody has watched somebody do it. Choose whichever you would target and the measured figures will appear.
Total elapsed: about 52 hours. Total human work: 59 minutes. That ratio is typical, and it is why measuring waiting time matters as much as measuring effort.
Five steps in this order, following the same delivery shape as the rest of the AI and automation practice.
Where does it start, where does it end, and which systems does it cross. Most disagreement about whether automation is worth it comes from two people describing different boundaries, and settling this in the first meeting saves weeks of argument later.
Timestamps from the systems involved, reconstructed into how cases actually flowed. Handling time, waiting time, rework loops and variant volumes. This is the deliverable that changes people's minds, and it is useful to you whether or not you build anything.
Remove steps that exist only because of a past system limitation, consolidate duplicate approvals, and merge handoffs that could be one. Automating a step you could have deleted is the most expensive option available, and it is the default one.
Rank what is left using measured hours and rule clarity. Build the highest-impact low-effort item first, because a programme that shows a defensible result early gets funded for the harder items later.
Implement with the right mix of orchestration, robots and models, then re-measure the same process the same way. Full handover follows: source, definitions, documentation and IP assigned to you on final approval.
Eight real candidate types plotted on measured impact against honest build effort. Select one to see where it lands and which part of the practice would deliver it.
The top-left quadrant is where a programme should start, and it is almost never where the enthusiasm is. Pick any candidate to see where it plots and why.
Measured in time rather than money, because time is the number you can verify. If the payback period is longer than the process is likely to survive unchanged, do not build it.
Measured handling time across everyone who touches it.
After redesign, and excluding the exceptions people will keep.
Including measurement, build, testing and handover.
Payback period
21
weeks of running before the build effort is returned
Hours back per year
800
Equivalent to
0.38
full-time roles
Formula: annual hours × automatable share gives hours returned. Build effort in person-weeks × 40 gives build hours. Payback weeks = build hours divided by weekly hours returned. Maintenance is not included, and for anything involving robots it is not negligible.
Get the measured versionHyperautomation is not a product you buy. It is what happens when a single process needs four different technologies at four different steps, which most real processes do.
Layer 1
The backbone. It holds the state of a case, decides what happens next, retries what failed and parks what needs approval. Every other layer is a step this one calls, which is why it gets built first even when it is not the interesting part.
Layer 2
For the one system in the chain that has no API. The robot is a tool the orchestrator invokes, not a strategy of its own, and it should be documented as a known piece of technical debt with a maintenance owner attached.
Layer 3
Because a large share of process input still arrives as a scan or an email attachment. Extraction produces structured fields with a confidence score, and the threshold decides what a person still reviews rather than what quietly enters your systems.
Layer 4
The smallest layer and the one people start with. A model classifies, routes or drafts where no rule can be written, and everything around it stays deterministic. If this layer is doing most of the work, the process was probably not ready to automate.
Four that reliably contain more waiting than anyone expects. Profiles are anonymised.
Crosses sales, credit control, production planning and the warehouse. The credit hold is usually where cases sit longest, and it is usually invisible to everyone except the customer waiting for a delivery date.
Manufacturing engagementsThe example in the module above. Document collection and external checks dominate elapsed time while the actual assessment takes minutes, and the variant count across products is always higher than the process document suggests.
Banking and insuranceLong-running, document-heavy, and full of chase loops between the claimant, the carrier and the insurer. Mining usually shows the same three chases repeating on most cases, which is a workflow problem rather than a staffing one.
Logistics engagementsReferrals arriving by fax, email and portal, then routed by hand. The measurement almost always finds a queue where referrals wait for a person to notice them, and that queue is cheaper to fix than any of the clinical steps.
Healthcare engagementsThree different scopes sold under overlapping names. Knowing which one you are buying prevents most of the disappointment.
| Criterion | Task automation | Business process automation | Digital transformation |
|---|---|---|---|
| Scope | One step | One process, end to end | The operating model |
| Starts with | A tool | Measurement | A strategy |
| Typical duration | Days | Weeks to months per process | Years |
| Can the benefit be proven? | Rarely measured | Yes, if you baselined first | Contested, always |
| Main failure mode | Local speed-up, no change downstream | Skipping measurement and building on a guess | Never reaching an operational change |
Most organisations asking for transformation want the middle column done well, several times. The broader programme framing lives under digital transformation and gaining efficiency.
Measurement produces a backlog; these are the parts of the AI and automation practice that deliver against it.
The orchestration layer that most of a measured backlog turns into.
For the steps where the input arrives as a scan and someone retypes it.
Sequencing across many processes, and a readiness assessment before the first one.
Once a process emits clean event data, forecasting its load becomes possible.
Connecting the systems a measured process crosses, which is often the real constraint.
The operations-leader framing of everything on this page, without the engineering detail.
Programme governance and vendor decisions sit with our IT consulting team, and where a process is held together by an internal tool that needs rebuilding, our web engineering team handles that. To start, describe one process or read the help centre.
The ten that come up in almost every first conversation.
You get a measured map and a ranked backlog whether or not you build anything with us. We reply in under 3 minutes.
