First Response Time

A customer writes at 10:00 and a support agent replies at 10:25, so under a calendar-time measure with those events, first response time is 25 minutes, although a receipt acknowledgement might not count as a qualifying reply. Zendesk defines its first reply time from ticket creation to the first public agent comment and offers calendar-hour and business-hour values, and its live chat and messaging cases can have special rules, so the metric configuration matters.

Intercom's reporting guidance explains office-hours treatment, where a business-hours measure pauses outside defined working hours whereas a calendar clock continues, and neither is inherently the right customer-experience measure for every operation. Choose the start event, because a web form submission, email received and ticket created may have different timestamps, and importing tickets late can hide the customer's real wait if creation time is used.

Choose the stopping event, since an automated acknowledgement may reassure a customer but should not be mixed with a human substantive response without labelling the measure, and some systems distinguish bot replies and agent replies. State the unit, with minutes or hours common, and convert consistently across channels and time zones, because daylight saving can also complicate naive clock subtraction.

For a group of tickets, an illustrative average is the sum of individual first-response durations divided by the number of eligible tickets, so durations of 10, 20 and 90 minutes average 40 minutes. The average hides the long wait, as the same set has a median of 20 minutes, so report a percentile or distribution if a small number of customers wait far longer.

Separate working and nonworking hours, because a Friday-night email to a weekday support desk will look very different on calendar and business-hour clocks, and show coverage hours to the customer. Segment by priority, since an urgent payment outage and a general feature question may have different targets and critical failures should not be buried in a strong overall average.

Segment by channel, because live chat is usually expected to be faster than email and a combined number may shift simply because more customers chose one channel. Track unresponded cases, since a report that only averages tickets that received a reply makes unanswered tickets disappear, so pair the timing with a count of open, unresponded contacts.

Clarify reopened tickets, as a new customer message in an old thread might be measured as a later response, not a new first response, and keep internal notes separate because a private agent note is progress for a team but may not answer the customer. Examine queue causes, since high response time may come from staffing, routing, duplicate tickets or unclear ownership, and faster typing alone will not fix a ticket sitting in the wrong queue.

Avoid empty replies to stop the clock, because a quick generic "we are looking" may be useful when truthful, but gaming a target with a non-answer makes the metric less helpful. Set service-level targets carefully, since a promise of an initial reply within two hours is not a promise to resolve within two hours, and customers should be told which outcome is covered.

Use time zones and holidays in schedules, because a business-hours clock must reflect real availability and a configuration that lists the office as open during a holiday can distort results. Review outliers by checking timestamps and actual customer experience before deciding a long wait is a data error, since it may reflect a lost integration or exceptional case, and for owners first response time is a starting signal about access to help that should be read with unresolved volume, quality and resolution measures before judging service.