Case Management: Tracking Work That Needs Judgement
Case management is how work that needs a person is tracked from arrival to close. A case is not a message and not a task: it carries the file itself, the reason that file stopped, what the system read and what it produced, what the person must supply or decide, its age and who holds it. A queue is stable only while closures exceed arrivals.
A queueThe open cases waiting, whose size is arrivals less closures accumulated over time. is arithmetic before it is anything else. How many cases arrive a day, against how many the desk can finish a day, decides whether the pile in front of the desk is a buffer or a debt, and every design question about case management sits downstream of that one subtraction. The arrival rate is set somewhere else entirely and the desk has no say in it, so everything a case carries exists to move the closure rate. The subtraction reorders the whole subject. The screen, the states, the assignment rule and the ageing report are not administration but the only levers the desk actually holds.
A small clinic with one doctor shows the shape. Patients arrive at whatever rate the neighbourhood produces, and the clinic cannot change that. The clinic can change how fast each consultation goes, whether the file is ready when the patient sits down, and who gets seen next. An exception desk holds the same three choices, and the arithmetic that decides whether the waiting room fills up decides whether a queue of cases fills up too.
Everything below runs on one case. Sumeru Bank Limited, an invented mid-sized Indian bank, runs an intake chain for retail personal loans, and in one steady month 3,010 of its files stopped and went to a person. The stopped files land on an exception desk of seven people headed by Ismail Sheikh.
What is a case, and how is it different from a task or a message?
A caseA unit of work needing a person, tracked from arrival to close with everything needed to work it held in one place. is a unit of work that needs a person, tracked from the moment it arrives until the moment it closes, carrying with it everything required to work it. The last clause is the whole difference. A message says something. A task instructs somebody to do something. A case instructs somebody to do something and hands over the evidence in the same object.
Watch what that changes in practice. A message reading please check the pay slip on this application is perfectly clear to the person who wrote it and almost useless to anybody else. The reader has to go and find the application, find the pay slip, work out what was wrong with it and reconstruct what the sender was worried about. A task adds a holder and a due date and nothing else. A case carries the evidence beside the instruction, and a case is therefore the only one of the three that a second person can pick up cold.
The difference is visible in an ordinary household. A note on the fridge saying call the electrician is a message. A note saying call the electrician by Thursday, and naming whose turn it is, is a task. A note saying call the electrician by Thursday, the fault is the kitchen socket, it tripped twice on Sunday, and here is the last bill with the number on it, is a case. Only the third one survives the person who wrote it going away for a week.
What makes a case different from a task?
What does a case have to carry for the person picking it up?
Seven fields, and Sumeru numbers them so that a screen change can be argued about without anybody guessing what is meant. The numbers do real work below, so the numbering is worth holding on to. 1 the file. 2 the cause. 3 what the component read. 4 what it produced. 5 what the person must supply or decide. 6 the age of the case. 7 who holds it.
Field 2 draws on the six numbered causes the bank already uses for every file that stops. The list runs from a document field that could not be read with enough confidence, through income that could not be corroborated, a fraud rule firing, a score inside the referral band, an identity record that did not match, to a consent record that was incomplete. Where those six causes come from is settled separately. Field 2 holds one of them, and the cause tells the person what kind of work this is before they have opened anything.
| No | The field | What it holds | What it buys |
|---|---|---|---|
| 1 | The file | The application the case belongs to | Ties the work to the thing being decided |
| 2 | The cause | One of the six numbered causes | Says what kind of work this is |
| 3 | What the component read | The input it was working from | Lets a fault be placed later |
| 4 | What it produced | The output it returned | Gives the person something to accept or overrule |
| 5 | The ask | What the person must supply or decide | Turns a record into work somebody can pick up |
| 6 | The age | How long the case has been open | The one field that moves on its own |
| 7 | The holder | Who has it now | Stops it being worked twice, or never |
Field 6, however, behaves unlike the other six. Every other field is written once and then sits there. The age changes whether anybody touches the case or not, and no other field can deteriorate while everybody is doing their job properly. Ageing therefore gets a report of its own below, and the other six fields get nothing.
Why are the third and fourth fields the ones people forget?
Because they look like duplication. The output is already in the system somewhere, the input is already in the document store somewhere, so a screen designer under time pressure copies neither into the case and links to both instead. Linking rather than copying is a reasonable-sounding decision, and it quietly removes the only thing that made the case portable. Six months later the document store has been reorganised, the link is stale, and a case that was supposed to be a self-contained record is a pointer to nothing.
There is one test that settles a case screen argument, and it is whether a second person could pick this case up cold and continue it. Not resolve it, not agree with it, just continue it. If the record does not say what the component was looking at and what it came back with, the honest answer is no, and everything else on the screen is decoration. Ismail Sheikh made this test the entrance requirement for any change to the desk's screen. The rule costs nothing and works unusually well.
There is a second reason these two fields matter, and it only shows up much later. With field 3 and field 4 both recorded it is possible to ask, months afterwards, whether the component read the document wrongly or the document itself was wrong. Without field 3 only the output is visible, and a wrong output has two completely different explanations that no amount of staring will separate. One is a fault in the reading. The other is a fault in what arrived. The two faults need different fixes, and exactly one field tells them apart.
What five states does a case move through, and who moves it?
Five, numbered, and the numbering matters because two of them are not the desk's to shorten. 1 open, meaning the case is with the desk and workable now. 2 waiting on the customer, meaning somebody has been asked for a document or a confirmation. 3 waiting on another desk, meaning a question has gone to credit or to operations. 4 decided, meaning the person has reached an answer. 5 closed, meaning the answer has been written back to the file and the case is done.
States 2 and 3 are the two where the case is open, the clock is running, and nobody at the desk can do anything about it. The distinction is not a technicality. A desk that reports one ageing figure covering all five states is reporting the customer's response time and another team's queue as though they were its own throughput, and it will look slow at exactly the moments it is not. A reviewer who wants a case off their ageing report can push it into state 2 with a routine question, and the clock stops being anybody's problem. The desk then looks fast in the worst possible way.
So the ageing report at this desk is split. Time in states 1, 4 and 5 is the desk's own. Time in states 2 and 3 is reported beside it and never inside it. A case waiting six days on a customer is still a case the customer is experiencing as six days, so both figures are shown. Hiding the second would be its own kind of dishonesty.
Which of the five states are outside the desk's control?
How is work assigned, and what does each assignment rule cost?
AssignmentThe rule deciding which person picks up which case, and therefore which cases wait. is the rule deciding which person picks up which case, and a desk always has one whether or not anybody wrote it down. Three rules are common. Each is right somewhere, and the second half of that is the part people skip. Assign oldest first. Assign by cause, so the same reviewer keeps meeting the same kind of work. Or assign by whoever is free, the default a desk falls into when nobody has decided anything.
Oldest first protects the tail. The case that has been waiting longest is worked next, so nothing can quietly rot, and a turnaround commitment has something behind it. Oldest first gives up practice. Every reviewer meets every one of the six causes, and nobody becomes quick at any of them. Assigning by cause buys that practice back: a reviewer who has worked forty unreadable-field cases this week is faster on the forty-first, and handling time falls through repetition rather than through any change to the system.
No rule in it ever points at the oldest case, so assigning by whoever is free maximises how busy everybody looks and protects nothing at all. Every reviewer takes the case in front of them, usually the newest one, and an awkward case gets passed over every time somebody scans the list. A desk with a perfectly respectable average then produces a handful of cases that have been open for a fortnight. Nobody chose that outcome. Choosing nothing produces it.
A desk assigns by whoever is free. What has it chosen not to protect?
What makes a queue stable, and what makes it grow?
One subtraction. The arrival rateHow many cases reach the desk a day, which is set upstream by volume and by the components rather than by the desk. is how many cases reach the desk a day, and it is set upstream by application volume and by how often files stop. The closure rateHow many cases the desk can finish a day, being its people multiplied by their available minutes, divided by the handling time a case. is how many the desk can finish a day, being its people times their available minutes divided by the time a case takes. Subtracting the first from the second gives the marginClosures less arrivals: how much extra volume the desk can absorb in a day before the queue starts growing..
While the margin is positive the queue drains. The moment the margin turns negative the queue accumulates without any limit at all, and a queue therefore does not degrade smoothly as volume rises. It turns. Below the crossing, extra volume eats into a buffer and the buffer refills. Above it, every day adds to a pile that no later quiet day is scheduled to remove, and the wait grows for as long as the condition lasts. There is no self-correcting mechanism in a queue. There is only the subtraction.
The everyday version is a kitchen sink. Water in, water out, and while the drain is faster than the tap the level falls no matter how full the basin looks right now. Open the tap two per cent past the drain and the basin does not fill two per cent faster. The basin fills, and keeps filling, until somebody turns the tap down. Nothing about the basin decides the outcome. The two rates do.
How much margin does this desk actually have?
Work it in two columns and it takes four lines each. On the arrival side, 3,010 exceptions in a month over 20 working days is 150.5 cases arriving a day. On the closure side, seven people at an assumed 420 minutes a day is 2,940 desk minutes, and at a handling timeMinutes of hands-on work a case takes. At this desk it rose to 19 minutes once the easy files stopped arriving. of 19 minutes a case that is 154.7 cases closed a day. Subtract. The margin at this desk is 4.2 cases a day.
| The line | The figure |
|---|---|
| Exceptions in the month | 3,010 |
| Working days in the month | 20 |
| Arriving a day | 150.5 |
| People on the desk | 7 |
| Minutes each a day, assumed | 420 |
| Desk minutes a day | 2,940 |
| Handling time a case, minutes | 19 |
| Closed a day | 154.7 |
| Margin a day | 4.2 |
Now the part that gets misquoted. The 4.2 has two denominators and they are different statements. Dividing 4.2 by the 154.7 the desk can close gives 2.7 per cent, the share of the desk's capacity sitting spare. Dividing 4.2 by the 150.5 actually arriving gives 2.8 per cent, the extra volume that can arrive before the queue turns. Both are correct and they are not the same number. A sentence quoting one of them without naming its denominator has not communicated anything. The crossing is about arriving volume, so the figure that names it is the second, 2.8 per cent.
Convert the margin into something concrete. Four point two cases a day at 19 minutes is about 80 minutes a day of slack, roughly 1,600 minutes over the month. Against the assumed working month of 8,400 minutes a person, 1,600 minutes is about a fifth of one post. At the bank's assumed fully loaded Rs 9,00,000/- a post that is about Rs 1,70,000/- a year of headroom on a desk of seven. A fifth of a post is the entire buffer between a desk that drains and a desk that accumulates.
The margin is 4.2 cases a day. Is that 2.7 per cent or 2.8 per cent?
What does that margin mean for the turnaround commitment?
Start with the queue that is already there. The exception desk holds about 285 open cases at any moment, and at 154.7 closed a day that is 1.84 working days of work standing in front of it before a single new case arrives. The bank commits to deciding within 2 working days, with the clock starting when a file reaches the decision engine. The desk therefore begins every morning with about 92 per cent of its promise already spent on work it has not started.
Sit with that for a second. The standing queue is what makes the margin the number that matters rather than a comfortable detail. A desk with 0.5 working days of standing queue could absorb a bad week and never breach anything. A desk with 1.84 has almost nothing between it and the commitment, so the margin is not a nice-to-have buffer. The margin is the only thing preventing a breach, and the margin is 4.2 cases a day.
In the month measured, 310 files missed the 2 working day commitment out of 8,600 decided, so the bank hit 96.4 per cent against its own commitment of 95. The number reads like a comfortable pass. Look at where the 310 sat and it stops being comfortable: every one of them was an exception file, being 310 of the 3,010 that went to a person, or 10.3 per cent of everything the desk touched. Nothing about any component was wrong on those 310 files. They queued.
The desk was sized on an average, and nobody computed the margin
The sizing was not careless. Somebody took 3,010 exceptions, 19 minutes each, 420 minutes a person and arrived at seven people, and the average was correct. The spare capacity, 4.2 cases a day, was never written down anywhere. A week carrying 3 per cent more volume than the month average puts arrivals at about 155 a day against a capacity of 154.7, and the queue stops draining and starts growing.
Because the queue already holds 1.84 working days of work, it does not take much growth before cases begin breaching 2 working days, and the breaches then appear on a service report as a turnaround problem rather than a capacity one. The service report carries reading accuracy, classifier accuracy and fault counts, all of them fine, and it does not carry the margin. A desk sized on the average with no margin recorded has a service level that is a function of the weather, and the report that surfaces the breach will be pointing at the wrong thing.
310 files breached the 2 working day commitment and every component behaved correctly. Where is the cause to be found?
Before the control below is moved: volume rises 5 per cent and stays there for a month. Does the queue stay inside the 2 working day commitment?
Move the arriving volume, and watch the queue stop draining
One input moves: how much volume arrives, as a change on what this month actually carried. Capacity is held fixed at 154.7 cases a day. The line redraws the open cases across 20 working days, the scale on the left redraws with it, a lime marker appears on the working day the wait first passes 2 working days, and the bar underneath redraws the wait a case would face at month end.
On the volume this month actually carried, 150.5 cases arrive a day against 154.7 closed, so across 20 working days the queue drains from 285 open to about 200 and a case arriving at month end waits 1.29 working days, comfortably inside the 2 working day commitment.
Why does the queue turn at 2.8 per cent but only breach at 3.6?
Moving the control slowly meets two different thresholds, and confusing them is easy. At plus 2.8 per cent arrivals equal capacity, so the queue stops draining. Arrivals equalling capacity is the turn. But a queue that has merely stopped draining is still sitting at 285 cases, still 1.84 working days, still inside the commitment. Nothing has broken yet.
Two working days of wait at 154.7 closed a day is 309 open cases, so the breach needs the queue to climb from 285 to about 309. Adding 24 cases inside 20 working days means growing the queue by at least 1.2 a day. Growth of 1.2 a day needs arrivals of about 156.0, roughly 3.6 per cent above the month's actual. The queue turns at plus 2.8 per cent and the commitment breaks at about plus 3.6 per cent, and the eight tenths of a percentage point between them is the entire warning the desk gets. Both crossings are arithmetic on the desk's own locked figures rather than a measured reading.
The gap leaves a window in which everything looks fine and the queue is already growing. The service report is green, the average handling time is unchanged, nobody is behaving differently, and the pile is getting taller. The only instrument that shows the growth is the count of open cases day by day. A desk that reports throughput and not standing queue has no early warning at all.
Why does the oldest case matter more than the average one?
Because the average is a mechanical consequence of the queue length and says almost nothing else. Worked strictly in order, the 285 open cases have ages spreading evenly from just-arrived to 1.84 working days, so the mean age lands at about 0.92 of a working day, call it about one. A mean of about one working day comes out of the queue length and the closure rate, and the mean stays at about one whether or not a dozen cases have been sitting for a fortnight. The mean age is exactly the statistic that hides the cases that will breach.
AgeingHow long each open case has been waiting, reported as a distribution across buckets rather than as a single mean. therefore has to be reported as a distribution, bucket by bucket, with the oldest bucket named and its oldest case stated. Two desks can show the same mean and be in completely different conditions. One has everything moving through in order. The other has almost everything closing in an hour and twelve cases nobody has touched in a fortnight, and only the second desk is about to appear on a complaints report.
The same effect appears in a hospital waiting room. The average wait can be twenty minutes while one person has been sitting there since morning, and the person who has been there since morning is the only one who is going to complain, escalate, or be genuinely harmed. Averages describe the room. Tails describe the incidents.
The mean age of open cases is about one working day. What does that say about the oldest one?
What does a case record owe an audit trail?
A case at this desk is the record of a person taking a decision on an automated output, and that is a specific thing to have to evidence later. The record has to show what the component produced, what the person did with it, and when. Field 4 gives the first. The close of the case gives the second. Field 6 and the state history give the third. Without field 3, the input the component was working from, the record can show that somebody disagreed but never why the disagreement was reasonable.
Field 3 is not there for the reviewer working the case, who is looking at the document anyway. Field 3 is there for the reviewer of the reviewer, six months later, trying to establish whether a wrong outcome came from a component reading a clear document badly or from a document that was genuinely unreadable. The two findings lead to completely different actions, one to the component and one to the document supply, and exactly one field separates them.
Where these cases carry lending decisions at a regulated lender, the expectations on record keeping, outsourcing and internal control are set by the Reserve Bank of India and published at rbi.org.in, and the current position there governs. The mechanics of case management are universal and hold whatever the regulator; what the record has to be kept for, and for how long, is not.
Why must the case hold what the component read as well as what it produced?
How does somebody outside the desk actually use this?
With two divisions and one subtraction, on numbers any operations report already carries. The volume reaching the desk divided by working days gives the arrival rate. People times available minutes divided by handling time gives the closure rate. The difference between them is the margin, and a percentage drawn from that margin names the denominator it used. The standing queue divided by the closure rate then shows how much of the commitment is already spent.
What a lender, an auditor or an operations head does with it
An operations head reading a proposal for a new automated step asks one question the proposal will not answer: what is the margin on the desk that absorbs whatever this step sends to a person, and where is it written down. A business case that promises a straight-through rate and says nothing about the residual desk has costed half the change.
An internal auditor reviewing a service level breach starts at the queue rather than the components. If every component reading is inside tolerance and files still missed, the breach is a capacity finding, and the recommendation is to record and monitor the margin rather than to retune anything.
An analyst reading an operations disclosure treats a reported average handling time as a description of the room and the ageing tail as a description of the incidents. If the tail is not disclosed at all, the average is the only thing on offer and it is the weakest of the two.
A household running its own version of this recognises the shape immediately. One person handling all the paperwork for four people has an arrival rate they do not control, a closure rate set by their evenings, and a pile on the shelf that is the standing queue. The month the arrival rate rises slightly is the month the pile stops shrinking, and nothing about that month feels different while it is happening.
Sources and how to check them
| Source | What it covers | Site |
|---|---|---|
| Reserve Bank of India | Expectations on a regulated lender covering internal control, outsourcing, record keeping and digital lending, the home of the conduct duty behind a case record | rbi.org.in |
| Securities and Exchange Board of India | Expectations where the institution running such a desk is a market intermediary | sebi.gov.in |
| Bank for International Settlements | International supervisory material on the deployment of such systems by banks, as the origin of the international position | bis.org |
| Ajay Agrawal, Joshua Gans and Avi Goldfarb, Prediction Machines, 2018 | The framing of an automated component as a producer of predictions a person still has to act on, the shape of every case on this desk | Harvard Business Review Press |
Sumeru Bank Limited and Ismail Sheikh are invented.
Educational material. Not advice on any investment, tax, budget or market position.
