How many live chat agents do I need?

Take your chats in your busiest hour, multiply by the average handle time in hours to get the concurrent workload, then divide by how many chats an agent handles at once (concurrency). Finally divide by your target occupancy and by one minus shrinkage to cover breaks and admin. This calculator does all of that for you and rounds up, then also gives the full-time equivalents and monthly cost.

What is chat concurrency?

Concurrency is the number of live chats one agent handles at the same time. Unlike a phone call, a chat agent can run two or three conversations at once. Insurance support sits lower (often 1–2) because policy, claims, and coverage questions are complex; simpler queues run 2–3 or more. Roughly speaking, doubling concurrency halves the number of agents you need, which is why it is the single most important input.

How is this different from an Erlang or call-center calculator?

Erlang C assumes one call ties up one agent until it ends. Live chat breaks that assumption because agents multitask across several chats, so the headline headcount uses a transparent workload-and-concurrency model built for chat. But you get the best of both: in Advanced mode the tool layers a concurrency-adjusted Erlang C on top to report your service level (percent answered within a target time), average speed of answer, and a sensitivity table.

What service level should I target for live chat?

A common live chat target is answering 80% of chats within 30 to 40 seconds, though proactive and high-touch insurance queues often aim faster. In Advanced mode you set your own target (percent answered within X seconds) and the tool grades your plan against it with concurrency-adjusted Erlang C, showing the service level, average speed of answer, and how it changes with one more or fewer agent.

What's the difference between reactive and proactive chat staffing?

Reactive chat is when customers start the conversation, so you staff straight from your chat volume. Proactive chat is when you invite visitors to chat, where demand depends on traffic and acceptance. In Advanced mode, switch the demand model to proactive and enter your visitor count and acceptance rate; the tool derives the resulting chat volume (visitors times acceptance) and sizes the team the same way.

What is a good occupancy for chat agents?

Occupancy is the share of paid, logged-in time agents spend actually handling chats. For live chat, 60–75% is the healthy range — high enough to be efficient, low enough to absorb spikes and avoid burnout. Above about 85%, wait times climb and quality drops. The calculator reports your agents' occupancy at peak and flags when you are running too hot.

What average handle time should I use for insurance chat?

Insurance chat typically runs about 10–15 minutes per conversation, longer than retail because policy, billing, claims, and coverage questions take explaining — and licensed or complex lines run longer still. The calculator defaults to 12 minutes, but you should replace it with your own measured average handle time if you have it, since it directly drives how many agents you need.

How do I account for shrinkage?

Shrinkage is the share of paid time agents are not available for chats — breaks, training, meetings, coaching, admin, and absence. In-house teams typically run 25–40%. The calculator defaults to 30% and inflates the required headcount accordingly, because you cannot staff as if everyone is on chat 100% of their shift.

How many chats can one agent handle at once?

For general support, 2–3 simultaneous chats is common for experienced agents, and top performers manage up to 4. For complex insurance work — claims, underwriting, coverage advice — 1–2 is more realistic so quality and compliance do not suffer. Set it with the concurrency slider; it is the biggest lever on the result.

Is this calculator accurate?

It is a planning estimate, not a workforce-management system. It sizes the team from your volume, concurrency, occupancy, and shrinkage, but it does not model the randomness of arrivals within an hour, chat abandonment, or skill-based routing. Use it to right-size and budget your chat team, then validate against your own historical data — or with a WFM professional — before hiring or rostering.

Can it forecast growth, attrition, and my hiring gap?

Yes. In Advanced mode you can enter your current headcount to see your hiring gap (how many more to hire, or spare capacity), an annual chat-volume growth rate to project staffing and cost 12 months out, and an annual attrition rate to estimate the hires you need each year just to stay staffed — insurance chat teams commonly run 30–45% attrition. You can also add a per-seat tooling cost and a management-overhead percentage for a fuller all-in cost and cost per chat.

Yes — 100% free with no signup. Everything is calculated instantly in your browser and your numbers never leave your device. sem.chat is an AI chat and voice product — this tool is a free resource, not a lead form.

Insurance Live Chat Staffing Calculator

Live chat staffing comes down to one idea: how much work arrives in your busiest hour, and how much of it one agent can carry at once. This calculator turns that into a defensible headcount using a transparent workload-and-concurrency model — the approach contact-center practitioners recommend for chat.

It works from your chat volume and open hours

It normalizes whatever you enter — chats per day, week, or month — into an average per open hour: avg chats/hour = chats per week ÷ (hours/day × days/week). That keeps a 24/7 operation and a business-hours desk on the same footing.

It sizes for the peak, not the average

Your busiest hour is what creates waits, so it multiplies by a peak factor (default 1.6×): peak chats/hour = avg chats/hour × peak factor. Staffing to the average would leave customers queueing every lunchtime spike.

It models concurrency for the headcount

