Stakes and Complexity: Two Axes of Case Mix
Stakes and complexity are two independent dimensions of case mix that service operations habitually collapse into one. Complexity is how much skill and judgment a contact requires to resolve; stakes is how much depends on its resolution for the customer, and how soon — the customer's stakes, distinct from the planner's stakes in a decision that Probabilistic Planning in WFM uses the same word for. A simple rebooking six hours before departure is low in complexity and very high in stakes; a multi-city itinerary built weeks in advance is the reverse. Because the two axes are independent, a comparison between two populations is valid only if both axes match, and a placement rule that routes on complexity alone — or on a value score that folds stakes into complexity — will send high-stakes simple work to whichever handler is cheapest for simple work, which is frequently the wrong one. This page defines the two axes, shows that stakes is measurable today from fields that already exist in most service records, and states the comparison and placement rules that follow.
The composite value score used for routing between handler pools is owned by Value Routing Model; the general conditions for a fair comparison are at Comparing Delivery Arrangements and Sample Size and Detectable Difference in Quality Measurement.
Two axes, not one
Case mix is usually read as complexity: how hard is this work, how long does it take, how much expertise does it need. That reading is not wrong; it is half of the picture. Emergency medicine separated the two axes long ago: the standard five-level triage instrument stratifies patients on acuity and on predicted resource needs as distinct dimensions, because a domain in which mis-triage kills cannot afford to collapse them.[1] Stakes — what is at risk for the customer, and how close the deadline is — varies independently of complexity, and the two combine into four cells that behave differently in every respect that matters for staffing and measurement.[2]
| Low complexity | High complexity | |
|---|---|---|
| High stakes | A rebooking a few hours before departure; a payment failing at a settlement cut-off; a prescription refill the day it runs out. Simple to execute, severe if mishandled or delayed. Needs speed, calm and authority, not deep expertise. | A disruption in progress affecting a multi-leg journey with dependent bookings; a fraud alert on an account with payments in flight. Hard and urgent. Needs the deepest handler available, immediately. |
| Low stakes | A routine question, a preference update, a receipt. Needs neither speed nor expertise; the natural candidate for self-service or the widest pool. | A complex itinerary built weeks out; a policy question with several interacting rules; a coverage query for a procedure months away. Needs expertise; tolerates time. The natural candidate for a specialist queue with no urgency premium. |
The cell that the single-axis reading misplaces is the top-left. Read as low-complexity work, the pre-departure rebooking is routed to the cheapest handler for simple work, measured against the same target as a receipt request, and treated as a candidate for automation on the same terms — when what it needs is a handler who can act at once and be trusted to act, and a measurement that recognizes the state the customer arrived in.
Stakes is measurable from existing fields
Complexity is hard to measure directly and is usually proxied by handle time or by intent category. Stakes, by contrast, is measurable today from fields most service records already carry, without new tooling:
- Time to the customer's deadline — hours to departure, to a settlement cut-off, to a procedure date. The single strongest stakes signal, and one every booking record holds.
- Whether a commitment already exists — a ticketed or confirmed reservation versus an enquiry. Changing a commitment carries consequence that making one does not.
- Whether the customer is mid-journey — in transit, admitted or mid-treatment, with a payment in flight: the customer is already inside the thing that is going wrong.
- Whether the contact was triggered by an external event — a schedule change, a cancellation notice, a recall, a fraud alert, a system failure — rather than initiated by the customer's own plan.[2]
A stakes score built from these four is coarse, but it is coarse in the right dimension: it separates the customer who can wait from the customer who cannot, which is the separation handle time never makes.
The comparison rule
Two populations can be compared on quality, handle time or cost only if their case mix matches on both axes. Comparing Delivery Arrangements carries a comparison key whose case-mix row reads on complexity alone — harder work scores lower at identical capability; this page's second axis is a direct amendment to that row. A node that holds the disruption work and a node that holds the itinerary-building work may have identical complexity profiles and utterly different stakes profiles; compared on a common target, the disruption node looks worse for reasons that have nothing to do with its capability. Sample Size and Detectable Difference in Quality Measurement gives the sample-size conditions for any such comparison; this page adds the second axis to the case-mix adjustment that must precede it. The customer's state at the moment of contact — planning, mid-journey, in a disruption — is the stakes axis seen from the customer's side; Customer State and Attribution in Quality Measurement develops it, and the two adjustments are usually made together.
The placement rule
The four cells want four different handlers, and only two of them are what a complexity-only rule would choose.[2]
- High stakes, low complexity wants speed and authority — a handler who can act now, with the permissions to act, in a pool staffed for immediacy rather than depth. This is the cell that suffers most from being routed as "simple."
- High stakes, high complexity wants the deepest handler, immediately — the specialist pool, with priority.
- Low stakes, high complexity wants expertise without urgency — the specialist pool, without the urgency premium; it can queue.
- Low stakes, low complexity wants the widest pool or self-service — the only cell for which the complexity-only rule gives the right answer for the right reason.
That sequencing by delay cost rather than by processing time alone is a known result in scheduling theory — the generalized cμ rule, which under convex delay costs is asymptotically optimal in heavy traffic — and the placement rule above is its routing-layer analogue.[3]
Value Routing Model decomposes the value dimension of the routing decision into lifetime-value impact, customer effort, revenue opportunity and churn risk. Stakes is not one of those four dimensions, but it moves two of them directly — a mishandled pre-deadline contact is a lifetime-value and churn event — and it acts on the third as a weight rather than a score: stakes does not raise the effort a customer experiences, it raises what a given level of effort costs.
That page's own diagram names urgency while its composite formula carries no such term; this page supplies the missing axis rather than contradicting the model, and the recommendation — not yet part of the model's calibration path — is that the four record-level stakes fields above feed the lifetime-value and churn dimensions.[2] The routing discipline that executes the decision is at Next Generation Routing.
Failure modes
- Reading case mix as complexity. The high-stakes simple cell is routed, measured and automated as if it were the low-stakes simple cell.
- Adjusting for one axis. Comparisons are complexity-adjusted and the stakes difference between nodes is read as a capability difference.
- Automating by complexity alone. The pre-deadline rebooking is a candidate for self-service on complexity grounds, and the customer who most needed a person meets a form.
- Measuring stakes by handle time. The two diverge sharply in the top-left cell, which is the cell that matters.
Maturity Model Position
Separating stakes from complexity is a Level 4 discipline on the WFM Labs Maturity Model™: it presupposes the explicit comparison key that Comparing Delivery Arrangements places at Level 4, and it is what makes value-based classification route the top-left cell correctly. It becomes a Level 5 refinement where, as Sample Size and Detectable Difference in Quality Measurement describes, case-mix bias is treated as a problem distinct from precision. The value-based model's own definition of high value — work whose mishandling produces outsized negative consequences — already half-contains stakes but carries no deadline term; this page supplies the missing axis rather than a competing one.
See Also
- Customer State and Attribution in Quality Measurement — the stakes axis from the customer's side
- Value Routing Model — the value composite the stakes signals feed
- Comparing Delivery Arrangements — the comparison conditions
- Sample Size and Detectable Difference in Quality Measurement — sample size and detectable difference; case mix as a separate bias
- Next Generation Routing — executing a multi-objective routing decision
- After-Hours Service as a Distinct Work Type — the work type that lives almost entirely in the high-stakes row
References
- ↑ Gilboy, N., Tanabe, P., Travers, D., & Rosenau, A. M. (2011). Emergency Severity Index (ESI): A Triage Tool for Emergency Department Care, Version 4. Agency for Healthcare Research and Quality.
- ↑ 2.0 2.1 2.2 2.3 Practitioner observation from travel and other deadline-bound service operations; a consistent pattern rather than a measured result.
- ↑ Van Mieghem, J. A. (1995). Dynamic scheduling with convex delay costs: The generalized cμ rule. Annals of Applied Probability, 5(3), 809–833.
