Metrics and terms
There is nobody picking anything up
First response time is one of the oldest numbers in support and it is inseparable from the thing it was invented to watch: a queue with people in it and a backlog that grows. A widget has neither. The metric does not transfer, and this product does not compute one.
not measured here
This product does not compute a first response time. Enquiries taken by the handover form are stored and listed per assistant, but nothing records when a person answered one, so no interval exists to report. The latency figure on the insights page is labelled "Median latency" and hinted "to full answer", which is machine timing rather than a human reply.
What it means
First response time is the interval between a customer making contact and a person replying for the first time. It exists because a queue can grow silently: tickets accumulate, nobody notices until the oldest is four days old, and the interval is the early warning. Everything useful about it depends on there being a waiting period governed by staffing. An automated assistant has no waiting period in that sense. It replies as soon as it has an answer, that interval is a property of the software rather than of anybody's workload, and no amount of staffing changes it. Applying the name to machine timing borrows the authority of an operational metric for something that is not operational at all.
How it is actually calculated
How it is calculated in a queue
The timestamp of the first human reply minus the timestamp of the inbound contact, aggregated across a window, usually as a median with a target attached.
The interesting choices are all about which clock runs. Business hours or wall clock, and whether an automatic acknowledgement counts as a response. That last one matters enormously: counting an automatic reply drives the figure to near zero and empties the metric of meaning, which is exactly what happens when an assistant is added to a channel that reports it.
Why it cannot be computed here
There is no queue and no assignment. When a visitor asks for a person, the assistant offers a form taking a name, an email and a message, and the enquiry is stored and listed for that assistant. That is the whole handover mechanism.
Nothing in this product records when somebody replied to a stored enquiry, because the reply happens in your email rather than here. Without a second timestamp there is no interval to compute, and inventing one from the moment the enquiry was read would measure attention rather than response.
What the latency tile is, and is not
The insights page shows a latency figure, which is machine time from question to finished answer. It is not a first response time. It measures the software, not a team, and it will always be small.
If somebody asks for first response time and you point at that tile, you will be understood as claiming your team replies in milliseconds. That misunderstanding is worth one extra sentence every time.
How the number gets moved without anything improving
How the number collapses without anybody replying sooner
Count the automatic reply as the first response. In a channel where an assistant answers instantly, the reported figure drops to near zero on the day it is installed, and every human wait behind it is unchanged. This is by far the most common distortion of the metric and it usually happens without anybody deciding to do it.
Switch the clock to business hours and a Friday evening enquiry answered on Monday morning becomes a fast response. The customer's experience is identical either way.
Reply with an acknowledgement that answers nothing. The clock stops, the number is excellent, and the actual work starts later. A metric that measures the first reply cannot distinguish a reply from an answer.
What to look at instead, or alongside
- The count of stored enquiries over time, which is the workload the handover actually creates for your team.
- Your own email or helpdesk timings, since the human reply happens there and that is where it can honestly be measured.
- The latency tile read as what it is, machine time to a finished answer, with no human implication attached.
- Whether your out of hours wording promises a reply time you can keep, which is the underlying question this metric usually stands in for.
Questions
- Can I report our latency figure as first response time?
- Only if you are willing to be understood as claiming a human answered that fast. The figures are unrelated: one is software timing on our side, the other is a property of how your team is staffed. Report them separately or report only the one you can defend.
- Will you ever measure the reply to an enquiry?
- It would require knowing when somebody answered the email, which happens in a system this product does not see. Anything computed here would be a measure of when the enquiry was viewed, which is a different thing wearing the same label.
- Does the assistant answering instantly help our first response time at all?
- It probably reduces the number of enquiries that reach your queue, which improves the queue's figures by reducing its volume. That is a real effect and it is worth measuring in the queue rather than here, where the causal half of it is visible as the unanswered list.
Keep reading
- Conversation volume: what a conversation count can tell youHow many people opened the widget and said something. A useful denominator, a poor headline, and a number that moves with your marketing.
- Containment rate: why this product does not compute oneContainment counts conversations that ended without a person. A widget cannot see whether one did, so no containment figure exists here.
- Escalation rate: what a handover is here, and why it is not a rateHandover enquiries are stored and listed. No rate is computed against them, and dividing by conversations by hand needs three caveats.
- Every metric and termWhat each one means, and which of them this product actually computes.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.