Formula to Calculate Effective First Response Time (Excluding Courtesy and Partial Replies)

Why the classic first response time doesn't work

First response time (FRT) is calculated, in most inboxes, as the difference between the customer's first message and the business's first outgoing message. It's easy to measure, and that's why it's used. The problem is that it treats two things as equivalent when they aren't: a 'hi, I'll be with you in a moment' and a response that actually resolves the inquiry or moves it forward.

When the team learns that the metric rewards responding quickly and nothing more, the incentive is obvious: greet first and resolve later. FRT goes down, the customer keeps waiting for the same thing, and the number stops being useful for making decisions. What you want to measure is how long the business takes to give a response that's useful to the customer, not how long it takes to acknowledge receipt.

This page is the method to calculate it: how to classify each outgoing message, the formula, an example with numbers, and how to report it without fooling yourself. There are no market figures here because they aren't needed: you apply the formula with the data from your own inbox.

First define what an effective response is

Before calculating anything, write the rule. An effective response is the first outgoing message that meets at least one of these conditions: it resolves the inquiry, delivers the requested information, asks for the exact information missing to resolve it, or confirms a concrete action (appointment, order, shipment) with the information necessary for the customer to know what comes next.

Everything else stays out of the numerator. That includes greetings, acknowledgments of receipt, 'we're transferring you now', 'we'll contact you shortly', and also partial responses: messages that contribute something but don't close the step, like answering one of the three questions the customer asked or giving a price without stating availability or how to proceed.

The uncomfortable part is that the classification can't be done by a machine without judgment. A message like 'yes, we have it' can be effective (if the customer asked whether a specific item was in stock) or partial (if the customer asked about price, stock and shipping). That's why the table in the next section matters more than the formula: the formula is a subtraction, the classification is where the measurement is won or lost.

Classification table: what counts and what doesn't

Notice that the same phrase appears twice with different verdicts. That's what makes this metric more honest than the classic TPR and also more laborious: it can't be fully automated without reviewing the context of the conversation. If you want to measure it seriously, someone has to audit a sample.

The formula

For each conversation, take the timestamp of the customer's first incoming message and the timestamp of the first outgoing message classified as effective. The difference, in minutes, is the effective first response time (EFRT) of that conversation.

• EFRT = (timestamp of the first effective response − timestamp of the customer's first message)
• Only outgoing messages from the human team or suggested by AI and approved by the team count.
• Courtesy messages and partial responses are discarded from the calculation, not averaged.
• If the conversation never receives an effective response, it doesn't go into the average: it goes into a separate rate, the rate of unresolved conversations.
• If the customer writes again before the effective response, the clock does NOT reset: it keeps running from their first message.

The last point is the one that generates the most discussion. If the customer sends three messages in a row ('hi', 'I wanted to ask about the M size', 'and if you have it in black'), the clock starts at the 'hi', not at the third message. Resetting the clock with each customer message is a way of sugarcoating the number: it makes it look like you respond quickly when in reality the customer has been waiting twenty minutes.

A useful variant is to also calculate the TPRE from the customer's last message, to understand how long they wait after they finish explaining themselves. But the main number, the one you report, is from the first one. The other is diagnostic.

Example with numbers

Let's suppose a conversation. The customer writes at 10:00 'hi'. At 10:02 the team replies 'hi, how can I help you?'. At 10:04 the customer says 'I wanted to know if you have model X in blue and how much it costs'. At 10:08 the team answers 'yes, we do'. At 10:15 the team adds '$12,000'. At 10:16 the team adds 'and it arrives tomorrow if you order today'.

The classic TPR of this conversation would be 2 minutes (10:00 to 10:02). The TPRE is 16 minutes (10:00 to 10:16). The difference between the two numbers is exactly the customer's real wait. If your dashboard shows 2 minutes and the customer experienced 16, the dashboard is lying to you.

Now add a second conversation: the customer writes at 11:00 and at 11:30 the team replies 'I'll get you the info in a bit'. At 12:00 they reply with the complete info. The classic TPR is 30 minutes; the TPRE is 60. And a third one: customer at 14:00, the team never replies with anything that resolves it. That conversation doesn't go into the average: it goes into the unresolved rate, which is reported separately because it's a different problem.

How the number is reported

An average alone says nothing. Always report three things together: the median TPRE (not the average, because a three-hour conversation distorts everything), the 90th percentile (how long the 10% who wait the longest wait) and the rate of conversations without an effective response. With those three numbers you have an honest picture.

The gap between classic FRT and EFRT is the most revealing metric of all. If your FRT is 3 minutes and your EFRT is 25, you have a team that acknowledges receipt quickly and resolves late. That is a process problem, not a typing speed problem, and it is not fixed by asking the team to type faster.

What to do with the result

If the gap is large and the EFRT is high, the problem is almost never that the team types slowly. It is usually one of these three: the team does not have the information at hand and has to go look for it, the conversation is transferred and comes back, or the volume is such that no one can keep up. Each cause has a different fix and it is best to diagnose before touching anything.

• If the team greets and then disappears: information is missing at hand. Templates with frequent data and saved replies address this.
• If the EFRT rises with volume but the gap stays the same: it is capacity. Look at how many simultaneous conversations each person can handle.
• If the gap grows but the EFRT stays the same: the team is greeting too much. Check whether the old metric is incentivizing empty greetings.
• If the unresolved rate is high: there are conversations that get lost. That is the most expensive problem and the one that shows up least on dashboards.

Measuring this by hand is feasible with a sample: take 50 conversations from the month, classify the outbound messages with the table above, and calculate. You do not need to automate to start; you need the rule written down and an hour of work. If the number worries you, only then does it make sense to think about how to measure it continuously.

Mistakes that ruin the measurement

• Classifying by message length: a long message can be a disguised partial response.
• Counting the automatic welcome message as an effective response. It is not: it is industrialized courtesy.
• Resetting the clock with each customer message. It inflates the result in your favor and does not reflect the real wait.
• Averaging without looking at the 90th percentile. A low average with a long tail means that you leave some customers waiting for hours.
• Excluding conversations without a response from the report. They hide the worst case.
• Changing the definition of 'effective' halfway through so the number improves. If you change the rule, re-measure the entire period.

The last one is the most tempting and the most destructive. If in March you define effective as 'resolves' and in April as 'contributes something', the two months are not comparable and you have lost the historical series. The definition is written once, dated, and respected. If it has to be changed, it is changed going forward and the change is noted.

How it fits with the rest of your metrics

TPRE does not replace the classic TPR: it complements it. TPR tells you how long it takes for the business to appear; TPRE tells you how long it takes for it to be useful. Together they give you the gap, which is the indicator of whether the team is responding for the metric or for the customer.

This metric relies on the same logic as two others we have already covered on the site: the formula to calculate the saturation point of an inbox, which tells you when wait time starts growing faster than the arrival of messages, and the formula to calculate the hourly cost of an agent, which tells you how much each minute of that wait costs. All three are read together: TPRE tells you how long the customer waits, saturation tells you why, and hourly cost tells you how much to invest to bring it down.

If you use a tool with AI suggestions on the official WhatsApp API, such as Wando, the calculation does not change: the AI suggests and the team approves, so the message that goes out is still the business's responsibility and is classified with the same table. What does change is that having frequent responses at hand usually shortens TPRE without touching staffing. But that you verify with your own numbers, not with ours.