Response Time SLA Calculator

What a response-time SLA actually promises

A service level has two parts: a wait, and the share of contacts that must be answered inside it. Contact centers write it as a pair, 80/20 for phone, and the live-chat version most teams inherit is 80/60: eight in ten conversations get a human reply inside a minute. Neither number is a law of nature. Both are a choice about how much idle capacity you are willing to pay for in exchange for how rarely a customer sits in a queue.

Chatbots complicate the promise in a way that is easy to miss. The bot answers everyone, instantly, so the first response time metric is satisfied on every conversation before a human is involved. If 20% of conversations escalate and the other 80% get a one-second bot reply, a blended average can sit comfortably under two minutes while the escalated fifth waits eight or nine. The metric that should expose a staffing gap is drowned by the traffic that never needed staff.

The three response times this calculator reports

Feed it one peak hour and it separates the figure your dashboard prints into the three quantities inside it.

Bot turn

The bot's own first reply. Rule-based bots return in well under a second; LLM-backed ones take one to three, longer if they retrieve documents first. This is a latency measurement rather than a service measurement, and when it drifts the fix is an engineering ticket, not a schedule change. A single fully blended FRT that counts the bot as a responder collapses to this number, which is why we do not report one.

Blended, bot plus human

The most honest version of the average many analytics panels show: the human wait counted for the conversations that escalated, the bot reply counted for the rest, weighted by volume. It is still a blend of two populations with different experiences, and the calculator prints the ratio between it and the human figure so you can see how much of the real wait it shows. On the defaults that ratio is 20%.

Human first reply after handoff

The bot turn plus the Erlang C average speed of answer. This is the number an escalated customer experiences, the number the SLA is about, and the number to report as your human FRT. Our first response time entry makes the same argument from the metric side: track the bot turn and the post-handoff wait as two figures, never as one.

How Erlang C turns handoffs into a wait

The model takes three inputs. Handoffs per hour times handle time in hours gives the offered load in erlangs, which is the number of agents that would be exactly fully busy if work arrived in a perfectly even stream. Agents times the chats each one holds at once gives the servers. Load over servers is occupancy. From those, the Erlang C formula returns the probability that an arriving handoff finds every server busy and has to wait, and from that probability the service level and the average speed of answer follow directly.

The property that surprises people is how badly the formula punishes small teams. Hold occupancy at 70% and vary only headcount: a one-person desk makes the customer wait 70% of the time, a ten-person desk at the identical occupancy does it 22% of the time. Our handoff design guide works through that table in full, and the engine on this page reproduces all six of its rows to the published decimal, because both compute the same formula rather than quoting a textbook. The practical consequence is that a two-person chat desk cannot buy an 80/60 target with effort. It buys it with slack, or with concurrency, or by sending the queue fewer conversations.

A worked example

The defaults describe a synthetic small ecommerce support desk, not a customer deployment, and they are deliberately consistent with the scenario our deflection rate calculator uses: a bot that escalates about one conversation in five. In its busiest hour the bot closes 160 conversations and hands 40 to humans. Three agents are online, each holding two chats, and an escalated conversation takes eight minutes. The team has promised a human reply within 60 seconds on 80% of handoffs.

Three agents look adequate on load alone: 5.33 erlangs against six servers is 88.9% occupancy, which a spreadsheet would call efficient. The queue disagrees. Seven in ten handoffs wait, the average wait is 8 min 34 s, and one in ten escalated customers waits 23 min 35 s or longer. Meanwhile the blended first response is 1 min 44 s, a fifth of the 8 min 35 s an escalated customer actually experiences once the bot turn is included. A support lead watching the blend would see a desk that is slightly slow. A customer who needed a person would see one that is not answering.

One more agent changes the shape of the hour rather than the margin. Occupancy falls to 66.7%, the wait probability to 22.1%, the average human wait to 40 s, and the staffed service level clears the target at 84.2%. At the default fully loaded cost of $24.30 an hour, that is what the promise costs in the peak. A fifth agent would take the service level to 97.1% and the average wait to 5.4 s: the next $24.30 an hour buys about 35 seconds off an average that is already inside the target, which is usually where to stop.

The hours nobody is there

The example does not end at four agents, because the bot does not stop escalating when the team logs off. The defaults assume 75% of handoffs land during staffed hours and the rest wait about eight hours for a person. Every one of those overnight handoffs breaches a 60-second target, so once they are counted the overall service level for the four-agent team drops from 84.2% to 63.1%, and no daytime headcount can lift it above 75%.

