Metric · Support

What is first-response time, and how do you measure it in Metabase?

First-response time (FRT) is how long a customer waits from opening a ticket to the first human reply. It's the clearest early signal of responsiveness, and it moves CSAT more than almost any other support metric. Measure it in Metabase from help desk data synced into a database (Zendesk, Intercom, Front, or Freshdesk).

TL;DR — Report the median (and p90), not the average — response times are heavily right-skewed. Count the first human reply, not an autoresponder, and decide upfront whether to measure against calendar time or business hours.

How is first-response time calculated?

For each ticket, FRT = timestamp of the first agent reply − ticket created timestamp. Then aggregate across tickets with a percentile, not a mean:

  • Median FRT — the typical wait; half of customers waited less, half more.
  • p90 FRT — the tail; what your slowest 10% of customers experience.

If you promise response SLAs in business hours, subtract nights, weekends, and holidays from the elapsed time before you aggregate — otherwise a ticket opened Friday evening looks like a failure on Monday.

What data does first-response time need?

  • A tickets/conversations table with a created_at timestamp.
  • The first agent reply timestamp — either stored on the ticket, or derived from a messages table (first non-automated agent message).
  • An author type or role so you can exclude bots, autoresponders, and the requester's own follow-ups.
  • Optionally, a business-hours calendar or SLA policy for business-time FRT.

SQL patterns

Median and p90 first-response time by weekPostgreSQL

Percentiles over the response gap, aggregated weekly.

-- Median first-response time in hours, by week.
-- Assumes a modeled tickets table with the first human reply timestamp.
SELECT
  date_trunc('week', t.created_at)                       AS week,
  PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (t.first_response_at - t.created_at)) / 3600.0
  )                                                       AS median_frt_hours,
  PERCENTILE_CONT(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (t.first_response_at - t.created_at)) / 3600.0
  )                                                       AS p90_frt_hours
FROM tickets t
WHERE t.first_response_at IS NOT NULL
GROUP BY date_trunc('week', t.created_at)
ORDER BY week;
Derive first response from a messages tablePostgreSQL

When the first reply isn't stored on the ticket, take the earliest human agent message.

-- Derive first response from a messages table when it isn't
-- stored on the ticket. First non-automated agent message wins.
WITH first_reply AS (
  SELECT
    m.ticket_id,
    MIN(m.created_at) AS first_response_at
  FROM messages m
  WHERE m.author_type = 'agent'
    AND m.is_automated = false
  GROUP BY m.ticket_id
)
SELECT
  t.id,
  t.created_at,
  fr.first_response_at,
  EXTRACT(EPOCH FROM (fr.first_response_at - t.created_at)) / 3600.0 AS frt_hours
FROM tickets t
JOIN first_reply fr ON fr.ticket_id = t.id;

Pitfalls

Reporting the average instead of the median.→ Response times are right-skewed; a few slow tickets drag the mean far above the typical experience.
Counting autoresponders as the first response.→ Define first response as the first human (or first meaningful) reply, or the metric always looks instant.
Mixing calendar time and business hours.→ Pick one and label it. Business-hours FRT needs a calendar to subtract nights and weekends.
Including internal notes as replies.→ Only customer-visible messages count toward first response.

Where this metric applies

Analytics

Metrics

FAQ

What's a good first-response time?
It depends on channel and promise: live chat expectations are minutes, email is hours. Track your own median against the SLA you've committed to rather than a universal benchmark, and watch p90 so the tail doesn't hide behind a healthy median.
Should I measure in business hours or calendar hours?
Measure against whatever you promised customers. If your SLA is stated in business hours, subtract nights, weekends, and holidays; if you offer 24/7 support, calendar time is fine. Just be consistent and label the chart.
How is first-response time different from resolution time?
First-response time is the wait for the first reply; resolution time is the wait until the ticket is fully solved. Fast first response with slow resolution usually means tickets are acknowledged but then stall.