Can I put email through an Erlang calculator with a long target answer time?

You can, and with a target of hours the Erlang formula collapses to the throughput answer, so the agent count is not wrong. But it tells you nothing about the turnaround, because it assumes steady arrivals inside the interval and no carry-over. The model here does the same throughput sum and then adds the backlog behaviour the turnaround depends on.

How do I handle emails that arrive overnight?

They are a backlog waiting at opening time, and behave like an extra peak at the start of the day. Either add them to the opening hour's volume when you estimate the peak factor, or measure the turnaround in working hours so that the overnight gap does not count against it. Most email SLAs are written in working hours for exactly this reason.

How to staff an email queue with a turnaround time

Nobody sits on hold for an email. That one difference makes voice staffing maths the wrong tool: there is no queue of customers to keep short, only a pile of work to keep from growing past a deadline. This guide sets out the model that fits, shows what the turnaround target does to the answer, and works through the figures from a question planners ask again and again.

Throughput, then turnaround

Email staffing has two constraints.

Throughput. The team must clear the day’s work within the staffed day. Daily volume divided by staffed hours is the average rate you must sustain, and volume multiplied by handle time is the hours of work.

Turnaround. No email may wait longer than the target. If arrivals were perfectly flat, throughput alone would satisfy this. They are not: there is a busy part of the day, and if capacity is set to the average, a backlog builds during it and drains afterwards. The email at the back of that backlog waits the longest, and the turnaround target caps its wait.

Describe the day with a peak factor (busiest hour divided by the average hour) and a peak length. With capacity c emails an hour, the backlog after the peak is (peak rate − c) × peak length, and it clears at c, so the longest wait is that backlog divided by c. Requiring it to stay under the turnaround T gives:

c ≥ peak rate × peak length ÷ (peak length + T)

Capacity is the larger of this and the average rate. A long turnaround lets you staff near the average; a short one pushes you towards the peak.

Worked example

500 emails a day, 12 minutes each, a four-hour turnaround, eight staffed hours, a peak of 1.5 times the average lasting two hours, 90 per cent target occupancy and 10 per cent shrinkage.

Work: 500 × 12 ÷ 60 = 100 hours of handling a day.
Average rate: 500 ÷ 8 = 62.5 an hour. Peak rate: 93.75 an hour.
Turnaround capacity: 93.75 × 2 ÷ (2 + 4) = 31.25 an hour. Throughput needs 62.5, so throughput binds and capacity is 62.5.
An agent at 90 per cent occupancy clears 60 ÷ 12 × 0.9 = 4.5 emails an hour, so 62.5 ÷ 4.5 = 13.9 agents on task.
After 10 per cent shrinkage, 13.9 ÷ 0.9 = 15.4, so 16 agents to schedule.

With a four-hour turnaround the peak does not matter: the backlog it creates, about 62 emails, clears well inside the target. Shorten the turnaround to 30 minutes and the picture changes. Turnaround capacity becomes 93.75 × 2 ÷ 2.5 = 75 an hour, which now exceeds the average, so it binds: 75 ÷ 4.5 = 16.7 on task, 19 to schedule. The same volume needs three more agents because the deadline no longer allows the backlog.

What this model does not do

It assumes one peak block of constant intensity and a constant staffing level through the day. Real days have a shape, and a real roster can put more agents on during the peak, which is cheaper than raising capacity all day. Once you are shaping staffing to the day, the week planner approach applies, with a workload rule per interval instead of Erlang. The model here is the right size for a budget or a headcount question: how many people, given this deadline.

It also treats every email as one touch. An email that generates a follow-up is new work arriving later, and belongs in the volume; a case that needs three touches is three emails with their own handle times, or one email with three times the handle time.

Try it with your own numbers

Inputs

Results

Agents to schedule

Each staffed day, after shrinkage.

Agents on task: 13.9
Capacity needed: 62.5/h
Agents if arrivals were flat: 13.9
Longest wait: 1.0 h
Backlog at the end of the peak: 63
Handling work per day: 100.0 h
Agent-hours per day: 111.1 h

Show the working

Workload = 500 × 12 min ÷ 60 = 100.0 hours of handling a day.
Throughput: 500 emails over 8 staffed hours is 62.5 an hour on average; the peak is 1.5 × that, 93.8 an hour, for 2 h.
Turnaround: with capacity c, the backlog after the peak is (93.8 − c) × 2 h and takes that ÷ c to clear, so c ≥ 93.8 × 2 ÷ (2 + 4) = 31.3 an hour keeps every wait under 4 h.
Capacity needed = the larger of throughput and turnaround = 62.5 an hour (throughput binds).
An agent clears 60 ÷ 12 × 0.90 = 4.50 emails an hour, so 62.5 ÷ 4.50 = 13.89 agents on task.
Shrinkage: 13.89 ÷ (1 − 0.10) rounds up to 16 to schedule.

Doing this for every interval of the week? Pebble WFM computes the requirement from your forecast and builds the roster. Free month, no card needed.

Common mistakes

Using a voice occupancy ceiling. There is always email waiting, so 85 to 90 per cent is sustainable. Going to 100 per cent is not; switching and system time still exist.
Measuring the turnaround in clock hours when staffing covers eight of them. Every overnight email then breaches. Write the SLA in working hours or staff the night.
Ignoring the peak because the turnaround is long. Check the longest wait the calculator reports; when it approaches the target, the peak is about to matter.
Forgetting the backlog carries. Work not cleared today is tomorrow’s opening peak. Throughput has to hold over the week, not just on the average day.

Where next

How to staff live chat with concurrency: the other channel where voice maths misleads.
How to calculate FTE from contact volume: turning a daily agent count into FTE.