Support Staffing Model Template
Two documents and four sheets that forecast chat staffing by the hour and ticket staffing by the day, then check both against your actual roster.
Free download · No account needed
Chat Staffing Requirement
Caldera Gear Co., 339 chats this week, 8am to 8pm
| Naive ratio: total volume × handling time against scheduled hours | 33.9 required, 46 scheduled — 36% cushion |
| Erlang C, checked hour by hour against the same scheduled roster | 58 required, 46 scheduled — 12 hours short |
The hour the ratio never checks
| Hour | Offered load | Scheduled | Result |
|---|---|---|---|
| 3:00 PM | 2.40 Erlangs | 4 | 83.2% service level |
| 4:00 PM | 4.70 Erlangs | 4 | Unstable, no steady state |
| 5:00 PM | 3.60 Erlangs | 4 | 31.1% service level |
Nine of twelve hours run short against an 80%-in-2-minutes target once chat is checked hour by hour. The daily ratio's 36% cushion never sees any of them, including the one hour where the queue has no steady state at all.
Most support staffing plans compute one ratio: total volume multiplied by average handling time, checked against total scheduled hours for the day or the week. That ratio can look comfortable in aggregate while a specific hour underneath it is failing completely, because an average never checks any single interval on its own. Assembled's own staffing guide draws the channel line plainly: real-time queueing math fits chat and phone. It is not appropriate for a deferred channel like email, where a backlog can build for hours or days rather than a customer waiting live.
This pack forecasts volume at the grain it arrives in, hourly for a real-time channel and daily for a deferred one. It applies the formula each channel needs: Erlang C for chat or phone, a due-today check for tickets or email. Coverage by Hour checks that requirement against your actual rostered shifts at the same grain. Gap to Target asks one question of the result: is there a spare hour to reshuffle from, or does the whole cycle fall short. Pull the volume from a complete ticket export with real timestamps, not a pre-aggregated total.
Caldera Gear Co. forecast 339 chats and 850 tickets a week. The naive ratio, 339 chats at six minutes each against 46 scheduled hours, reads as a comfortable 36% cushion. Erlang C, checked hour by hour, needs 58 agent-hours against an 80%-in-2-minutes target: nine of twelve hours run short, and 4pm's 4.70 Erlang load makes an unstable queue with no steady state. Its ticket queue is the opposite: weekly capacity covers weekly volume, but zero weekend coverage puts 267 due Monday against 205-ticket capacity, which two weekend shifts clear to zero.
What's in the pack
Model Assumptions
States which formula applies to which channel and why. Assembled's own staffing guide draws the same line: Erlang C is not appropriate for a channel like email, where a backlog can build for hours or days instead of a customer waiting live.
Hiring Trigger Note
The test that decides whether a gap closes by moving hours you already have or needs new headcount, applied to both of Caldera Gear's channels. Converts a sustained shortfall into a hire using Soon.works' own shrinkage defaults, which run higher for a real-time queue than for back-office work.
Volume Forecast by Channel
Chat forecast hourly across the operating day, tickets forecast daily across the full week including the two days nobody is scheduled to open one. Neither channel gets averaged into the other before the sheets that follow apply their own formula to it.
Capacity Model
Erlang C's required headcount for chat, hour by hour, next to the naive volume-times-handling-time ratio the same data would produce with no queueing math at all. A due-today capacity ceiling for tickets, from scheduled agent-hours divided by handling time, the model a deferred channel actually fits.
Coverage by Hour
Required checked against actually scheduled at the same grain the volume arrived in, chat by the hour and tickets by the day, so a comfortable period total cannot hide the one interval that is failing. The same discipline the SLA reporting template applies once a target is already breached.
Gap to Target
Names the worst interval, checks for a spare hour to reshuffle from before recommending a hire, and checks the whole cycle's total before recommending a reshuffle. A chat gap is sometimes cheaper to close by deflecting repeat questions to an article than by adding a shift.
How it works
- 1
Send your volume, handling time and shift data
The historic volume export with real timestamps for each channel, handling time if your platform reports it separately, and your actual current shift schedule, not a target headcount someone wrote down once.
- 2
Name which channel is real-time and which is deferred
Chat and phone have someone waiting live; email and tickets get worked on their own schedule. River asks if it is not obvious from the data, since the two channels never share a formula.
- 3
Build the Capacity Model with the right formula per channel
Erlang C for the real-time channel, hour by hour, next to the naive ratio the same volume would produce without it. A due-today capacity ceiling for the deferred channel, day by day, against what is actually due rather than what merely arrived.
- 4
Check Coverage by Hour, then close the specific gap
Required against actually scheduled at the same grain, with the worst interval named rather than averaged away. Gap to Target states whether that gap closes by reshuffling hours already on the schedule or needs a new hire.
Frequently asked questions
Why does chat get a different formula than tickets?
Someone is waiting live on a chat, so the right model is a real-time queueing formula against each hour's offered load. A ticket queue has no one watching a clock in real time, so the real question is whether today's scheduled hours can clear what is actually due today, which Erlang C was never built to answer.
I've never run an Erlang C calculation. Can I still use this?
Yes. You send the historic volume, handling time and target; River runs the formula hour by hour and states the required headcount next to your actual schedule. You do not compute anything by hand, and Model Assumptions states exactly which numbers produced the result.
Does this set my service level target, or assume one already exists?
It assumes one exists, whatever your policy already states for each channel. Once you are meeting the coverage target this pack builds toward, the SLA reporting template is what measures whether you are actually meeting it on real tickets, breach by breach.
Does the staffing number account for shrinkage, breaks and training time?
Coverage by Hour compares on-queue agents to on-queue requirement, with no shrinkage adjustment on either side, because both already describe people present. Shrinkage enters once at the hiring step, converting a sustained on-queue gap into a headcount to actually hire, using your own measured rate or a documented typical range if you have none.
What format are the downloaded files?
Word documents for Model Assumptions and the Hiring Trigger Note, plus CSV spreadsheets for the four forecast and coverage sheets. Everything opens natively in Word, Excel, Google Docs or Sheets with no conversion step or special software required.
What does Edit with AI actually do?
It creates a free River workspace with this pack already installed, then asks for your volume, handling time and shift data by channel. River builds the forecast, runs the channel-appropriate formula, and checks the result against your actual roster in the same session.
Forecast next quarter's staffing by the hour, not the day
Take the documents and sheets blank, or install this pack in River and send it your volume, handling time and shift data by channel.
Edit with AI