Want help applying this guide?Ask the DripTell team
A customer sends a question at 9:00. Support replies at 9:04, so the first response dashboard looks healthy. The customer answers at 9:07 with the detail the agent asked for, then hears nothing until the afternoon. From the customer's side, that was not a four minute response. It was a conversation that went quiet after it had already started.
Measure next reply time for every customer wait after the first team response. Start the interval at the oldest unanswered customer message and stop it at the first useful public reply from the team. Keep intervals that have not received a reply visible as an open waiting tail. Do not let a fast greeting hide them.
The first reply is only the beginning
First response time answers one narrow question. How long did the customer wait before the team first engaged? It says nothing about the second, third, or sixth wait in the same conversation.
- 1Open the waitStart at the first customer message after the last useful team reply.
- 2Group the burstKeep later customer messages in the same open interval.
- 3Qualify the replyStop only on a useful public answer or a specific owned update.
- 4Keep both clocksStore calendar and business hours time without mixing them.
- 5Preserve the open tailKeep unanswered intervals visible with current age and owner.
That distinction is not theoretical. Microsoft's live conversation counter guidance starts a customer wait timer when a customer sends a message and resets it when the representative replies. Its service level overview explains that response targets can use customer service and holiday schedules when business hours matter.
The useful question is therefore not whether an agent sent something quickly once. It is whether every new piece of customer demand returned to an accountable owner in reasonable time.
Build waiting intervals from message events
Use the message history rather than a ticket status as the clock. A simple event rule is enough.
Start a new interval when the customer sends a message after the last useful team reply. If the customer sends two more messages before anyone answers, keep one interval and retain the first timestamp. Otherwise a fragmented message style would make the wait look shorter.
Stop the interval when the team sends a public reply that addresses the question or gives a specific, owned update. An internal note does not stop customer waiting. Neither does an automated receipt that merely says the message arrived. A useful update can stop the interval when it tells the customer what has happened, who owns the next action, and when another update will come.
Store the conversation, customer, channel, current owner, team, start, stop, elapsed time, business-hours time, and response type. If no qualifying reply exists, keep the interval open and calculate its current age.
Choose one clock and keep the other
Calendar time reflects the customer's lived wait. Business-hours time reflects the team's staffed commitment. Both can be valid, but they answer different questions.
Publish one as the service target and keep the other for diagnosis. If the promise says replies come during stated opening hours, business-hours time can govern the target. Calendar time should still remain visible because a message sent just after closing may feel old by the next morning.
Do not pause the customer clock simply because a case is snoozed, assigned to another team, or waiting for an internal approval. Those are causes of delay, not proof that the customer stopped waiting. Pause only when the customer has been clearly asked for something and the next action genuinely belongs to them. Preserve that state change as an event that can be audited.
| Observed pattern | Evidence to inspect | Likely operating cause | Useful response |
|---|---|---|---|
| First replies are fast but later replies are slow | Queue age before and after first reply | New work is favored over active conversations | Balance new and ongoing customer demand |
| Waits grow after reassignment | Ownership events and public reply times | Handoff changes the assignee but not acceptance | Require the receiving owner to accept the next action |
| Internal activity is high while customers wait | Notes, approvals, and public updates | Work is happening but no one owns communication | Add a customer-visible update rule |
| Calendar waits spike outside staffed hours | Calendar and business-hours distributions | Coverage or the stated promise does not match demand | Change coverage or set a truthful expectation |
| A few conversations contain many long waits | Customer reply count and issue outcome | The issue is looping or the answer is incomplete | Review the root cause and resolution path |
Report the tail as well as the middle
An average next reply time can improve while the worst waits get older. It can also be distorted by one long conversation that contains many customer replies. Use a small set of views instead.
Report the median answered interval to show the typical wait, a slow-tail percentile to expose long waits, the share answered within the stated target, and the count and age of open intervals. Add a conversation-level view so one message-heavy case cannot dominate the story. Use a fixed customer-message cohort and allow late replies to mature rather than selecting only intervals completed during the reporting period.
Segment only where the operating difference is real. Channel, service tier, issue type, language, staffed hours, and responsible team can explain different promises or constraints. Agent rankings usually explain less. A person who takes ownership of an old unanswered message should not inherit all the blame for the delay without the earlier queue history.
Use the measure to repair the queue
Review a sample of the longest open and answered intervals. Mark the actual cause such as missing ownership, work left in a team queue, an unrecorded handoff, approval delay, weak scheduling, or an update that never became customer-visible. Then change the mechanism that produced the silence.
A support workspace can keep the issue and next action together. A shared inbox makes ownership and customer-visible replies easier to inspect, while a connected customer record preserves context across contacts. Clear cases can use controlled automation, but exceptions should remain visible. Review the distribution in inbox reports, and keep sensitive notes behind appropriate security controls.
Set targets from the promise made to customers, the harm caused by waiting, and the team's real coverage. There is no honest universal number. The first reply opens the conversation. Next reply time shows whether the team keeps showing up after that.
Frequently Asked Questions
What is next reply time in customer support
It is the elapsed time from the oldest unanswered customer message after the first response to the next useful public reply from the team.
Should several customer messages create several waits
No. Consecutive customer messages before a team reply should normally form one interval that begins with the oldest message. This avoids making the wait look shorter because the customer added detail.
Do automated acknowledgements stop next reply time
Only if the automation genuinely answers the follow-up or gives a specific owned update. A generic receipt should not stop the customer-wait clock.
How should unanswered follow ups be reported
Keep them open, show their current age and owner, and include their count alongside answered intervals. Excluding them creates completion bias.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy