Triage the queue: what to work next when the backlog is winning

1. Before you start

Triage is sorting a pile of waiting work by how much it matters and how soon, so you handle the right item next instead of just the next item. A queue under overload is any backlog where more work arrives each day than the team can finish, so the pile grows no matter how hard everyone works — and the only lever you control is the order you work it.

A tiny example. Two requests are waiting and you have time for exactly one right now. Request A takes 5 minutes and, if it is late, costs nothing. Request B takes 30 minutes and, if it is late, cancels a booked procedure and wastes the slot. “Whoever came first” or “the quick one first” might point you at A. Triage points you at B, because a late B is expensive and a late A is free. Ordering by cost-of-delay, not by arrival, is the whole idea.

Three honest statements before you start:

This is a Decide course. You read a situation, learn the idea, and make a call. You do not write or run any code.
The organisation in the case, Rivergate Community Health, is a composite — an invented healthcare provider built from ordinary, realistic back-office dynamics. No number or claim here describes any real company.
This is not a certification. It proves, to you, that you can sequence a backlog under load and defend your order.

This is an operations lesson about sequencing work items when demand outruns capacity. It is not clinical advice, and no scenario here asks you to make a care decision about a patient.

2. The Situation

Rivergate’s authorisations desk — the back office that clears insurance pre-authorisation requests before a procedure can go ahead — now takes in more requests each day than it can process, and the backlog grows. Each morning the new desk lead must decide what order to work the pile in, knowing a wrong miss cancels a booked procedure: a lost theatre slot and a day of rework. Choose badly and the desk stays busy while the expensive misses pile up.

3. What you’ll be able to do

After this course you can:

Sequence a backlog by urgency and impact, and say why plain first-in-first-out ordering loses money once demand outruns capacity.
Decide when to clear the quick items first (shortest-processing-time) and when a hard deadline or a high cost-of-delay overrides that.
Spot and resist the two reflexes that wreck a queue under load — “oldest first is only fair” and “work whoever shouts loudest” — and protect capacity for the critical few over the trivial many.

4. Prerequisites & time box

Prerequisites: none beyond ordinary work reasoning. No operations background, no spreadsheet, no code setup — the Decide hall is read-and-decide in the browser. This is an early course in the operations track and assumes no prior Decide course.

Time box: about 21 minutes of reading (measured), plus your own thinking time on the call. Under the 25-minute cap for a concept course.

Difficulty: 3 / 8 — a new-manager decision: a couple of interacting factors and one real judgment call, where the obvious answer is often the trap.

Free-tier honesty: no signup, no paid tool, requires_gpu: false.

5. The case & where the numbers come from

Rivergate Community Health is a composite organisation: an invented healthcare provider whose authorisations desk and every figure attached to it are in-course assumptions, not drawn from or claimed about any real firm. The ideas used — triage, priority queueing, shortest-processing-time scheduling, context-switching cost, and the vital-few principle — are standard operations concepts, cited in section 11. The word triage is borrowed from emergency medicine, where it names the sorting of arrivals by need; this course applies the same sorting logic to a queue of administrative work items, not to patient care.

Here is one morning’s backlog. The desk clears roughly six hours of work a day while about eight hours arrives, so the queue grows and the order you pick decides which misses you avoid. Every figure below is an in-course assumption:

Request	Procedure booked in	Time to process	Cost if it misses the deadline
A — surgical pre-authorisation	1 day	~40 min	High: surgery cancelled, theatre slot lost, full rework
B — imaging authorisation renewal	12 days	~10 min	Low: resubmit later, nothing lost now
C — routine specialist referral	20 days	~8 min	None soon
D — specialist pre-authorisation	2 days	~35 min	High: appointment cancelled, rework
E — batch of six medication renewals	15 days	~5 min each	None soon

These attributes per request — a deadline, a processing time, and the cost of a miss — are the only case data. Everything the course concludes is reasoned from this table.

6. The Concepts

This is a judgment course; the ideas build in the order you use them at the desk, each applied to Rivergate as we go. The call is a judgment, not a formula, so this course carries no calculator.

Triage sorting by urgency and impact

Triage sorts waiting work on two attributes at once:

Urgency — how soon the deadline bites. Request A is due in one day, request C in twenty. Urgency is about when, not how bad.
Impact — how large the cost of a miss is. A missed A cancels surgery and wastes a theatre slot; a missed B is resubmitted later at no real cost. Impact is about how bad, not when.

