Formula to calculate the rate of conversations that exceed the target wait time (SLA breach rate)

What exactly the SLA breach rate measures

The SLA breach rate (the rate of failing to meet the target wait time) is the percentage of conversations that waited longer than what the business defined as acceptable before receiving a first human response. It does not measure how long it took: it measures how many times the promise was broken. It is the difference between saying "we take 40 minutes on average" and saying "in 1 out of every 4 conversations we take more than 15 minutes." The second statement is the one that is useful for managing, because the average hides the tail.

It is a binary indicator per conversation: each conversation either breaches the SLA or does not breach it. That makes it easy to calculate and hard to gloss over. If instead you measure the average wait time, a week with many fast responses and a few abandoned conversations can produce an average that looks good while the customer's actual experience gets worse.

The formula, step by step

The base formula is a simple division: conversations that exceeded the target time, over the total conversations that entered the measurement window, times one hundred.

With that, you have the number. The rest of the page is about how to make that number useful for something.

Before calculating: the minimum case threshold

A breach rate calculated over 15 conversations says nothing: a single broken conversation moves the number by almost 7 points. Before publishing the indicator internally, define a case floor below which the data is marked as "inconclusive" instead of being compared against the previous week. The following table is a reading guide, not a statistical rule: it helps ensure no one celebrates or panics over noise.

Weekly tracking table (to copy and fill in)

This is the spreadsheet worth maintaining: one row per week, always with the same columns and always with the target time noted. If the target changes along the way, note the change and cut off the backward comparison: don't compare a week with a 15-minute SLA against another with a 30-minute SLA.

The "after-hours" column is there for a specific reason: if the business operates from 9:00 to 18:00 and someone writes at 23:00, that conversation did not break the SLA, it simply arrived when no one was there. Mixing them inflates the breach rate and makes the team lose credibility with the numbers. They are always kept separate.

How to separate real breaches from business hours

The clean breach rate is calculated only on conversations that came in during business hours. After-hours ones are measured separately, with their own indicator: what percentage of messages that arrive after hours receive a response within the first hour of the next day. They are two different problems and they are fixed with different things.

• Within business hours and breaks the SLA: it is a capacity or assignment problem. It is fixed with more staff in the critical time slot, better distribution of conversations, or fewer parallel tasks per operator.
• After hours and breaks the SLA: it is a coverage problem. It is fixed with an auto-reply by schedule, a reduced shift, or explicitly accepting that no one is available and saying so.
• Within business hours but the conversation was left unassigned: it is a process problem. The conversation came in, no one took it, and the clock kept running.
• Within business hours, assigned and without a response: it is a per-operator workload problem. It is measured per person and per time slot, not by overall average.

Without that separation, the overall breach rate mixes four causes with four solutions and does not allow you to decide anything.

Example calculation with actual numbers

Let's suppose a week with 140 conversations during business hours and a target of a first human response within 15 minutes. Of those 140, 35 exceeded 15 minutes. The breach rate is (35 ÷ 140) × 100 = 25%. One out of every four conversations waited longer than what the business said it would wait.

Now, the same business had 60 conversations outside business hours. If you added them to the calculation, the denominator would go to 200 and the breach rate would drop to 17.5% without anything having improved: the problem was simply diluted among conversations that shouldn't have counted. That is the most common mistake when reporting the metric, and it is the reason the outside-hours column exists in the table.

What to do with the result (and what not to do)

The breach rate is not a goal you can lower from one day to the next. It is a thermometer. What you decide with it is where to look: if the overall number is good but one time slot is bad, the problem is coverage in that time slot. If all time slots are similar, the problem is total capacity or the assignment process.

1. 1Calculate the overall breach rate for the week and write it down in the table.
2. 2Calculate the same number by time slot (morning, midday, afternoon) to find the peak.
3. 3Calculate the breach rate by operator, but only to detect extreme cases, never for a public team ranking.
4. 4Cross the non-compliance peak with the number of simultaneous conversations in that time slot: if they match, it is capacity; if they don't match, it is process.
5. 5Choose a single action for the following week and measure again. Changing three things at once makes it impossible to know which one worked.

What you should not do is set a breach rate goal of zero. There will always be conversations that break the target: a demand peak, a complex inquiry, a holiday. A goal of zero makes the team stop reporting real cases or start closing conversations so they don't count. An acceptable range, reviewed every month, is more useful than an unreachable zero.

Errors that invalidate the calculation

• Using the record's insertion date in the database instead of the message timestamp: if there was a history import, almost all messages will appear to be from the same time and the indicator becomes useless.
• Counting the schedule auto-reply as the first human response: it lowers the breach rate artificially and hides the coverage problem.
• Excluding conversations that breached the SLA from the denominator: it is the equivalent of raising the average by lowering the grades.
• Changing the target time without noting it: two weeks with different targets cannot be compared.
• Measuring over fewer than 30 conversations and drawing conclusions: it is noise, not signal.
• Reporting only the average wait time: it hides exactly the queue that this indicator exists to show.

Frequently asked questions about the SLA breach rate

Short answers to the questions that come up when a WhatsApp support team starts measuring this indicator.