Northwind Mutual: Every Claim Is Urgent, So Nothing Is
Northwind Mutual opens about 4,200 auto claims a month. Every claim runs through one case type whose first assignment routes to a single work queue, ClaimsIntake, with no skills required. On creation, a data transform sets urgency to the literal value 10 for every claim. The assignment's service level has a 4-hour goal, an 8-hour deadline, and an escalation action that transfers the assignment back to ClaimsIntake. Managers report three symptoms: total-loss claims sit untouched behind routine glass claims, the SLA dashboard shows 71% of intake assignments breached last quarter, and hiring eight temporary adjusters in Q3 made no dent in the backlog. The dashboard is built on each assignment's own goal and deadline times, not on the case's stage duration.
1. The design intends urgent claims to have high urgency (10), yet they are not picked first. Explain what actually determines which assignment an adjuster gets next, and what you would change.
Read the worked answer
What actually drives selection
Get Next Work looks at what the operator is eligible for, in this order: assignments routed directly to that operator, then items on work queues reachable from the operator's access group/work group (filtered by any skill requirement). Within each bucket, the highest urgency wins, and when urgencies tie the tiebreaker is age - the oldest assignment is served first.
Because every claim is set to exactly 10, there is nothing to rank. Every claim ties, so the queue degenerates into pure FIFO by assignment create date. Total-loss claims are not older than the routine claims queued ahead of them, so they lose.
The compounding bug
The literal assignment of 10 is not just differentiation-free, it is actively destructive. Service levels raise urgency as the goal and deadline approach - that is how an aging claim climbs the queue. A data transform that rewrites urgency to 10 flattens the only signal that would have made an old claim outrank a fresh one. Verify when the transform runs; if it runs on open or on every assignment creation, aging never survives.
The fix
- Compute urgency from business drivers - severity, total-loss flag, policy tier, regulatory clock - in a declare expression or a one-time data transform on case creation, not a literal.
- Spread the values so ties are rare (e.g., 60 / 40 / 20 rather than 10 / 10 / 10).
- Stop overwriting urgency after creation so service-level increments can accumulate on top of the business baseline.
- Prove it: create a high-severity claim and an older routine claim, then preview Get Next Work for an adjuster in that queue and confirm the high-severity claim is offered first.
2. Eight additional adjusters did not reduce the backlog. What does that tell you, and where would you look before hiring anyone else?
Read the worked answer
Capacity added at a step that is not the constraint produces no throughput gain. The backlog is therefore accumulating somewhere other than intake, or intake work is not reaching the new staff at all.
Look for these, in order
- A downstream constraint. Intake agents may be completing their assignments quickly while work piles up at, say, appraisal or payment approval, staffed by four specialists. Intake looks healthy; overall case age grows. Chart work in progress and cycle time per assignment and per queue, not per case type.
- Eligibility, not capacity. If the work queue is not reachable from the new adjusters' access group/work group, or the queue now requires a skill they were not given, Get Next Work returns nothing for them. The tell is eight idle people and a deep queue at the same time. Compare queue depth against assignment inventory and confirm access for one new user.
- Recycled work. The escalation transfers overdue assignments back into the same queue. That resets routing, may reset the assignment's create timestamp, and inflates queue depth with work that has already consumed time - which also explains a 71% breach rate concentrated in assignments that bounced.
- Hidden rework. Claims returned for missing information re-enter intake and are counted as new work.
Fix the constraint. If the downstream team is the limit, add there, or remove the step (auto-approve below a threshold) rather than adding intake staff.
3. Redesign the service-level escalation. Be specific about what is wrong with the current escalation action and how you would model and measure the replacement.
Read the worked answer
Why the current escalation is a no-op
Transferring the overdue assignment back to ClaimsIntake puts it into the same pool, under the same urgency logic, for the same people. Nothing about the case's priority changes; if anything it gets worse, because the transfer can reset the assignment's create timestamp so the work appears younger than it is, and because a transferred assignment may land behind work it was already ahead of.
What to build instead
- Two-stage escalation. At goal: raise urgency and notify the case owner and their manager. At deadline: transfer to a supervisor queue whose access group includes supervisors and excludes the general intake population, or assign to the team lead directly.
- Fire once. Escalation must be idempotent. Store a flag or timestamp on the case and guard the escalation action so a case that sits overdue for three days does not get re-escalated on every interval.
- Escalate with context. The supervisor picking up an escalated assignment needs to see why it is late - age, prior transfers, blocking dependency - so carry that onto the assignment or into the review screen.
- Put the clock where the work is. If the commitment is "claim triaged within 4 hours of creation," that is a start-to-finish commitment independent of who holds the assignment. An assignment-level SLA restarts when the assignment is reassigned. Attach the commitment to the stage or to the case so the measurement survives transfers.
Measurement
The dashboard currently uses assignment goal/deadline times, which is why it is both inflated by transfers and silent on stage duration. Report on stage duration and on case elapsed time, with a separate breakdown for assignments that were escalated, so you can tell whether escalation is actually recovering cases or just moving them.