The calculator reports both figures because they lead to different fixes. A staffed-hours miss is a scheduling problem. An overall miss with a healthy staffed figure is a coverage problem, and the cheap response is not a night shift. It is a bot that says so: a handoff that states a checkable window, captures a contact method that outlives the session, and routes the genuinely urgent case somewhere real. A wait the customer agreed to is experienced very differently from the same wait with no warning, and the SLA you publish should describe the promise you can keep.

Concurrency, and where the approximation breaks

Chat economics rest on one agent holding several conversations at once, and the calculator models that by multiplying agents by concurrency to get servers. Two agents at three chats each queue like a six-person voice desk, which is the mechanism behind every live-chat business case. It is also an approximation with a ceiling. Real agents slow down on every open conversation when they accept another, so handle time rises with concurrency and the slots are not interchangeable. Past three the arithmetic starts to overstate capacity, and the calculator warns at four and above.

If you want the model to stay honest at higher concurrency, raise handle time to what it measures at that concurrency rather than what it measures at one chat. The number you need is already in your helpdesk: filter handled conversations by how many were open on the agent at the time.

Why we built it this way

Handoff advice is almost entirely about when the bot should escalate. Across the platform reviews on this site, the handoff scenario tests whether the transfer happens, how the context arrives, and how the agent view looks. What none of them can test, and what a bot builder's analytics rarely separates, is whether anyone was there to receive it inside the promised time. Helpdesk products report that after the fact; nothing forecasts it before the schedule is set, because the answer sits on the operator side, in a staffing plan and an arrival pattern the platform never sees.

The inputs here are the smallest set that answers the question: one peak hour of bot activity, the team on shift, a handle time, and the promise. All of them are in a bot analytics panel and a helpdesk report already. We chose Erlang C over a simpler load-divided-by-capacity sum because the sum is exactly the calculation that makes three agents look sufficient in the example above, and it is the calculation most small teams stop at.

Reducing the queue from the other side

Every lever in the model works in both directions, and the cheapest one is often not a seat. Cutting handoffs per hour lowers the offered load, and because Erlang C is steep near capacity, a modest fall in escalations near the edge buys more service level than a seat does. The escalation rate is therefore a queueing metric as much as a quality one. Tightening handoff rules so the bot stops transferring conversations it could have finished, improving the knowledge base behind the answers it gives, and using a warm transfer that carries context so the human handle time falls: each of these moves the same numbers this calculator prints.

Watch the quality side while you do it. A service level bought by making the bot harder to escape shows up as fewer handoffs, a better queue, and a CSAT drop a month later. Our CSAT calculator is the counterweight, and first contact resolution is the metric that tells you whether the faster answer was also the right one.

What this calculator deliberately is not

It is not a workforce-management system. It sizes one hour, and a real schedule has to cover every hour with a different arrival rate, shrinkage for breaks and training, and skills that are not interchangeable. Use it to understand the shape of your peak and the cost of your promise, then plan the week in whatever tool plans your schedule.

It does not model abandonment. Erlang C assumes every customer waits as long as it takes, so on a desk where people actually give up it overstates the queue, and it says nothing about the customers who left. If your chat platform reports abandoned handoffs, a rising figure is the queue you are seeing here made visible.

It does not price the bot. Whether the extra seat is cheaper than reducing the handoff rate belongs in the bot vs human cost calculator, and whether the deflection that reduced the queue was real belongs in the deflection rate calculator.

Limitations you should state alongside the number

Erlang C assumes Poisson arrivals, exponentially distributed handle times, customers who never abandon the queue, and interchangeable servers. Real chat violates every one of these to some degree. Arrivals cluster after a marketing send or an outage, handle times have a long tail, customers leave, and an agent holding four chats is not four agents. The figures are a shape, and a good one, but they are not a forecast to the second.

The off-hours model is deliberately crude: a single share of handoffs and a single typical wait. A desk with an evening shift and a weekend gap has several off-hours populations with different waits, and the honest treatment is to run the calculator once per coverage pattern.

Everything here is decision support for an operating question, not financial advice, and no output should be the sole basis for a hiring commitment. Where a figure is going into a plan, put the peak hour you used, the concurrency you assumed, and the staffing table in front of whoever signs it.

Related Chatbotscape tools and resources

Some review links below go to platforms we may earn a commission from. That relationship does not affect scores, rankings, or what this calculator computes. See our affiliate disclosure for how it works.

• Chatbot handoff design guide — coverage, queue, and the offline path, with the Erlang C tables this engine reproduces
• Deflection rate calculator — whether the handoffs that stopped arriving were real
• Bot vs human cost calculator — the seat versus the bot, priced
• Containment rate calculator — how many conversations the bot really finished
• Chatbot CSAT calculator — the quality check on a faster queue
• Chatbot metrics guide — first response time, escalation, and satisfaction on one dashboard
• The chatbot KPIs a board actually cares about — how to present a split FRT upwards
• Live chat — where concurrency comes from and what it costs
• Average handle time — the input that moves this model most
• Intercom review — resolution-priced AI on top of a human inbox, where the queue this page models is the cost driver
• Tidio review — a live-chat-first platform with a chatbot layer on top, the shape of desk this calculator sizes

