Case Load Calculator
Compare incoming SOC case volume with investigative capacity, and see how fast the backlog grows or clears.
About Case Load Calculator
The calculation is deliberately a queueing sanity check rather than a full model: if arrivals exceed service capacity, the backlog grows without limit, and no amount of process improvement changes that. Utilisation above roughly 90% also means normal variation alone will produce a permanent queue. A SOC running at 100% utilisation has no capacity for the one incident that matters, and the backlog figure is what turns 'we are busy' into a staffing decision a finance team can act on.
Formulas
Case Load
Capacity (cases/week) = analysts × investigative hours per week ÷ hours per case. Utilisation = cases opened ÷ capacity.
- investigative hours
- Hours per analyst genuinely available for casework, typically 26–30 of 40
- hours per case
- Mean end-to-end investigation effort
- utilisation
- Demand as a percentage of capacity
Backlog burn-down
Weeks to clear backlog = open cases ÷ spare weekly capacity; when demand exceeds capacity the backlog never clears.
- spare capacity
- Capacity remaining after the incoming queue is served
Worked example
With the default values below, Case Load Calculator returns Capacity Utilisation of 140.6%. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Cases opened per weekaccepts 0–100,000 cases/week
- 210 cases/week
- Investigating analystsaccepts 1–1,000 analysts
- 8 analysts
- Mean investigation hours per caseaccepts 0.1–200 hours/case
- 1.5 hours/case
- Investigative hours per analyst per weekaccepts 1–80 hours/week
- 28 hours/week
- Cases already openaccepts 0–1,000,000 cases
- 120 cases
- Cases escalated to tier 2 or IRaccepts 0–100 %
- 12 %
Results
- Capacity Utilisation
- 140.6%
- Weekly Case Capacity
- 149.3 cases/week
- Cases per Analyst per Week
- 26.3 cases
- Weekly Surplus or DeficitNegative means the backlog shrinks.
- 60.7 cases/week
- Weeks to Clear the Current Backlog
- 9,999.0 weeks
- Escalations per Week
- 25.2 cases/week
- Case Load Verdict
- Over capacity — the backlog grows by 61 cases every week
Step by step
- 1Values used
- 2Case Load
- 3Backlog burn-down
- 4Capacity Utilisation= 140.6
- 5Weekly Case Capacity= 149.3 cases/week
- 6Cases per Analyst per Week= 26.3 cases
- 7Weekly Surplus or Deficit= 60.7 cases/week
- 8Weeks to Clear the Current Backlog= 9,999.0 weeks
- 9Escalations per Week= 25.2 cases/week
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is Case Load calculated?
Capacity (cases/week) = analysts × investigative hours per week ÷ hours per case. Utilisation = cases opened ÷ capacity. The calculation is deliberately a queueing sanity check rather than a full model: if arrivals exceed service capacity, the backlog grows without limit, and no amount of process improvement changes that. Utilisation above roughly 90% also means normal variation alone will produce a permanent queue.
Why does Case Load matter?
A SOC running at 100% utilisation has no capacity for the one incident that matters, and the backlog figure is what turns 'we are busy' into a staffing decision a finance team can act on.
What values do I need to enter?
This calculator takes 6 inputs: Cases opened per week, Investigating analysts, Mean investigation hours per case, Investigative hours per analyst per week, Cases already open, Cases escalated to tier 2 or IR. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why not plan for 100% utilisation?
Because arrivals are bursty. Queueing behaviour means waiting time rises steeply as utilisation approaches capacity, so a team planned at 95% will have a persistent backlog even though the weekly averages balance. Target 70–85%.
What if the backlog never clears?
Then the fix is not process. Either reduce arrivals (tune detections, automate closure of benign categories) or add capacity. Deferring the decision converts the backlog into a permanent, silent detection gap.
