Back-office case work WFM
Back-office case work has no live queue, no service level, and no real-time arrival pressure. What it has instead is a backlog that ages and SLA deadlines that breach. You are not staffing to answer arrivals fast — you are staffing to clear work before it breaches, and to stop the backlog growing faster than you can process it.
Real-time queue vs. back-office case work
| Dimension | Real-time queue (voice/chat) | Back-office case work |
|---|---|---|
| Customer presence | Customer waiting live — speed of answer is everything | No customer waiting live — work is deferred |
| Time pressure | Seconds (SL target e.g. 80% in 20s) | Hours to weeks (SLA deadline per case type) |
| Staffing model | Erlang C — staff to answer random arrivals fast | Flow / backlog model — capacity vs inflow + backlog |
| Can work wait? | No — unanswered = abandoned + lost | Yes — cases queue in a backlog without being lost |
| Primary risk | Long wait → abandonment | Case ages past SLA → breach |
| Can be batched? | No — answered on arrival | Yes — prioritised, batched, scheduled |
| Achievable utilisation | ~80–85% (idle gaps between arrivals) | Higher — no waiting-for-arrivals idle constraint |
| Key metric | Service level + queue depth | Backlog age profile + forecast SLA breaches |
Four case-work planning concepts
Backlog and backlog age profile
Definition
The backlog is the count of unprocessed cases at a point in time. The age profile breaks the backlog down by how long each case has been waiting (e.g. 0–1 day, 1–3 days, 3–5 days, 5+ days). The age profile matters more than the headline backlog count, because it shows how close cases are to breaching their SLA.
Planning implication
Plan from the age profile, not just the total. A backlog of 1,000 cases all received today is a very different situation from a backlog of 1,000 cases where 300 are already past their SLA deadline. The age profile drives prioritisation and tells you how much of the backlog is recoverable vs. already breached.
Inflow rate vs. processing capacity
Definition
Inflow is the rate at which new cases arrive (per day or per week). Processing capacity is how many cases the team can complete in the same period (FTE × productive hours ÷ average handle time). The relationship between the two determines whether the backlog grows or shrinks.
Planning implication
If processing capacity < inflow, the backlog grows without limit and SLA breaches are guaranteed — no amount of prioritisation fixes a structural capacity deficit. The first WFM question for case work is always: does steady-state capacity at least equal inflow? Only then can you plan to burn down the existing backlog.
SLA deadline and breach risk
Definition
Each case type has an SLA — the maximum time allowed to complete it (e.g. complaints within 8 weeks, applications within 5 working days). Breach risk is the proportion of the backlog at risk of exceeding its SLA given current capacity. A case that will not be reached before its deadline is a forecast breach.
Planning implication
Prioritise the backlog by breach risk, not by age or arrival order alone. A 4-day-old case with a 5-day SLA is more urgent than a 6-day-old case with a 20-day SLA. WFM should report forecast breaches (cases that will breach at current capacity) as the headline risk metric, not just the current breach count.
Backlog burn-down plan
Definition
A plan to reduce an elevated backlog to a target level over a defined period, by deploying processing capacity above the steady-state inflow rate. Burn-down capacity = total capacity − inflow; the surplus is what eats into the backlog.
Planning implication
Burning down a backlog requires capacity above inflow for a sustained period. Calculate it explicitly: to clear a 2,000-case backlog in 4 weeks while inflow continues, you need (steady-state capacity to match inflow) PLUS (2,000 ÷ 4 weeks) of additional weekly capacity. This is where overtime, temporary resource, or borrowed capacity is deployed — and where it can be stood down once the backlog reaches target.
Backlog burn-down: worked example
Capacity to clear a backlog while inflow continues
FTE needed = [ inflow_per_week + (backlog ÷ weeks_to_clear) ] × AHT_hours ÷ productive_hours_per_FTE
The plan: deploy ~17 FTE for 4 weeks to clear the backlog while keeping pace with inflow, then stand down to the ~9 FTE steady state that matches inflow alone. The extra ~8 FTE for 4 weeks is the burn-down capacity — sourced from overtime, temporary resource, or borrowed capacity, and stood down once the backlog hits target. Note: if steady-state capacity (9 FTE) is not in place permanently, the backlog simply rebuilds after burn-down.
Six metrics for case-work WFM
Backlog size + age profile
How much work is waiting and how close it is to breaching. The single most important case-work metric — replaces the real-time queue depth of a contact operation.
Inflow vs. completed (per day/week)
Whether the backlog is growing or shrinking. Inflow > completed = growing backlog = structural problem. The case-work equivalent of 'are we keeping up?'.
Forecast SLA breaches
How many cases will breach their deadline at current capacity. The forward-looking risk metric — far more actionable than the count of cases that have already breached.
Average case age at completion
How long cases wait before being processed. Rising age-at-completion is an early warning that capacity is slipping behind inflow, before breaches appear.
Processing capacity utilisation
Productive case-work time ÷ available time. The case-work equivalent of occupancy — but note that 100% is achievable here (no idle-waiting-for-arrivals constraint), so the target is higher than a voice queue.
Rework / reopen rate
Cases returned for further work after being marked complete. High rework inflates effective inflow (a reopened case is new work) and signals a quality problem that WFM capacity planning must account for.
Back-office case work questions
Why can't you use Erlang C to staff back-office case work?
Erlang C models a real-time queue optimising for speed of answer under random arrivals — contacts arrive, wait only briefly, and must be answered within seconds. Case work has none of these properties: cases have SLA deadlines in hours or days (not seconds), they wait in a backlog without a customer holding the line, and they can be batched and prioritised. The correct model is a flow/backlog model: processing capacity (FTE × productive hours ÷ AHT) compared against inflow plus existing backlog. If capacity exceeds inflow the backlog shrinks; if inflow exceeds capacity the backlog grows and breaches become inevitable regardless of prioritisation. The staffing question is 'how many FTE to clear the backlog and keep pace with inflow before SLA deadlines breach', not 'how many agents to answer within X seconds'.
Related guides
Back-office staffing
Staffing the back-office function
Email and ticket WFM
Throughput model for deferred contacts
Staffing models guide
Voice, email, chat, outbound, case work
WFM for blended agents
Agents who split voice and case work
Net staffing calculation
From requirement to establishment
Capacity buffer planning
Buffer for inflow variability
Email & ticket calculator
Calculate FTE from target response time and inflow rate