Workforce Management and Capacity Planning
Forecasting fraud alert volume, staffing review and QA teams with queueing math, setting SLAs on the money clock, planning for surges and attacks, and choosing between in-house and outsourced review.
Alert Review Operations covers queue design and a first-order FTE formula. This note covers forecasting, queueing math for real-time queues, backlog math for deferrable work, QA staffing, surge and attack plans, and outsourcing.
Core components
Two kinds of review work
| Real-time (customer waiting) | Deferrable (backlog work) | |
|---|---|---|
| Examples | Held withdrawals and payouts, step-up verification calls, in-flight P2P and RTP holds, instant-funding release decisions | Post-transaction review, receipt and offer review, account-level reviews, investigations, QA |
| Money state | Pre-movement: held, customer waiting | Usually post-movement, or held with a longer clock |
| What the customer feels | Minutes matter | Hours to days |
| Right model | Queueing (Erlang-style), staffed by 15–30 minute interval | Workload and backlog: clear inflow within the SLA window |
| Peak handling | Must staff the peak | Backlog absorbs peaks, within limits |
Many teams blend the two: real-time queues get priority, and analysts fill idle time with deferrable work. Blending raises utilization, but only if routing enforces the priority. Otherwise the deferrable backlog wins because it's always there.
Forecasting alert volume
Alert volume is the product of three things, and only one of them is outside your control:
Alerts = transaction volume × alert rate + attack volume
- Transaction volume follows business seasonality: hour of day, day of week, paydays and month-end, holidays, tax season, promo calendars, product launches, and for brokerages, market volatility. Forecast it with the methods your analytics team already uses for business volume (seasonal baselines, exponential smoothing, regression with event flags), at daily level, then spread across intervals with an intraday profile.
- Alert rate is your choice. It moves every time a rule or model threshold changes. That makes strategy the biggest driver of ops cost, and it's why every rule change should come with a volume estimate (see Rule Governance and Change Management and Fraud Strategy Lifecycle).
- Attack volume can't be forecast as a time series. Plan for it with scenarios: what happens to each queue if a credential-stuffing wave, a promo exploit or a bot sign-up wave doubles or quintuples inflow for 48 hours?
Practical rules:
- Forecast by queue, because handle times and SLAs differ.
- Keep a calendar of known events (promo launches from New Product and Promo Launch Review, marketing pushes, holiday returns season for retail, tax refund season for neobanks and brokerages, earnings and index events for brokerages) and adjust the baseline ahead of each event.
- Measure forecast accuracy with weighted absolute percentage error by day and by interval, plus bias (consistently over or under). A forecast that's accurate daily but wrong by interval still produces bad schedules.
- Separate organic from attack volume in history before fitting anything. Otherwise last quarter's attack becomes next quarter's baseline.
Handle time
Average handle time (AHT) is the other half of workload, and it's less stable than teams assume.
- Measure it by queue, outcome and tenure. Declines and escalations take longer than approvals. New analysts take longer for weeks or months (a ramp curve).
- Include after-case work: documentation, reason codes and customer messaging. Exclude waiting time for customer callbacks, which should re-queue rather than tie up an analyst.
- Watch the whole distribution. Handle times are right-skewed: most cases are quick and a few take very long. That matters for queueing math, which assumes a specific shape, and for SLAs, which live in the tail.
- Tooling and SOP changes move AHT. A review UI that puts linked entities on one screen, or an SOP that ends in a clear decision matrix, can cut AHT meaningfully (SOP Writing Standards, Case Management Systems).
Queueing basics for real-time review queues
For a queue where items arrive randomly and an analyst works one at a time, the classic staffing model is Erlang C:
- Offered load A = arrival rate × AHT, in "Erlangs" (the number of analysts that would be continuously busy)
- Analysts N must exceed A, or the queue grows without limit
- Probability an item waits: P_w, from the Erlang C formula
- Service level (share handled within target wait T) = 1 − P_w × e^−(N − A) × T / AHT
- Average wait = P_w × AHT / (N − A)
- Occupancy = A / N
Where Erlang C misleads:
- It assumes random arrivals, exponential handle times, a single homogeneous pool of analysts, and no abandonment. Alert queues don't abandon in the call-center sense, but SLA-expiry defaults (auto-release, auto-decline) act like abandonment. Comparative research finds Erlang C usually overstaffs relative to models that include abandonment, though it can understaff at high utilization when arrivals are uncertain. Neither model dominates. Treat Erlang C as a conservative baseline, then calibrate against what your queues actually do.
- Skills-based routing breaks the single-pool assumption. Simulate if you have many overlapping skill groups.
- Interval volatility. Fraud volume is burstier than Poisson, especially during attacks. Staff to a high percentile of interval volume, because the mean understates the peaks.
- The formula gives analysts on the floor. Apply shrinkage separately.
Backlog math for deferrable queues
For deferrable work, the questions are whether throughput keeps up with inflow and how old work gets.
- Average queue size = arrival rate × average time in queue (Little's law). A queue receiving 4,000 alerts a day with an average time-in-queue of 6 hours (0.25 day) holds about 1,000 alerts on average. If the backlog is 3,000, your effective time-in-queue is closer to 18 hours.
- For capacity, daily productive analyst minutes ÷ AHT must exceed average daily inflow, with headroom for variance. Running at 100% means any spike becomes permanent backlog.
- Prioritize by deadline: sort by time remaining to SLA × value at risk. FIFO lets a low-value alert from yesterday block a high-value alert from this morning.
- Track backlog by age. Report the oldest item and p90 age by queue every day.
From workload to heads
| Step | What you calculate | Typical considerations (illustrative) |
|---|---|---|
| 1. Workload | Volume × AHT per interval or per day | By queue |
| 2. Floor staff | Erlang (real-time) or workload ÷ productive time (deferrable) | Occupancy ceilings: sustained occupancy above roughly 85–90% burns people out |
| 3. Shrinkage | Divide by (1 − shrinkage) | Breaks, meetings, training, QA feedback, calibration, absence, attrition backfill. Commonly 25–35% in total |
| 4. Coverage | Hours of operation × days | A seat staffed 24/7 is 168 hours a week. At 40 paid hours and 30% shrinkage, that's 6 FTE per seat |
| 5. Ramp | Add capacity for new hires below full productivity | New analysts may run at half productivity for their first weeks |
| 6. Schedule | Shifts and breaks that match the interval curve | Stagger start times to follow the curve; a flat 9-to-5 schedule misses evening peaks |
Staffing QA
QA capacity is easy to forget until the sampling plan can't be met. Build it bottom-up from the sample design in Fraud QA Program:
QA is also the first thing teams cut during a surge. Decide in advance which QA work pauses (targeted samples, routine documentation audits) and which never does (critical-error checks on money-out queues, new-hire coverage).
SLAs on the money clock
- Set SLAs by what the money and the customer are doing (see the SLA table in Alert Review Operations).
- Measure at percentiles (p50, p90, p99) and by interval. A daily average can look fine while the evening peak misses every target.
- Write down the SLA-expiry default per queue. If it's "auto-release," treat capacity shortfalls as a fraud exposure as well as a service problem, because attackers can create the shortfall on purpose.
- Regulatory deadlines are hard constraints that sit outside your SLAs: Reg E investigation and provisional-credit clocks (Regulation E and Unauthorized Transfers) and SAR filing timelines (BSA-AML and SAR Filing). Plan capacity for them separately and never let them compete in a general queue.
Surge and attack plans
Surges differ by cause, and so does the right response.
| Surge type | Example | Primary response |
|---|---|---|
| Predictable organic | Holiday returns, tax season, a planned promo launch | Forecast it; schedule overtime and cross-trained staff in advance |
| Unplanned organic | Viral growth, a market selloff driving brokerage activity | Flex staffing; temporarily defer non-urgent queues |
| False-positive storm | A rule change or vendor signal outage floods queues with good customers | Roll back or tune the rule. More staff is the wrong answer. |
| Attack | Credential stuffing, bot sign-ups, promo exploit, ring funding attack | Contain the money path first with automated controls and kill switches, then add staff. |
Attackers can scale faster than you can hire. During an attack, adding analysts to a queue that's growing by thousands an hour mostly adds cost. The levers that work are automated: tightened thresholds with auto-decisions, circuit breakers on the affected money path, temporary holds, and turning off the exploited feature (see Fraud Incident Response and Kill Switches and Circuit Breakers).
Surge levels (illustrative; calibrate to your queues)
| Level | Trigger | Actions |
|---|---|---|
| Green | Inflow within forecast; oldest item within SLA | Normal operations |
| Amber | Inflow above forecast for two or more intervals, or p90 age approaching SLA | Overtime offered; blended analysts moved to real-time queues; targeted QA paused |
| Red | Oldest item past SLA on a money-out queue, or inflow far above capacity | Cross-trained reserve activated; deferrable queues paused; pre-approved volume valves applied with strategy; incident declared if the cause is adversarial |
| Black | Queue can't be cleared, and the SLA-expiry default would release money | Switch defaults to hold; circuit breakers on the affected path; executive and customer-comms notification |
Volume valves are pre-approved, pre-tested rule changes that cut review volume in a surge, each with a known risk cost: auto-decline above a score, auto-approve below a much lower score, auto-hold instead of review for a segment. Agree on them with strategy ahead of time. Writing them during the surge is how unreviewed money gets released. Rehearse them in Fraud Tabletop Exercises.
In-house vs outsourced review
| Factor | In-house | Outsourced (BPO) |
|---|---|---|
| Cost per decision | Higher | Lower, especially offshore |
| Scaling and surge | Slow to hire | Faster, if surge capacity is in the contract |
| Ramp time | Depends on recruiting | Vendor recruits, but still needs your training |
| Decision quality | Easier to calibrate | Needs strong QA, calibration and the same SOPs |
| Knowledge retention | Better | Vendor attrition can be high, and knowledge leaves with it |
| Insider risk and data access | Your controls | Extra exposure; the vendor's staff can see and act on customer accounts (Insider Fraud) |
| Regulatory oversight | Direct | For banks, third-party risk management applies to the arrangement, scaled to how critical the activity is |
| Time zones and languages | Limited | Follow-the-sun coverage; language coverage |
The common pattern is hybrid: in-house teams own SOPs, calibration, novel patterns, high-dollar and regulated queues, and investigations. Outsourced teams handle high-volume, well-specified, lower-risk queues. Fraud strategy and QA stay in-house in every model.
Contract terms that matter:
- Pricing model. Per-transaction pricing rewards speed over accuracy. Per-FTE pricing with quality targets aligns better. If you must price per item, tie part of the fee to QA accuracy.
- Surge commitments: a defined flex band above baseline volume with a notice period, and ramp-down terms.
- Quality: your rubric, your QA sampling, access for your reviewers, and consequences for missed targets.
- People: minimum tenure on your queues, attrition reporting, training completion, and attestation on SOP versions (SOP Writing Standards).
- Access and monitoring: least-privilege access, session monitoring, controls on value-releasing actions, background checks, and right to audit (Insider Access Controls).
- Data handling: where data is viewed and stored, screenshot and device restrictions, and breach notification.
How to build it
| Stage | What it looks like | Next step |
|---|---|---|
| 1. Reactive | Staffing set by headcount budget; overtime when backlogs explode | Measure inflow, AHT and backlog age per queue |
| 2. Planned | Daily forecast, FTE plan, shrinkage assumptions | Interval-level forecast and schedules; percentile SLAs |
| 3. Modeled | Erlang for real-time queues, backlog math for deferrable; rule changes come with volume estimates | Surge levels, volume valves, cross-trained reserve |
| 4. Integrated | WFM signs off on strategy changes and launches; capacity treated as part of control design | Scenario planning for attacks; simulation for skill routing |
| 5. Adaptive | Real-time routing, automated volume valves with guardrails, forecasts that learn from attack detection | Feed WFM data into exposure models (Exposure Window Modeling) |
Artifacts and templates
Capacity plan (per queue, per month)
| Field | Example |
|---|---|
| Queue and money state | Withdrawal hold, new destination; pre-movement |
| Forecast inflow | Daily, plus peak interval |
| AHT | By outcome; tenure-adjusted |
| SLA and model | 90% within 2 minutes; Erlang C |
| Floor staff by interval | From the model |
| Shrinkage assumption | By component |
| Scheduled FTE | In-house and vendor |
| Planned events | Launches, promos, seasonal peaks |
| Volume valves available | IDs and risk cost |
| SLA-expiry default | Hold, never release |
Weekly WFM review agenda
- Forecast vs actual by queue and interval; bias
- SLA attainment at p50/p90/p99; oldest-item age
- AHT trend by queue and tenure
- Shrinkage vs plan
- Upcoming rule changes, launches and promos, with volume estimates
- QA coverage vs plan
- Vendor performance: volume, SLA, QA accuracy, attrition
Rule-change volume estimate (attach to every rule proposal)
- Expected alerts per day, with backtest basis
- Queue affected and AHT
- Analyst hours per day added or removed
- Interval peak impact
- Ops lead sign-off
Metrics
| Metric | Why |
|---|---|
| Forecast accuracy (weighted APE) and bias, by queue and interval | Planning quality |
| SLA attainment at p50/p90/p99 | Customer and fraud impact |
| Oldest-item age and p90 backlog age | Early warning for deferrable queues |
| Occupancy and utilization | Burnout risk above sustained high levels; waste at low levels |
| Shrinkage, actual vs plan | Hidden capacity loss |
| Schedule adherence | Whether staff are where the plan needs them |
| AHT by queue, outcome and tenure | Capacity driver; tooling and SOP impact |
| Cost per decision, in-house vs vendor, paired with QA accuracy | Cost per decision means little without the matching quality number |
| Attrition and time to proficiency | Sustainability |
| Share of SLA-expiry defaults triggered | Capacity gaps that turn into fraud exposure |
Pitfalls
- Staffing to daily averages. Interval peaks are where SLAs fail.
- Ignoring the alert rate. Treating volume as weather when strategy controls most of it.
- Hiring through an attack. Analysts don't scale as fast as bots. Contain first.
- Auto-release on SLA expiry. A capacity problem becomes an exploitable hole.
- Over-specialized queues. Small pools lose the efficiency of pooling.
- Productivity targets without quality targets. Analysts learn to clear cases fast at the expense of deciding them well (see Fraud QA Program).
- Cutting QA first in every surge, so error spikes go unnoticed exactly when decisions are most rushed.
- Per-transaction vendor pricing without quality incentives.
- Shrinkage set once and never measured. Training, calibration and meetings creep up unnoticed.
Related
- Operations: Alert Review Operations · Fraud QA Program · Manual Review Queues · Case Management Systems · SOP Writing Standards · Investigation Standards
- Surge and incidents: Fraud Incident Response · Kill Switches and Circuit Breakers · Fraud Tabletop Exercises · Credential Stuffing · Business Logic Exploitation
- Strategy interface: Rule Governance and Change Management · Fraud Strategy Lifecycle · New Product and Promo Launch Review · Friction and Customer Experience Tradeoffs
- Organization and people: Fraud Operating Model · Fraud Team Hiring and Career Paths · Fraud Analyst Onboarding Curriculum · Insider Access Controls
- Measurement: Fraud Metrics and KPIs · Exposure Window Modeling
Sources and further reading
- MetricGate, Erlang C documentation: offered load, probability of waiting, service level and average wait formulas; assumptions; shrinkage applied separately
- Robbins, Comparing Erlang A and Erlang C (working paper, East Carolina University): Erlang C assumptions; Erlang C usually overstaffs, Erlang A usually understaffs; neither dominates under arrival uncertainty
- OCC Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management (June 2023): banks' third-party risk management scaled to the criticality of the activity, relevant to outsourced review
- Federal Reserve SR 23-4, Interagency Guidance on Third-Party Relationships: the Federal Reserve's issuance of the same interagency guidance
- CFPB, Regulation E §1005.11 Procedures for resolving errors: regulatory clocks that need dedicated capacity
- eCFR, 31 CFR 1020.320 Reports by banks of suspicious transactions: SAR timelines that bind investigation capacity