FAQ

How do you calculate a response time SLA?

A response-time SLA is a target wait plus the share of contacts that must be answered inside it, written 80/60 for 80% within 60 seconds. To compute whether a team meets it, take the handoffs arriving per hour and the average handle time to get the offered load in erlangs, divide by agents times concurrency to get occupancy, then run Erlang C to get the probability a handoff waits at all. Service level is one minus that probability times exp(minus (servers minus load) times target over handle time). The calculator does all of this and also solves for the smallest team that clears the target.

What is a good first response time for a chatbot?

There are two numbers and they should never be averaged. The bot's own first reply should be effectively instant: under a second for a rule-based bot, one to three seconds for an LLM-backed one, and past about five seconds the calculator flags a latency fault. The human first reply after a handoff is the one customers feel, and the common live-chat target is a minute or less during staffed hours with a stated wait off-hours. A single blended average across every conversation is dominated by the bot turn and hides the human queue. Our first response time glossary entry publishes working bands for both.

What is Erlang C and why use it for chat?

Erlang C is a 1917 queueing formula, derived for telephone exchanges and adopted by contact centers for staffing, that turns an arrival rate, a handle time and a headcount into a probability of waiting and a service level. It assumes random arrivals, exponential handle times, no abandonment and interchangeable agents. Chat breaks the last assumption through concurrency, which the calculator approximates by treating each agent as several servers, and it warns when that approximation is being stretched.

Why does the calculator ask for a peak hour instead of a daily average?

Because queues form in peaks. A team that is comfortable on the daily average can be badly over capacity at 11 a.m. on Monday, and the customers who escalate then are the ones who wait. Size the peak, then decide how much of the day you want to carry that headcount for.

How does off-hours coverage affect the SLA?

A bot escalates around the clock and a day team does not answer around the clock, so every handoff that lands at night breaches a target measured in seconds. The calculator weights the staffed-hours service level by the share of handoffs that arrive while someone is online. If 25% arrive off-hours, the overall service level cannot exceed 75% however well the day shift performs.

What occupancy should a chat team plan for?

The calculator warns above 85%. Small teams need lower occupancy than large ones to hit the same service level, because with few agents the chance that all of them are busy at once is much higher. A two-person desk that wants an 80/60 target usually has to carry visible slack, and the staffing table on the page shows exactly how much.

Does the calculator send my data anywhere?

No. All math runs in your browser. Nothing you type is uploaded, stored, or logged, and refreshing the page clears it.

Can I embed this calculator on my site?

Yes, free. Copy the iframe snippet from the embed section on this page. The embed strips Chatbotscape navigation and keeps the calculator plus attribution.

Sources and basis

• Queueing model.Erlang C, computed rather than quoted. Erlang B is evaluated with the stable recurrence B(k) = A·B(k−1) / (k + A·B(k−1)), Erlang C as N·B / (N − A(1 − B)), the service level as 1 − C·exp(−(N − A)·t / AHT), the average speed of answer as C·AHT / (N − A), and the 90th-percentile wait by inverting the exponential tail. The engine reproduces the closed forms it must: C equals occupancy for a single server, and the six rows of the constant-occupancy table in our handoff design guide match to the published decimal (the guide evaluates Erlang B by an equivalent inverse recurrence). Reference derivation: Erlang C formula, checked 3 September 2026. Primary source: A. K. Erlang, “Solution of some problems in the theory of probabilities of significance in automatic telephone exchanges,” Elektroteknikeren 13 (1917), English translation in The Post Office Electrical Engineers' Journal 10 (1917-18).
• Service-level convention. The 80/20 phone and 80/60 chat pairs are inherited contact-center defaults rather than standards; they are used here as editable examples.
• Cost default. $24.30 an hour is an $18 wage at a 1.35 overhead multiplier, the same worked figure our bot vs human cost calculator uses. The 8-minute handle time and roughly one-in-five escalation share match the synthetic desk in the deflection rate calculator. All are examples, not benchmarks.
• Response-time bands. Chatbot first response time carries the editorial working ranges for the bot turn and the post-handoff human turn, with the collection date on the entry.
• No hands-on deployment data. The worked example is a synthetic scenario. Nothing on this page reports measured waits from a customer account, and no Chatbotscape review has timed a handoff outside staffed hours.