01 Overview
Customer onboarding at a large multinational bank
Six of every ten days went on doing the work twice
The bank wanted onboarding 25% faster across more than 130 products and services, each with distinct workflows and execution patterns. Before choosing where to cut, it needed to know where the time was going. The answer was already sitting in its operational records.
02 The problem
A target without a baseline
Onboarding spanned more than 130 products and services — including account opening, wire transfer, online business banking and remote deposit — with different workflows and execution patterns across them. Leadership had committed to cutting cycle times by a quarter. Nobody could say where that quarter would come from.
Standard reporting showed volumes and closures. It could not show how a request actually travelled, which steps repeated, or why two identical requests finished a fortnight apart. Four things stayed invisible.
Cycle times varied wildly
Some requests closed in days. Others ran for months, in the same product and the same team.
Rework never surfaced
Repeated steps sat inside case records, counted nowhere and owned by no one.
No way to compare products
130 products, no shared baseline, so nobody could tell a good performer from a bad one.
Handoffs crossed systems
Document, KYC and AML steps spanned teams — and two different case systems in two regions.
03 How it worked
Two weeks, and almost none of it the bank's
The bank provided source extracts, scrubbed personal data and approximately two hours of subject-matter support. RE-ViVE handled the data modeling, execution reconstruction and analysis from records the bank was already keeping.
Read the source evidence as it existed
Service requests, activities, assignees and product types were distributed across ServiceNow and OpenText — two systems supporting the onboarding work in different regions — and across 54 underlying tables. The evidence was not delivered as ready-made process flows organized by product or service.
Create a common execution foundation
RE-ViVE mapped records from both systems into a common Execution Data Model, allowing requests across regions, products and services to be reconstructed and compared consistently.
Reconstruct and analyze execution
RE-ViVE reconstructed the observed paths and measured delay, rework, loops and productivity differences — producing 130+ process views, each drillable to the evidence behind a single request.
| 03 Apr 09:12 | Request created | |
| 05 Apr 14:30 | Collect documents | |
| 11 Apr 10:08 | Documents received | |
| 17 Apr 08:55 | Perform KYC tasks | |
| 24 Apr 16:40 | Collect documents | repeat 2 |
| 02 May 11:20 | Documents received | repeat 2 |
| 08 May 09:47 | Send documents for e-sign |
The two highlighted rows are the whole problem in miniature. Asking twice for the same documents added seventeen days, and nothing in the bank's reporting counted it as anything other than a step completed.
04 What we found
What the data showed
The biggest product spent most of its time repeating itself
Account opening was one of the bank’s largest and most critical onboarding services, with 13,685 requests in the period and an average cycle time of 16.62 days. Six of every ten of those days were rework.
Four activities out of twenty-nine carried roughly 70% of it: receiving documents, KYC, AML approval and e-signature. All four are document and verification steps.
96,675of 138,769 total rework days sat in just four activities
A small tail ran for months
Most requests closed inside ten days. 602 took more than fifty, and some ran past two hundred.
Three activities each averaged over ten days on their own inside that population — and all three were already known rework hotspots. Because every delayed request is traceable, the 602 became a work list rather than a statistic.
3,000 observed paths, 46 underlying flows
Those 13,685 requests travelled roughly 3,000 distinct routes. Once repeated and rework steps were separated, 46 underlying activity flows remained, with approximately half identified as candidates for consolidation.
Much of the sprawl was not inherent product complexity. It came from repetition and rework that could be targeted for simplification.
The same product, two very different paths
Online business banking had thirty variations. The dominant one ran 57% of volume through six activities and finished in under three days. Another added a return step and took nearly seven.
Four extra days bought nothing but rework — in the same product, on the same system.
Elsewhere, one wire transfer process repeated ten of its eleven activities inside the same request — nine tenths of a short, well-understood process running twice.
05 What we recommended
Where the time goes back
Five plays, in the order we would take them. Every figure comes from the bank's own records — these are measured opportunities, not results already banked.
Automate the document and verification chain
Start with the transfer steps that need no human judgement.
Take the rework out of four activities
Receiving documents, KYC, AML approval and e-signature hold roughly 70% of all rework days.
Consolidate 46 flows toward 23
Hold new requests to the paths that already work.
Move analysts onto the fast path
The largest variant of each product runs about 50% above expected time. The quick route already exists.
Keep the maps live
Delay, rework and duplication surface as they happen instead of in the next review.
06 Next steps
The opportunity was already in the data
Every number on this page came from records the bank had been keeping all along. RE-ViVE made them measurable, and then made them actionable.
This is Execution Intelligence: reconstructing how work actually executed from the evidence already produced by the enterprise, then exposing where time, effort and complexity accumulate.
Where should we send it?
Tell us who you are and the PDF will download straight away.
We use these details to send you related material and to follow up about Execution Intelligence. We do not share them. See our privacy notice for how we handle your data.