A customer service metrics dashboard is only as honest as its definitions. Most bad numbers come from the same three places: the clock starts in the wrong place, the hours don’t match the promise, or a grouping hides a spike. Five cards cover what a support lead needs: first response time, resolution time, backlog, reopen rate and CSAT. This guide gives the field behind each card, the Slack and email details that change the calculation, and the slices that mislead. The business-hours arithmetic lives in the first response time calculator, so this page refers to it rather than repeating it.
The five cards and their fields
| Card | Field definition | Data source |
|---|---|---|
| First response time | Minutes from request start to the first human reply that addresses it. Store both timestamps. | Slack: parent message ts and first reply in the thread. Email: inbound received time and first outbound reply. |
| Resolution time | Minutes from request start to the moment the request is set to resolved. A reopened request keeps its original start. | Status change events in your inbox, not replies. |
| Backlog | Count of requests not yet resolved at a snapshot time, split into age buckets: under 4 hours, 4 to 24 hours, over 24 hours. | Status at the snapshot time. |
| Reopen rate | Requests that return to open within 7 days of resolution, divided by requests resolved in the period. | Status history. |
| CSAT | Share of survey responses in the top two points of your scale, with the response count beside it. | Survey responses. |
The 7-day reopen window and the age buckets are starting choices, not industry standards. Pick them once and write them on the dashboard so nobody changes them mid-quarter.
Slack Connect: where each timestamp comes from
Every Slack message carries a ts field. The message event reference describes it as unique per channel, and its example value, 1355517523.000005, has a whole-seconds part and a six-digit fraction. Store the raw string as the key and convert to your timezone at read time. Two requests can land in the same second, and a rounded key merges them.
Request start is the ts of the customer’s top-level message. First reply is the earliest message in that thread from someone on your team that addresses the request. Before you take the minimum, exclude:
- Emoji reactions, which are not messages in the thread.
- Subtype events. The message event reference says messages can carry a subtype and gives
channel_joinas an example, and a join is not a reply. - Bot acknowledgements, unless your SLA explicitly counts them.
Fetching is where Slack dashboards go wrong. The conversations.history reference directs readers to conversations.replies to retrieve a message from a thread, so a poller that reads only channel history sees the parent messages and misses the replies. As of 2026-11-11 the docs list both conversations.history and conversations.replies as Tier 3, at 50+ per minute. Treat that as a snapshot, not a guarantee: Slack has changed limits for these methods for some app types, such as distributed apps outside the Marketplace, so check the current limit for conversations.replies and for your own app type before you size a poller. Keep a list of open threads, re-fetch only those instead of the whole channel, and set the schedule from the limit you confirmed.
Email threads link through headers
Subjects are a poor key. Customers rename threads, and forwards start new ones. Use headers instead. RFC 5322 Section 3.6.4 defines the In-Reply-To and References fields, and says the References field may be used to identify a thread of conversation. Store each inbound Message-ID and then:
- Request start is the received time of the first inbound message in the chain.
- First reply is the first outbound message whose
In-Reply-Topoints at an inboundMessage-ID. - Auto-replies and out-of-office messages are excluded from both sides.
Whatever tool holds the threads, the counting rules above decide what counts as a reply.
Business hours or calendar time
Store both elapsed values on every request. Calendar elapsed is what the customer waited. Business elapsed is whether the team met the promise. Show the one your SLA names on the attainment card, and keep the other in the drill-down.
Worked example. Assume a Monday to Friday schedule of 09:00 to 18:00 in one time zone. A customer message arrives Friday at 16:30 and the first reply is Monday at 10:00. Calendar elapsed is 65.5 hours, or 3,930 minutes. Business elapsed is 150 minutes: 90 on Friday from 16:30 to 18:00, and 60 on Monday from 09:00 to 10:00. Against a one-hour target, the calendar breach is 64.5 hours and the business breach is 90 minutes. Both numbers are arithmetically correct. Only one of them matches the promise.
The decision rule: if the SLA says business hours, attainment uses business elapsed. If it says “within X hours” with no qualifier, attainment uses calendar elapsed, and weekends will show up as breaches. Do not switch between the two on one chart.
Group by creation time or by reply time
Two groupings answer different questions. Group by created time, as a cohort, for attainment: of the requests that arrived this week, how many were answered in target? Group by first-reply time for throughput: how much did the team answer this week? Both are legitimate. Putting them on one card is the common error.
Worked example. 40 requests arrive on Friday afternoon, and all of them get a first reply on Monday morning. In the cohort view, Friday’s attainment is poor and stays poor however fast Monday goes. In the reply-date view, Friday shows 0 replies and Monday shows 40, so Friday looks idle and Monday looks like the busy day.
The decision rule: if the card answers “did we meet target”, group by created time. If it answers “how much did we answer”, group by reply time. Put the grouping in each card’s title.
Three traps that make the numbers mislead
Weekend backlog looks high. A backlog snapshot at Monday 09:00 includes everything that arrived since Friday’s close. It looks like a crisis and is mostly the weekend. Take two snapshots, one at close and one at the start of business hours, and report the age buckets next to the count. If the count is high but the over-24-hour bucket is near its Friday level, the problem is Monday staffing, not a growing backlog.
The holiday drop. The holiday itself records zero requests and zero replies, and those are not real zeros. The day after usually shows a catch-up surge, and replies to requests that waited over the closure make reply-date averages look slower. Mark the holiday as closed in your calendar, leave it out of daily averages, and show the day-after cohort on its own. Exclude closed days from business-elapsed calculations too, or every request that spans the holiday will look slower than it was.
One large account. Suppose one customer posts 300 requests in a week and the rest of the book posts 90. If the 300 average 9 hours to first reply and the other 90 average 1 hour, the request-weighted mean is (300 × 9 + 90 × 1) ÷ 390 = 7.15 hours. The card says 7.15 hours, which describes neither group. Show first response time and attainment per account next to request counts. Add an “excluding top account” line whenever one account is more than a third of the period’s requests.
What belongs on the front page
Keep the front page to the five cards. Put per-channel, per-account and per-agent cuts behind drill-downs. Do not rank agents on first response time alone. Under most definitions, a reply that only says “looking into it” stops the clock, so a fast reply can be a poor one. Decide whether such replies count, write the rule down, and report them as a separate count if you want visibility into them.
On CSAT, hide the score when the response count is below the floor you wrote down, and say on the card that the score is hidden and why. A number from six answers is a conversation, not a result.
For the timing rules behind the targets, see Slack Connect SLA: first response time and how to improve first response time.