Score both and you get a simple 2x2. Urgent and high-impact (A, D) is do-now work. Not urgent but high-impact you schedule deliberately so it never becomes a crisis. Urgent but low-impact you clear cheaply when it is quick. Neither you defer or batch. This morning A and D sit in the do-now corner — near deadlines and expensive misses — while B, C, and E are low-impact and days away, so they wait. Either axis alone misleads: sort by urgency only and you sprint on a due-tomorrow renewal that costs nothing; sort by impact only and you polish an item weeks away while a cheaper one breaches today.

Assumptions and limits. Urgency and impact are estimates. Triage’s common failure is urgency inflation — when every requester marks their item “urgent,” the signal collapses. It needs a shared definition of impact (cost of the miss, not volume of the complaint) or it reverts to whoever labels loudest.

Why FIFO fails under overload

First-in-first-out (FIFO) works the oldest item first. It feels fair and, when capacity exceeds demand, it is fine — the queue drains, so order barely matters. The trouble is specific to overload, when the queue no longer drains.

Under overload, arrival order is uncorrelated with urgency or impact. A low-impact renewal that arrived at 8am blocks a high-impact surgical authorisation that arrived at 9am, so you predictably miss the expensive deadlines while protecting the cheap ones. FIFO is not neutral here; it optimises the wrong thing — which is why scheduling systems offer a priority queue, served by a priority key rather than arrival, when items differ in what a delay costs.

Assumptions and limits. FIFO’s real virtue is that it cannot starve anyone. A pure priority scheme has the opposite risk, so mature queues bound FIFO — an item’s priority rises the longer it waits (aging). The lesson isn’t “FIFO is wrong,” it’s “FIFO is the wrong default under overload when items differ in cost-of-delay.”

Weighted shortest processing time

Shortest-processing-time (SPT) ordering — quickest jobs first — minimises the average wait and clears the largest number of items fastest. But SPT is blind to value: it will finish ten trivial items before one important slow one. Weighted shortest processing time (WSPT) fixes this by ranking each item on value divided by processing time — the payoff per minute — highest first: spend every scarce minute where it averts the most cost. At Rivergate, A takes 40 minutes but averts a very expensive miss, so its avoided-cost per minute keeps it near the top; among the low-stakes items, do the 5-minute renewals before the 8-minute referral. So the rule is layered: impact sets the tier, and inside a tier the quicker item goes first.

Assumptions and limits. WSPT is a heuristic, not an optimum — its guarantee assumes one worker and known times with no deadlines. So a hard deadline overrides it (a due-today item beats a higher-payoff item due next week), and the ranking is only as good as your estimates of value and time.

The cost of context switching

Every jump between dissimilar tasks carries a hidden switch cost — reloading context, re-reading the case, re-opening a different system. It compounds: task-switching measurably slows work and raises errors. Under load the reflex is to grab whatever is loudest, which maximises switching and shrinks how much the team clears.

Batching similar items defeats this. Handle all six medication renewals in one sitting and the processor pays the switch cost once, not six times — the same team clears more per hour. So sequencing is also about grouping: triage sets the tiers, and inside a tier you batch by type.

Assumptions and limits. Batching trades latency for throughput: the first renewal waits for its batch, so you never batch the top-urgency item — the surgical authorisation doesn’t sit in a queue to fill a batch. The rule is asymmetric: expedite the critical few, batch the trivial many.

Protecting the critical few

A small share of items carries most of the downstream cost — the vital few against the trivial many (the Pareto pattern). At Rivergate a handful of near-deadline, high-impact authorisations hold almost all the money and rework at risk; dozens of routine renewals hold almost none.

Under overload the failure is drowning: the trivial many consume the whole day and one of the critical few slips through. The defence is to protect capacity for the critical few — reserve part of the day for high-impact arrivals and route the routine bulk into a batch lane — so an expensive request is never stuck behind the pile because it arrived later. Identify that few by impact, not by volume and not by who complains: the squeaky-wheel reflex hands scarce capacity to salience, and the loudest requester is often the cheapest miss.

Assumptions and limits. A reserve you never use is waste, so size it to the real arrival rate of high-impact work and let unused reserve fall back to the batch lane — which still has to move, or the trivial many age into a second crisis.

7. Your Call

You have sequenced one overloaded queue from a standing start. Now a different one lands on your desk — in a different industry, with a contract clock and a loud customer attached.

Northwind is a composite business-software company whose customer-support desk now takes more tickets each day than the team can resolve. Two wrinkles that Rivergate did not have: some tickets carry a contractual service-level agreement (SLA) with a financial penalty if the response clock is breached, and one large enterprise account is emailing hourly demanding a cosmetic fix “right now.” The support lead has to decide what to work next.

