← ccPlanning Academy · Channel planning track

Messaging & async

Free visual lesson · about 5 minutes · short quiz at the end

ccPlanning academy · channel planning

Messaging & async

WhatsApp, SMS, in-app: conversations with no clear beginning or end.

The big idea

Async sits between live chat and email — and behaves like neither.

A messaging conversation can pause for minutes, hours or days and resume on the same thread. It’s not real-time like chat, nor a one-and-done item like email. That “sometimes live, sometimes deferred, never closed” nature is what makes it hard to plan.

Problem 1

There’s no clean handle time.

When does a WhatsApp conversation “end”? The customer replies a day later and it’s alive again. Total session length is meaningless for staffing; what matters is active handling time — the minutes an agent actually spends, scattered across a long-lived thread.

Problem 2

High, lumpy concurrency.

Because most open conversations are idle at any moment (waiting on the customer), an agent can hold many open async threads — far more than live chat. But when several reply at once, they all need attention together. Concurrency is high on average and spiky in the moment.

Problem 3

Response-time expectations vary wildly.

SMS feels urgent; an in-app message thread the customer expects a reply to “sometime today” does not. The same channel can carry both expectations. Plan to the promised response time per use case, not a single blanket SLA.

How to plan it

Staff to active workload, manage to response time.

Forecast inbound messages and the active minutes each consumes (not session length). Staff enough capacity to keep average response time within the promise, treat the pool of open threads like a managed backlog, and watch the spiky moments where many reply together — that’s where service breaks.

The bot handoff

Async is where automation lives — plan the residue.

Messaging is the channel most blended with bots, which handle the simple turns and hand the hard ones to agents (often mid-conversation). So the human workload is the harder residue — the residual-complexity effect from the automation lesson, in real time. Plan for what the bot leaves you.

Count the work, not the windows

A two-day conversation, six minutes of work

A WhatsApp thread stays open 48 hours — but the agent spent maybe six active minutes on it, in three short bursts. Count it as a 48-hour “open conversation” for concurrency and you’ll wildly over-staff; count the six active minutes and the response promise, and the plan is real.

One agent can hold dozens of these because most are idle — until several reply at once. Staff the work; watch the spikes.

The takeaway

Active minutes, response-time promises, spiky concurrency.

Async messaging has no clean handle time and no real close — staff to the active handling minutes, manage the open threads as a backlog against a per-use-case response promise, and watch the moments when many threads come alive at once. And remember the bot leaves you the hard half.

Now test yourself ↓

1 / 8

Slides done? Here’s the same idea in a bit more depth — the part worth keeping.

In depth: conversations with no clear beginning or end

Async messaging — WhatsApp, SMS, in-app — sits between live chat and email and behaves like neither. A conversation can pause for minutes, hours or days and resume on the same thread, so it’s not real-time like chat nor a one-and-done item like email. That “sometimes live, sometimes deferred, never closed” nature is exactly what makes it hard to plan, and why the live-chat and email playbooks both mislead.

Three things that break the usual maths

First, there’s no clean handle time: when does a WhatsApp conversation “end” if the customer can reply a day later and revive it? Total session length is meaningless for staffing — what matters is active handling time, the minutes an agent actually spends, scattered across a long-lived thread. Second, concurrency is high but lumpy: because most open conversations are idle at any moment, an agent can hold many open threads — far more than live chat — but when several reply at once they all need attention together, so concurrency is high on average and spiky in the moment. Third, response-time expectations vary wildly: SMS feels urgent, an in-app thread the customer expects answered “sometime today” does not, and the same channel carries both, so you plan to the promised response time per use case, not one blanket SLA.

How to plan it — and the bot residue

The method is to forecast inbound messages and the active minutes each consumes, staff enough capacity to keep average response time within the promise, treat the pool of open threads like a managed backlog, and watch the spiky moments when many reply together — that’s where service breaks. And remember async is the channel most blended with bots, which handle the simple turns and hand the hard ones to agents, often mid-conversation. So the human workload is the harder residue — the residual-complexity effect in real time — and you plan for what the bot leaves you, not the gross volume.

The principle to remember: active minutes, response-time promises, spiky concurrency. Async has no clean handle time and no real close — staff to the active handling minutes, manage open threads as a backlog against a per-use-case promise, watch the moments many threads come alive at once, and plan for the hard half the bot leaves you.

Quick quiz

Five questions. Pick an answer to each, then check your score.

1. How does async messaging relate to chat and email?

That ‘sometimes live, sometimes deferred, never closed’ nature makes it hard to plan.

2. Why is session length the wrong basis for staffing async?

Total session length is meaningless — staff to active handling time.

3. What’s distinctive about async concurrency?

Most open threads are idle, so agents hold many — but simultaneous replies need attention together.

4. How should you set response-time targets?

The same channel carries different expectations — plan to the promised response per use case.

5. What does bot blending leave the human agents on messaging?

Plan for what the bot leaves you: the hard half, mid-conversation.