Backlog management for non-real-time channels

Scheduling · Forecasting · ~7 minute read

Work that accumulates rather than queues

Voice and chat operations have a familiar rhythm: contacts arrive in real time, an Erlang model says how many agents are needed, and the planner builds a schedule that staffs to the curve. Email, social media, and back-office work do not work this way. The contact arrives, but it does not queue in the traditional sense — it joins a backlog that the operation needs to clear within an agreed window. The planning problem changes shape: the question is not “how many agents do I need at 10:30 on Tuesday” but “how many agent-hours do I need across this week to keep the oldest case under our SLA target.” This article walks through the differences, the service-level definitions that work for backlog channels, how to forecast and schedule them, and the real-time discipline that prevents quiet backlog drift.

The fundamental difference

In a synchronous channel, the relationship between staffing and service level is governed by queuing theory — Erlang for the simple cases, simulation for the complex ones. The customer waits in real time, and the staffing decision has to match the arrival pattern at interval level. In an asynchronous channel, the relationship is governed by simple capacity arithmetic: the channel needs to process at least as much work as arrives, plus some buffer, plus any backlog being worked down. The planning problem is closer to a manufacturing line than to a queue. Treating an asynchronous channel as if it were synchronous — staffing it intraday against a moment-by-moment forecast — is a common mistake that wastes effort and produces worse outcomes than a simpler weekly capacity plan.

Service-level definitions that actually work

Voice service level (80% in 20 seconds) does not apply to email. The right metrics for asynchronous channels are of two types. The first is age of oldest case: how long has the oldest unworked item been waiting? A common target for email is “no case waits longer than 24 hours” or “90% of cases resolved within 48 hours.” The second is throughput against backlog: how much work cleared today compared to how much arrived. A target of “daily throughput at least equal to daily intake” keeps the backlog from growing; aiming for 105–110% allows it to shrink. Some operations also report a first response time separately from a resolution time, which matters when the operation auto-acknowledges receipt and the customer is more relaxed about resolution than about being heard.

Forecasting for backlog channels

Forecasting asynchronous channels is generally easier than forecasting voice because the volume is more stable. Customers send emails throughout the day with less of the morning peak that voice exhibits, and the day-to-day variation tends to be lower. The planning grain is also coarser — weekly or daily, rather than half-hourly — which gives more data points to fit and smoother forecasts. The complication is event-driven spikes: an email arrival pattern that has been stable for months can double in 24 hours if a customer-facing problem hits, and the backlog can build faster than the channel can clear it. Forecasting the baseline is straightforward; forecasting the spikes requires the same event awareness as voice and the same speech-analytics-style demand decomposition described in the speech analytics article.

Scheduling for backlog

The schedule for an asynchronous channel does not need to match the intraday curve of arrivals. It needs to deliver the agent-hours required to keep the backlog within SLA. This unlocks scheduling flexibility that is not available to voice. Agents can work in longer blocks at times that suit them, the operation can lean on quiet days to catch up from busy days, and the channel can flex headcount across the week to absorb volatility. Many operations run backlog channels with non-standard shift patterns specifically because the channel does not need the same coverage shape as voice — 9am to 7pm with a midday lull is fine, where voice would have struggled with that shape.

A common and effective design is to schedule backlog channels on a target throughput model: each agent is expected to complete a known number of cases per hour, the planner translates the weekly intake forecast plus the backlog target into total hours required, and the schedule is built to produce those hours. The schedule does not need to be tight to the arrival pattern; it needs to deliver the total capacity.

Blended agents and the trap of dynamic priority

Many operations run blended agents who handle voice when the voice queue needs them and email when it does not. This is operationally attractive but planning-fragile. The instinct is to push email into the “quiet” moments around voice peaks, which sounds efficient but consistently fails because email does not get the dedicated focus required to keep its own SLA. Agents asked to handle email between calls produce worse email throughput than dedicated agents, take longer per case, and make more errors that come back as repeat contacts. If the operation truly needs email handled, it usually needs dedicated email time rather than scavenged time between voice calls.

A workable blended pattern is to dedicate specific intervals or specific agents to backlog work, with a hard switchover. “Email between calls” rarely works; “email in the afternoon, voice in the morning” can work; “email all day for these four agents, voice for the rest” usually works best. The pattern reflects the cognitive cost of context-switching, which is real and underestimated.

Real-time monitoring

The real-time view for an asynchronous channel is different from voice. Instead of an interval-by-interval queue, the monitor watches three numbers: current backlog size, age of oldest case, and rolling throughput. If backlog is growing for more than a few hours, the operation has a problem developing. If the oldest case is approaching SLA, the operation has an imminent problem. If throughput has dropped, the operation has an immediate problem — a system issue, an agent state issue, or a routing problem. A simple dashboard with these three numbers and the trend across the last few hours is usually enough; sophisticated real-time tooling adds value only at large scale.

Common mistakes

Four patterns recur. Treating asynchronous channels as synchronous — forecasting at half-hour grain and scheduling tight to the curve, when the channel does not benefit from either. Setting voice-style SLs (“email answered in 20 seconds”) that have no relationship to customer expectation or operational reality. Blending email handling into the gaps between calls without dedicated time, producing worse outcomes on both channels. And ignoring the backlog as long as it is not actively growing, missing the slow drift that becomes a crisis after a few weeks of quiet accumulation.

Conclusion

Asynchronous channels are different enough from voice that the planning approach has to be different too. The SL definitions, the forecasting grain, the scheduling design, the real-time view, and the operational rhythm all shift. The planners who recognise this and design for it produce backlog channels that operate quietly and consistently. The planners who try to apply voice planning to email produce noisy backlog channels that lurch from crisis to crisis. As more contact volume continues to migrate from voice to digital channels, the asynchronous-channel discipline becomes a larger part of the planning function’s work — and the operations that have the discipline already are several years ahead of the operations that do not.

Pair this with multi-skill scheduling for the blended-agent question, and the contact centre planning cycle for the rhythm that anchors backlog management.