Every figure below is an in-course assumption for this transfer case:

Ticket	SLA / deadline	Time to resolve	Cost if it slips
T1 — production outage, top-tier SLA	breaches in ~30 min	~25 min	High: SLA penalty plus real churn risk
T2 — “how do I export a CSV?“	no SLA	~4 min	None
T3 — enterprise account emailing hourly, cosmetic button colour	no near deadline	~20 min	Low real impact; loud
T4 — batch of five password-reset requests	soft, none urgent	~3 min each	None, but volume
T5 — data-import failure, mid-tier SLA	breaches in ~4 hours	~45 min	Moderate: smaller SLA penalty

How this differs from the taught case — the transfer. This is a different company and sector (business-software support, not a healthcare back office) with different figures to re-read; it asks a different decision type (what to work next against a live SLA penalty clock); and it adds a new constraint the taught case lacked — a contractual penalty plus one customer applying loud pressure. The core concept is the same: triage a queue under overload.

8. Self-check

Before the memo, make sure you can say each of these in one line, without an answer key:

State your call in one sentence: at Northwind, what do you work first, and what runs next?
Name the one axis — urgency or impact — that keeps the loud T3 out of your scarce now, and the fact about T3 that proves it.
Name the single change that would flip your ordering (say, T5’s SLA breaching in ten minutes instead of four hours, or a real penalty appearing on T3).
Say what strict oldest-first and working the loudest ticket would each cost Northwind — breached SLAs and cancelled-slot-style rework.

If any is fuzzy, reread section 6 — the two axes, the FIFO-under-overload trap, and protecting the critical few are the whole course.

9. Stretch

Push the thinking further on your own:

The desk keeps missing SLAs no matter how it sequences, because arrivals exceed capacity every day. Sequencing decides which items slip; it cannot drain the backlog. When does the honest call stop being “sort better” and become “add capacity, shed scope, or renegotiate the SLA”? Name the signal you would watch. (The genuinely hard one — spotting a capacity problem in disguise.)
Two tickets are tied on both urgency and impact but one is far quicker. Which goes first, and what principle from section 6 breaks the tie?
Write the single sentence you would give the team as their standing “what do I work next” rule, and the one exception that overrides it.

10. Ship it — your decision memo

Write a one-page memo to Northwind’s support lead. State the call: work the SLA-breaching outage T1 first; then drain the quick no-stakes items while T5 still has margin; batch the routine resets; acknowledge and schedule the loud T3 without letting it jump the queue; and reserve daily capacity for high-impact and SLA work. Give the reasoning in a few lines — urgency and impact set the order, shortest-processing-time breaks ties inside a tier, a hard deadline overrides, and switch cost is why you batch the trivial many. Name what you rejected (strict oldest-first; working the loudest account; chasing raw close-count) and the one thing that would change your mind (a nearer SLA breach elsewhere, or a real penalty on T3). Keep it to one page — your own argued claim, not a credential.

11. Sources

Rivergate Community Health and Northwind, and every figure attached to them — deadlines, processing times, and cost-of-miss ratings — are composite: invented from ordinary, realistic dynamics for clean teaching, not drawn from or claimed about any real organisation. No figure here describes a real firm. What is cited below are the standard ideas the course teaches; every number the learner sees is an in-course assumption in the case tables (sections 5 and 7) or reasoned from them inside the course.

Concept / claim	Source (publisher)	URL	Accessed
Triage — sorting waiting work by need and time	Wikipedia — Triage	https://en.wikipedia.org/wiki/Triage	2026-07-20
Queue behaviour when demand exceeds capacity	Wikipedia — Queueing theory	https://en.wikipedia.org/wiki/Queueing_theory	2026-07-20
Priority queue — serving by a priority key instead of arrival order	Wikipedia — Priority queue	https://en.wikipedia.org/wiki/Priority_queue	2026-07-20
Shortest-processing-time / shortest-job-next scheduling	Wikipedia — Shortest job next	https://en.wikipedia.org/wiki/Shortest_job_next	2026-07-20
Context-switching / task-switching cost	Wikipedia — Human multitasking	https://en.wikipedia.org/wiki/Human_multitasking	2026-07-20
The vital few vs the trivial many (Pareto principle)	Wikipedia — Pareto principle	https://en.wikipedia.org/wiki/Pareto_principle	2026-07-20

Next up

Finished this call? Continue the Operations & Process track:

Little’s Law in practice: why starting more work makes it slower → · Browse all courses