A medical triage system can split patients by 'fever? yes/no'
Your support queue has 47 open tickets this morning. Your team can close 15 today. Three are from your largest account - the one that makes up 12% of Revenue. Eight are password resets. The rest are somewhere in between. Working them in arrival order means that password reset at 8:01 AM gets handled before the Revenue-blocking outage reported at 8:02 AM. You need a system that splits the pile into buckets before anyone touches a ticket.
Triage is the act of sorting incoming items into priority buckets using simple, repeatable rules - so you spend scarce capacity on what matters most before you run out of it.
Triage is a classification step that happens before work begins. You take a stream of incoming items - support tickets, sales leads, bug reports, expense requests - and split them into a small number of buckets based on simple criteria.
The medical version asks one question at the door: immediate threat to life - yes or no? The business version asks the same kind of question: immediate threat to Revenue - yes or no?
The key insight: triage is not the same as doing the work. It is a separate, fast step whose only job is to route each item to the right bucket. A good triage rule takes seconds per item. If your triage step takes as long as doing the work, it is not triage - it is just working the queue in a different order.
Every Operations team has finite capacity. When inbound volume exceeds capacity - and it will - you face a resource allocation problem. Without triage, the default behavior is one of two things:
Both are failure modes. They disconnect effort from P&L impact.
Triage forces you to define what matters as an explicit decision rule, then apply it consistently. This is how you protect Revenue, reduce Churn, and make your Cost Structure reflect actual priorities instead of random arrival order.
On a P&L, the impact shows up in two places: you catch high-value problems before they become expensive (reducing Error Cost), and you stop spending capacity on low-value work that crowds out what matters (reducing opportunity cost).
A triage system has three components:
1. Buckets (usually 3-4)
More than four buckets and the person triaging slows down, which defeats the purpose. Common patterns:
Each bucket has a different response: Critical gets worked immediately, Normal goes into today's queue, Low gets batched weekly.
2. Splitting rules (simple, binary questions)
Business triage uses blunt questions answerable in seconds:
The questions must be answerable in under 10 seconds by the person triaging. If you need to investigate to classify, your triage rules are too complex.
3. A single triage point
One person (or one automated rule) classifies every item before it enters the work queue. This prevents the failure mode where multiple people each pick from the same pile, duplicating effort or leaving hard items orphaned.
The output of triage is not a solution - it is a sorted queue that respects your priorities.
Triage earns its keep when three conditions hold:
If none of these conditions holds, just work items as they arrive. The overhead of the triage step only pays for itself when the cost of getting the order wrong exceeds the cost of the classification step.
You run customer support for a SaaS product with $2M ARR across 200 accounts. Revenue is concentrated at the top: your five largest accounts average $150K each ($750K combined - over a third of total Revenue). Accounts six through twenty average $30K each ($450K combined). The remaining 180 accounts share $800K, averaging about $4,500 each.
Your team of 3 can close 15 tickets per day. Monday morning: 47 tickets in the queue. Your Churn Rate data shows accounts with unresolved tickets older than 48 hours churn at 10%. Accounts resolved within 24 hours churn at 1%.
Step 1 - Define buckets: Critical (top-20 account OR Revenue-blocking), Normal (all other paying accounts), Low (non-paying users, feature requests).
Step 2 - Triage the 47 tickets: 3 are from top-5 accounts, 3 are from accounts 6 through 20, and 3 are Revenue-blocking bugs from smaller accounts. That is 9 Critical. 22 are from other paying accounts (Normal). 16 are feature requests and non-paying users (Low).
Step 3 - Allocate capacity: Work all 9 Critical tickets first (takes roughly half the day for the team). Remaining capacity of ~6 tickets goes to Normal. The 16 Low tickets get batched for Friday.
Step 4 - Calculate the P&L impact: The 3 top-5 accounts represent $450K in ARR. The 3 accounts from the 6-through-20 tier represent $90K. The 3 smaller accounts represent about $15K. Total ARR exposed on Critical tickets: ~$555K. Resolving within 24 hours means 1% Churn risk on that $555K - $5,550 in Expected Value of loss. Delaying past 48 hours means 10% Churn risk - $55,500. Triage protected ~$50,000 in Expected Value of Revenue by ensuring the right tickets got worked first.
Insight: Triage did not increase your team's capacity - you still closed 15 tickets. It changed which 15 got closed first. The P&L difference between a triaged queue and an arrival-order queue is the difference between protecting $555K in ARR and leaving it exposed to a 10x higher Churn Rate.
You are a sales manager with 3 reps and 60 open deals in the Pipeline. It is day 75 of a 90-day quarter. Each rep can run 5 meaningful meetings in the remaining 15 days (15 total meetings). Deal sizes range from $5K to $120K.
Your historical Close Rate data by deal stage: deals where the Buyer has confirmed both budget and timeline close at 40%. Deals where only one of those signals is present close at 15%. Deals with neither signal close at about 5%.
Step 1 - Define buckets using two splitting questions: (a) Has the Buyer confirmed budget? (b) Has the Buyer confirmed timeline? Both yes = Hot. One yes = Warm. Both no = Cold.
Step 2 - Triage the 60 deals: 8 are Hot ($480K total Pipeline Volume, average $60K each). 17 are Warm ($310K total, average ~$18K each). 35 are Cold ($290K total, average ~$8K each).
Step 3 - Allocate the 15 available meetings: All 8 Hot deals get meetings. Remaining 7 meetings go to the largest Warm deals (averaging ~$25K each). Cold deals get a written follow-up only - zero meetings.
Step 4 - Expected Payoff: Hot deals: 8 × $60K × 40% Close Rate = $192K. Top 7 Warm deals: 7 × $25K × 15% Close Rate = $26K. Total Expected Payoff from triaged meetings: ~$218K. Without triage, distributing 15 meetings proportionally across all 60 deals yields roughly 2 Hot meetings, 4 Warm meetings, and 9 Cold meetings - about $62K in Expected Payoff. Triage more than tripled the Expected Return from the same 15 meetings.
Insight: Triage increased Expected Return per meeting from ~$4,100 to ~$14,500 without changing the number of meetings. The reps did not work harder. A 30-second classification step routed their effort toward the highest Expected Value outcomes.
Triage is a fast classification step that happens before work begins - its job is to sort, not to solve.
The power of triage comes from matching scarce capacity to high-impact items first, which directly protects Revenue and reduces Error Cost.
Good triage rules are binary questions answerable in seconds. If classification takes investigation, your rules are too complex - simplify them.
Too many buckets. Five or more priority levels and people spend more time classifying than working. Three buckets cover 90% of real-world Operations needs. If you catch yourself adding a 'Medium-High' tier, you have already lost the thread.
Triaging by effort instead of impact. It is tempting to knock out the quick-and-easy items first because it feels productive. But triage should sort by P&L consequence, not by how fast you can close the item. A 5-minute password reset is satisfying to close but has near-zero Revenue impact compared to a 45-minute investigation for a top account.
You manage a 4-person engineering team. On Monday you have 30 bug reports. 5 are from the payments flow (which processes $400K/month in Revenue), 10 are cosmetic display issues, and 15 are minor feature gaps customers have requested. Your team can fix about 12 bugs this week. Design a triage system: define your buckets, write the splitting questions, and allocate the 12 bug-fix slots.
Hint: Start with the splitting question 'Does this bug block Revenue?' and work from there. Think about what happens to the $400K/month if the payments bugs sit for a week.
Buckets: (1) Critical - blocks or degrades the payments flow, (2) Normal - affects functionality for paying customers, (3) Low - cosmetic or feature requests. Splitting questions: 'Does this touch the payments flow?' Yes → Critical. 'Does this cause a paying customer to hit an error or lose functionality?' Yes → Normal. Everything else → Low. Allocation: Fix all 5 payments bugs first (Critical). Then work 7 of the 15 feature-gap bugs that affect the most customers (Normal). The 10 cosmetic issues (Low) wait until next week. The payments flow handles $400K/month - roughly $100K/week. Even a 2% defect rate there means $2,000/week at risk. No cosmetic bug has that kind of P&L consequence.
Your company's Collections team handles payments from 500 customers. 40 invoices are overdue. The team can make 10 collection calls per day. The overdue invoices range from $200 to $85,000. Some are 5 days late, others are 90+ days late. Your Collections data from the past four quarters shows: invoices under 30 days overdue recover at about 60% per contact. Invoices between 30 and 60 days recover at about 30%. Invoices over 60 days recover at about 10%. Design a triage system that maximizes Cash Flow recovery this week (5 working days, 50 total calls).
Hint: You have two dimensions to triage on: invoice size and days overdue. The recovery rates decrease with age. Think about which combination of size and age gives you the highest Expected Value per call.
Buckets: (1) Critical - invoice over $10,000 AND under 30 days overdue (high dollar value, still recoverable at 60%). (2) Normal - invoice over $10,000 AND 30-60 days overdue (high value, moderate recovery at 30%), OR invoice $2,000 to $10,000 AND under 30 days overdue. (3) Low - everything else. Splitting questions: 'Is the invoice over $10,000?' and 'Is it under 30 days overdue?' Both yes → Critical. One yes → Normal. Both no → Low. Work Critical first, then Normal. With 50 calls across the week, you cover all Critical invoices first (likely 8-12 of them) and then work through Normal by descending dollar amount. An $85,000 invoice at 15 days overdue has a 60% recovery rate - that is $51,000 in Expected Value per call. A $200 invoice at 90 days has a 10% recovery rate - $20 in Expected Value per call. Triage ensures you are not spending one of your 50 calls on $20 of expected recovery when $51,000 is sitting in the queue.
Triage is the simplest form of resource allocation under constraint, which is why it connects to so many other Operations concepts. The Bottleneck is the constraint that makes demand exceed capacity - it is the precondition that makes triage necessary; without a Bottleneck, you can work everything and sorting adds no value. Decision rules formalize the splitting criteria so triage is consistent across people and shifts - without them, two people triaging the same queue will produce different bucket assignments, which is itself a failure mode. Pipeline management applies triage at every stage of a sales or recruiting funnel: each stage is a triage gate that decides what advances and what stalls, so Pipeline Velocity depends on how well each gate sorts. Capacity planning asks the upstream question - should you keep triaging a constrained queue, or invest in expanding Throughput until triage becomes less critical? And Expected Value gives you the math to verify your buckets are ordered correctly: if the Expected Value of a Normal item exceeds a Critical item, your splitting rules are wrong and need recalibration.
Disclaimer: This content is for educational and informational purposes only and does not constitute financial, investment, tax, or legal advice. It is not a recommendation to buy, sell, or hold any security or financial product. You should consult a qualified financial advisor, tax professional, or attorney before making financial decisions. Past performance is not indicative of future results. The author is not a registered investment advisor, broker-dealer, or financial planner.