A chat agent runs several conversations at once, so the workload at peak is peak chats/hour × (handle time ÷ 60) concurrent chats, and agents = workload ÷ concurrency. Standard Erlang C assumes one call ties up one agent until it ends — as CallCentreHelper notes, that misfits chat, so the headline headcount uses this transparent concurrency model. (In Advanced mode we then layer Erlang C on top as a service-level check — see below.)

One agent, three live chats at once — that's concurrency, and it's why chat needs far fewer agents than phone for the same volume.

It allows for occupancy and shrinkage

You can't run agents at 100%, and not all paid time is spent chatting. So it divides by your target occupancy and by one minus shrinkage, then rounds up: agents at peak = ceil( workload ÷ concurrency ÷ occupancy ÷ (1 − shrinkage) ). Occupancy leaves headroom for spikes; shrinkage covers breaks, training, meetings, and admin.

It converts to FTEs across all open hours

The peak number is a scheduling target for the busy hour. To staff the whole week without overstaffing quiet hours, FTEs use the average load: FTE = (avg chats/hour × handle time/60 ÷ concurrency ÷ occupancy ÷ (1 − shrinkage)) × weekly open hours ÷ 40.

It turns headcount into cost

Add a fully-loaded hourly rate and it computes monthly cost = FTE × loaded rate × 173.2 productive hours (annual ×12), plus a true cost per chat. That makes the headcount a budget you can defend.

It runs three scenarios

Because every input is a range, it runs the calculation three times — Conservative (heavier handle time and shrinkage, lower occupancy and concurrency), Likely (your inputs), and Aggressive (leaner) — so you plan for the busy days, not just the average one.

It grades service level with Erlang C (Advanced)

Switch to Advanced mode and the tool adds a concurrency-adjusted Erlang C lens. It treats each agent as concurrency parallel chat "slots", computes the offered load in Erlangs (arrivals/hour × handle time), and reports the share of chats answered within your target (e.g. 80% in 40s), the average speed of answer, and the percentage answered instantly. A sensitivity table then shows how service level, occupancy, and speed of answer shift if you staff one or two agents above or below the recommendation — so the trade-off is explicit.

It plans your day, hour by hour (Advanced)

Advanced mode also distributes your daily volume across open hours using a realistic intra-day pattern (business-hours bell, lunch dip, evening-heavy, or flat), then sizes each hour individually. You get an hourly staffing chart, a roster table with the service level each hour, and a one-click CSV export for your workforce-management tool.

It handles reactive and proactive chat (Advanced)

Reactive chat sizes straight from chat volume. For proactive programs that invite visitors to chat, switch the demand model and enter your visitor count and acceptance rate — the tool derives the resulting chat volume (visitors × acceptance) and sizes the team the same way.

It can plan ahead

Advanced mode goes further still. Add a current headcount to see your hiring gap (how many to hire, or spare capacity), an annual growth rate to project staffing and cost 12 months out, and an attrition rate to estimate the hires needed each year just to stay level — insurance chat teams commonly run 30–45% attrition. You can also add a per-seat tooling cost and a management-overhead percentage for a fuller, all-in cost. It does not model within-hour arrival randomness, chat abandonment, or multi-channel blending — validate those against your own data.

A worked example — insurance claims chat

Say a claims team handles 3,000 chats a month, open 12 hours × 5 days, with a 15-minute handle time and agents running 1.5 chats at once. The chain looks like this:

Normalize to about 13 chats per open hour on average.
Apply a 1.6× peak factor → roughly 21 chats in the busiest hour.
Concurrent workload = 21 × (15 ÷ 60) ≈ 5.3 chats in progress at once.
Divide by 1.5 concurrency, 75% occupancy and (1 − 30% shrinkage), then round up → about 7 agents at peak.
Across all open hours that's roughly 4–5 FTEs; at a $35 loaded rate, about $28k/month, near $9 per chat.

Switch to Advanced and the Erlang C lens grades the service level and abandonment for that headcount, the day-planner spreads those agents across the day, and the sensitivity table shows what an eighth agent buys you. The Show example button loads a starting point instantly.

What good looks like — live chat benchmarks

Use these published industry ranges as a sanity check on your inputs — not a promise, since your own chat data always wins. Ranges are drawn from contact-center sources such as CallCentreHelper.

Metric	Typical range for live chat
Average handle time	8–15 min (claims & licensed lines longer)
Concurrency	1–2 complex · 2–3 mixed support
Target occupancy	60–80%
Shrinkage	25–40%
Service level	≈ 80% answered within 30–60s
Chat abandonment	under ≈ 5–8%
Agent attrition	30–45% (insurance support)

A note on estimates. This is a planning model, not a workforce-management system. Real staffing depends on how arrivals cluster within the hour, chat abandonment, the service level you commit to, and your agents' skill mix. The benchmarks come from published contact-center research such as CallCentreHelper. Validate against your own historical chat data — or with a WFM professional — before hiring or rostering decisions. sem.chat does not provide staffing or HR advice.

Insurance Live Chat Staffing Calculator