WhatsApp, in app messaging and social inboxes have turned a lot of contact centres into asynchronous messaging teams. A customer writes, goes away, comes back an hour later, writes again. The conversation can stay open for a day or more. Then someone has to plan staffing for it, and the first question is always the same: which handle time do I use?
Pick the wrong one and the plan is off by a huge margin, in either direction. In the example below, one common shortcut gives you 3 agents where the work needs 11, and another gives you 195. This guide shows why, with a simple Erlang C model you can rebuild with your own numbers.
Why async messaging is hard to plan
Voice has a clear start and end. Async messaging does not. As Community WFM points out, a thread has no defined end and can stay open for weeks, which makes duration hard to predict.
Peopleware gives a useful way to think about it: one initial contact creates several subsequent interactions, sometimes in a later interval or the next day. Their example is 100 initial contacts a day with 4 follow ups each, which is 500 interactions a day, not 100.
So there are three different numbers that all get called "volume" or "handle time":
- Conversations: how many customers start a thread.
- Interactions: how many times an agent has to pick up and reply.
- Elapsed time: how long the thread stays open from first message to close.
Only the second one is work. The agent is busy when writing a reply, not while the customer is away. Mixing these up is where the errors come from.
The setup
We used one peak hour with these assumptions:
- 60 new conversations start in the hour.
- Each conversation has 5 interactions that need an agent reply (the first message plus 4 follow ups), so the team handles 300 interactions an hour once the flow is steady.
- Each interaction takes 2 minutes of agent work, including the reading and the wrap up. That is 10 minutes of work for the whole conversation.
- The conversation stays open for about 3 hours from start to close.
- Target: 80% of customer messages answered within 15 minutes.
The workload is 300 interactions × 2 minutes = 600 minutes, or 10 hours of work in the hour. In Erlang terms that is 10 Erlangs.
Three ways to plan it, and what each one gives you
| Method | What goes into the model | Workload | Agents needed on the floor |
|---|---|---|---|
| Correct: interactions × time per interaction | 300 interactions × 2 min | 10 Erlangs | 11 |
| Shortcut 1: conversations × time per interaction | 60 conversations × 2 min | 2 Erlangs | 3 |
| Shortcut 2: conversations × elapsed time (voice style) | 60 conversations × 3 hours | 180 Erlangs | 195 |
The first shortcut happens when your system reports handle time per message and the forecast is in conversations. It undercounts the work by a factor of 5, which is exactly the number of interactions per conversation. The team looks well staffed on paper and the inbox grows.
The second shortcut happens when someone treats a conversation like a call and uses how long it stayed open as its handle time. The thread was open for 3 hours, but the agent was working on it for 10 minutes of that. The plan asks for about 18 times the people the work needs.
The fix for both is the same: plan on interactions, with the handle time of one interaction.
What happens when conversations get chattier
The count of interactions per conversation is the number that moves most. A bot that hands over after three failed attempts, a complex product, or a customer who is chasing an update can all add replies. The chart shows the agents needed for the same 60 new conversations an hour as the replies per conversation go up.
Every extra reply per conversation adds about 2 agents at this volume. Conversation volume can stay flat while staffing need grows by close to half (from 9 agents at 4 replies to 13 at 6). If you only forecast conversations, you will not see it coming. Track interactions per conversation as its own line in the forecast, by contact type. This is also why AI deflection changes your staffing model: the contacts that reach people are longer and have more back and forth.
Does the response time target matter?
For a very short response target, yes. For anything beyond a few minutes, hardly at all. Each interaction is a small piece of work, only 2 minutes, so a 15 minute target already gives the queue plenty of room.
| Response target (80% answered within) | Agents needed | Occupancy |
|---|---|---|
| 2 minutes | 12 | 83% |
| 5 minutes | 11 | 91% |
| 15 minutes | 11 | 91% |
| 1 hour | 11 | 91% |
| 4 hours | 11 | 91% |
Past 5 minutes the answer does not change, because the agents are close to fully busy at 11 and the model cannot go lower without the queue growing without limit. The practical meaning is this: a longer promise to the customer does not shrink the team in the busy hour. What a longer response time does give you is the option to move work out of the peak and into quieter hours, so the plan should be built on the day's total workload, not only the peak.
Occupancy of 91% is also high for a team that has to read, think and write all day. See why a lower occupancy target protects retention before you plan to run an inbox team that hot.
Turning the floor number into a roster
The 11 agents above are the people needed on the floor in that hour. You still need to add shrinkage for breaks, training, meetings and absence. At 30% shrinkage, the roster for that hour is 11 ÷ (1 − 0.30) ≈ 16 people, not 11 × 1.3. The difference matters, as the shrinkage formula guide shows. If agents also handle more than one thread at a time, work that out with your real data first. The chat concurrency guide explains why the usual formula overstaffs when threads overlap.
A simple build for your own team
- Pull 8 weeks of data by contact type: new conversations per interval, and every agent reply with its timestamp.
- Calculate interactions per conversation and the handle time of one interaction. Peopleware suggests splitting the handle time into writing and research, wrap up, and before chat work.
- Forecast conversations and interactions per conversation separately, then multiply. Spread the follow ups over the next intervals, as they do not all arrive in the first hour.
- Set a response target per message, not per conversation. Peopleware suggests starting at your phone target until you have your own data.
- Run the interaction workload through Erlang C with the handle time of one interaction. Try it in the free Erlang C calculator.
- Add shrinkage by dividing, then check the plan against the day's total workload.
Key takeaways
- Plan on interactions, not conversations and not open time. In the example, that is 11 agents, against 3 or 195 from the two common shortcuts.
- Interactions per conversation is the number to watch. Each extra reply adds about 2 agents at 60 new conversations an hour.
- A response target beyond about 5 minutes barely changes the staffing in the busy hour, because each reply is a small job.
- Convert to a roster by dividing by (1 − shrinkage), and keep occupancy at a level agents can sustain.
The numbers in this article come from a simple model based on the stated assumptions: follow up messages flow steadily, one agent handles one reply at a time, and replies take 2 minutes each. Use your own data for planning.