Pick a persona preset
Four operator scenarios with realistic SLA, throughput, and a sample case list. Load one, then customize the inputs below.
24-hour backlog projection
Teal line is current trajectory. Amber line appears when you add agents in the header above. Red dashed line is the SLA breach threshold (queue size that breaches at current throughput).
Current trajectory
With added agents
SLA breach threshold
How this tool works
Two views, one mental model. Backlog health tells you whether you are behind right now. Queue prioritization tells you which case to grab first. Splitting them across two tools forces the operator to context-switch. Both questions share the same SLA, the same throughput, the same backlog count, so they live together here.
Real-world impact
Illustrative scenarios drawn from operator practice. Numbers are realistic order-of-magnitude estimates, not measurements from any specific deployment.
Case 1: 6,000-case backlog on a Tuesday morning
SetupFraud ops lead walking into Monday standup finds the weekend left a 6,000-case backlog with mixed SLA risk and no clear "who works what first" answer.
ProblemStatus quo was analyst-by-analyst FIFO, oldest cases worked first regardless of dollar exposure, causing roughly $45K weekly in avoidable losses on high-value cases that aged past windows.
Tool surfacedCommand center showed hours to SLA breach across queues, ranked cases by dollar-at-risk × time-decay, projected 9 agents needed for full recovery in 36 hours vs 14 for 18 hours.
OutcomeTeam prioritized 380 high-value aging cases first, dollar-weighted loss dropped 62% week over week (around $28K saved), and the backlog cleared in 41 hours.
Case 2: Content moderation team facing an SLA audit
SetupTrust and Safety manager at a UGC platform with a 12-person moderation team and contractual 24-hour SLA across 3 queue types (reports, appeals, escalations).
ProblemAudit was 10 days out and the team did not know current SLA compliance percentage by queue, manual sampling estimated somewhere between 78% to 91% with $0.5M of contractual penalty exposure.
Tool surfacedContent moderation preset surfaced live SLA compliance per queue (84%, 71%, 96%) and showed appeals queue needed 3 extra reviewers for 4 days to reach 95% before audit date.
OutcomeTemporary reallocation from escalations to appeals pulled appeals compliance to 97% before audit, full audit passed at 96% weighted, penalty exposure eliminated.
The backlog math:
effective_throughput = agents × throughput_rate × (1 − shrinkage)
net_change_rate = arrival_rate − effective_throughput
hours_to_breach = min(SLA − oldest_case_age, SLA − backlog / effective_throughput)
agents_needed = ceil((backlog + arrivals × hours_remaining) / (throughput × hours_remaining × (1 − shrinkage)))
recovery_cost = added_agents × hours × hourly_cost
The breach formula reports the earlier of two conditions: the oldest case in the queue aging past SLA, or new arrivals pushing the queue past the throughput ceiling. The tool tags which driver is binding so you can act on the right lever.
The priority formula:
age_factor = min(1.0, age_hours / SLA_target_hours)
value_factor = case_value / max_case_value_in_queue
priority_score = (w_risk × risk / 100) + (w_age × age_factor) + (w_value × value_factor)
priority_score is normalized 0 to 100, tier red ≥ 80, yellow 50 to 79, green < 50
Three reprioritize modes change the weights:
- Balanced (default): risk 0.5, age 0.3, value 0.2
- Risk-weighted (loss prevention): risk 0.7, age 0.2, value 0.1
- Value-weighted (revenue protection): risk 0.3, age 0.2, value 0.5
The four presets change SLA, throughput, and the sample case mix to match the operator persona. Fraud ops runs short SLA and risk-weighted. Content moderation runs long SLA and ignores value (zero-value cases by design). Disputes runs week-long SLA and is value-heavy. CS escalations runs 2-hour SLA and is age-dominated.
What this tool is NOT:
- Not a real-time monitor. Inputs are static for the session. Plug into your queue data manually or use it as a planning tool ahead of the shift.
- Not an ML predictor. Priority is a formula with explicit weights, not a learned model. The point is for the operator to see the math.
- Not a ticketing system. It recommends order, it does not execute or assign work.
- Not a portfolio view. Single queue at a time. For multi-queue allocation use Tool #1 V2 portfolio mode.
Operator credit. Tool #7 was inspired by feedback from Ricardo Vieira-Gomes (Co-Founder & Executive Director, ET Armadillo · AI Transformation in Operations) on a previous launch post. The integrated backlog-health-plus-prioritization model is his concept, refined into a single tool.