In short
An Indian bank case queue is not a handful of common requests plus noise. One measured queue held 16,736 cases spread across 189 distinct scenarios, and the largest single scenario was 9.9% of volume.
Half the queue sits outside the top ten scenarios. That shape is why a top-five pilot succeeds and the production rollout stalls, and you can measure it yourself before talking to any vendor.
The shape of a real queue
Scenario breakdown from one Indian banking operation, 2026.
Most people expect a small number of common requests plus some noise. What turns up is a long, flat curve, and no SOP written in advance anticipates all of it.
The coverage curve, scenario by scenario
| Scenarios | Share of all cases |
|---|---|
| Top 1 | 9.9% |
| Top 3 | 24.3% |
| Top 5 | 33.7% |
| Top 10 | 48.2% |
| Top 20 | 67.4% |
| Top 50 | 87.5% |
Ten scenarios cover 48.2%. The other 179 cover the rest.
This is the number that breaks most automation business cases. A vendor demos the top five scenarios, which look like a third of your volume, and the pilot succeeds. Then it meets the other two thirds and the resolution rate collapses, because those cases were never in scope and nobody said so out loud.
Get to 50 scenarios and you have 87.5% covered. That is the real scope of the job, and it is roughly ten times bigger than the demo suggested.
The tail is where the risk lives
Seventeen scenarios occurred exactly once in the period. Forty-one scenarios had five cases or fewer, and together those 41 account for just 90 cases.
It is tempting to write that off. Ninety cases out of 16,736 is half a percent.
But a case does not become less consequential because it is rare. A single freeze that should not have happened, or one LEA request answered wrongly, costs more than the ninety routine cases saved elsewhere.
The right handling is to route them to a person with the reason attached, rather than forcing an answer. Every exception carries its category, so the tail stays visible and measurable instead of becoming an unexplained pile.
We do not sell generic chatbots or AI agents that freely reason over sensitive processes.
Why a single general approach fails on this shape
Point one general process at this queue and it has to work out, from scratch, which of 189 situations it is in and what the correct handling is. Every time.
It will be right most of the time on the top ten, because those are well represented and distinctive. It will be unreliable across the rest, and you will not be able to tell which is which without reading every case.
The published evidence supports deciding in advance. Across roughly 10,000 runs and 150 outcome scenarios, defined steps reached 93% coverage and 82% success, against 79% and 71% for an open-ended approach on the best available model.
What coverage actually costs
The alternative is to decide the correct handling for each scenario in advance, where it can be reviewed and signed off, rather than leaving it to be worked out case by case at the moment of decision.
That sounds like a lot of work until you look at the curve. Against 189 scenarios, it is simply what coverage costs.
In one deployment, 76 resolution scenarios were codified as workflows, and 637 improvements were deployed against them over time as the operation changed.
How to look at your own queue
You can run this analysis before talking to any vendor, and it is the most useful hour you will spend on the problem.
- Export a month of cases and group them by scenario, not by team or by status.
- Work out what share the top ten hold. If it is near half, a top-five pilot tells you very little.
- Count the scenarios with fewer than ten cases. That is your escalation design problem.
- Ask any vendor for a resolution rate by scenario, not a blended figure.
A blended number carried by two or three easy high-volume scenarios will look excellent and change nothing about your backlog.
What the curve tells you about pricing
There is a commercial point hiding in this curve. If half your volume sits in the tail, seat-based pricing charges you for the people you still need, and platform pricing charges you whether or not the tail gets covered.
Pricing tied to execution is the only model that lines up with the shape of the work, because it only costs you when a case is actually handled.
This is the analysis CaseLEA starts with on any new operation - until you know the shape of the queue, nobody can tell you what coverage is worth.
What the curve means for a pilot design
Most pilots are designed to succeed, which is why so many of them do and so few of them scale.
If the top five scenarios are 33.7% of volume, a pilot scoped on them will report a high resolution rate and tell you almost nothing about production. The honest design includes tail cases deliberately, even though they lower the headline number.
A useful split is roughly two thirds head and one third tail. The head proves throughput. The tail proves what happens when the system does not recognise the situation, which is the behaviour you are actually buying.
Ask for exception handling to be demonstrated on a case nobody prepared for. A vendor who cannot show that has only shown you the easy third.
Why the tail grows rather than shrinks
There is a structural reason this curve does not flatten over time.
New scenarios arrive whenever a product changes, a rule changes or a portal behaves differently. One deployment deployed 637 workflow improvements against 490k workflow runs, and a good share of those exist because something new turned up in the tail.
So coverage is not a one-time project with a finish line. It is a rate: how quickly a new scenario goes from unrecognised to handled properly. That rate, more than today's resolution percentage, decides where your backlog is in a year.
Sources
- Scenario breakdown from one Indian banking operation, 2026: 16,736 cases, 189 scenarios, coverage curve.
- Patched, published benchmark, 2026: 10,000 runs, 150 outcome scenarios.
- caselea.com, 2026: 76 resolution scenarios codified, 637 improvements deployed.
