Fresh, reassign, response received: the three I4C case states Indian banks handle differently

The volume split tells you where the work is

Production outcomes at a leading Indian payments bank. Source: caselea.com, 2026.

Reassign is almost as large as fresh. That surprises most people who have not run this queue, because reassign gets treated as the exception pile and staffed accordingly.

It is not an exception pile - it is nearly half the work, and the half where manual effort per case is highest.

Fresh cases: separating routine from exception

The job on a fresh case is mostly triage. Most of them are routine, and a team that treats all of them as equally serious will spend its best hours on trivial cases.

What sits inside the routine bucket is specific: small-value closures, duplicate references, invalid UTRs, hold scenarios and credit-debit reconciliation, among others.

Each of those has a known correct handling. None needs an experienced analyst's judgement. All of them consume an experienced analyst's time when there is no way to separate them from the cases that do.

The genuinely difficult cases still need a person. When evidence is low-confidence or high-risk, the right output is a draft and an escalation, not a guess dressed up as a resolution.

Reassign and response received: where effort climbs

Reassign and response received contain the cases where effort goes up rather than down. Corrections. Confirmations. Reversals. Mismatches. Incomplete bank details.

Each one means the case has already been through the process once and come back carrying a problem.

The work is validation before action. Each case gets checked against the available evidence, and only then does it get decided: correct it, confirm it, hold it, or escalate it. After that it is refilled or resubmitted on the basis of the validated evidence.

That ordering is the whole discipline. A team under backlog pressure tends to act first and validate later, which is exactly how a case ends up back in the reassign pile a second time.

The three states side by side

Why one approach rarely covers all three

A tool built for fresh cases is optimised for throughput. Take a large volume of similar complaints, classify them, handle the routine ones, push the rest to a human.

Point that same tool at reassign and it performs badly, because the task is not classification. It is reconciling what the bank believes against what came back, and the interesting part is the discrepancy.

This is why the three states need three operating models held to one standard, rather than a single classifier pointed at a mixed queue. It is also why a resolution rate quoted for the whole queue tells you very little.

Consistency across users, shifts and volumes

The other benefit of handling all three under one operating model is consistency. The same standard applies across users, shifts and case volumes.

That matters more than it sounds when your queue is worked by different people on different days. Execution quality is largely a function of how many cases each analyst has to get through today, not how good they are.

Whichever state a case starts in, it should end in one of seven named outcomes, with the reason attached to anything left open.

In one Indian banking deployment, between 50 and 60% of cases were handled end to end with no analyst time, and the remainder dropped from about two minutes of manual handling per transaction to under one minute.

What to ask when scoping this queue

Ask for the resolution rate broken out by state rather than a blended number.

A blended figure carried by easy fresh cases will tell you almost nothing about the half of your queue that is actually hard. If a vendor cannot give you the split, they have not run reassign at volume.

The same applies to turnaround. One deployment reported 40% lower turnaround time and 95% backlog reduction, but those came from handling all three states under one standard, not from getting faster at fresh cases alone.

Why reassign volume is a signal, not just a workload

A large reassign pile tells you something about the cases before it, and most teams read it only as a staffing problem.

Cases come back for reasons: a detail was wrong, evidence was incomplete, or the response did not match what was asked. Each returning case is a piece of feedback about how the original was handled.

Treated as a workload, reassign gets staffed and the same cases keep returning. Treated as a signal, the pattern behind them can be fixed upstream so fewer arrive next month.

This is what a categorised exception reason buys you. When every returned case carries why it came back, the top three reasons usually account for most of the pile, and two of them are normally fixable in how fresh cases are prepared.

The operating standard that holds across all three

One rule covers the whole queue regardless of state: validate before you act, and let escalate be a legitimate outcome.

A team under backlog pressure inverts that, acting first so the case leaves the queue today. It returns next week as reassign, so the work was not saved, it was deferred and doubled.

Holding the standard across users, shifts and volumes is what makes the improvement durable rather than seasonal.