A slow first response time usually hides one long wait. Find that wait before you change how anyone writes replies, because a faster reply cannot recover time spent waiting for an owner.
Split the wait into four segments
Each request gets four timestamps. Every segment starts where the previous one ends, so the four durations add up to the total for that request:
- Capture: from the customer’s message timestamp (the
tsvalue, covered below) to the moment the request appears in your inbox or tracker. Any delay in your integration sits here. - Assignment: from capture to a named owner.
- First open: from assignment to the owner opening the thread.
- Reply: from first open to the first human reply that addresses the request.
Your tool may not record the two middle stamps. Add them before you change anything. Without them you can measure the total but not the part causing it.
Decision rule: take the median of each segment over the last 30 days, for requests that arrived in business hours. Fix the segment with the largest median first. If that segment is capture, the problem is intake, not staffing.
Worked example, with illustrative numbers: 180 requests in 30 days, a 60-minute business-hours target, and segment medians of 3, 38, 6 and 19 minutes. The four medians add to 66 minutes, but medians do not add, so read the total median from the same 180 requests to see whether you are above the 60-minute target. Assignment, at 38 minutes, is the largest segment median, so routing comes before any change to reply speed.
Four actions, matched to the segment they fix
Capture every message (capture segment). If the capture median is more than a few minutes, people are seeing messages late. The trap is the keyword trigger. Slack’s Workflow Builder help article says a workflow using the “When a message is posted” trigger “will start when a message is posted that contains keywords that you specify”. A keyword-only setup therefore never starts on the rest of the channel. Use a source that reads every message. To check it, pull ten customer messages from last week and compare each one’s Slack timestamp with the time it first appeared in your queue. If any arrived more than a few minutes late, the capture segment is broken, and no reply-speed work will fix it.
Name an owner and a backup per shift (assignment segment). Rule: if the assignment median is above 10 minutes in business hours, give each shift one named owner and one named backup. The 10-minute threshold is a planning assumption, not a benchmark, so check it against your own data.
If assignment stays above the threshold two weeks after you name owners, check two things before you hire. First, whether the owner receives Slack notifications at all during their hours (default Do Not Disturb hours can suppress them, as covered below). Second, how many open threads each owner holds. Slow pickup can come from either. Muted notifications are a configuration fix. A heavy open-thread load per owner is a workload problem, so check it before you decide whether you need more people.
Acknowledge with a commitment (when the reply is far off). When a real answer will take longer than the target, a short message in the thread helps the customer plan. For example: “Thanks for flagging this. Dana is picking it up and will reply here by 3:30 pm Eastern.” Only promise a time you will meet. Under the definition in “What not to do”, a message that only names an owner and gives a time is a holding message, so this message does not stop the clock.
Cut the reply segment with a snippet library. Pull the last 30 days of requests and tag them by question type. Write one snippet for each question type that came up at least 10 times, and link the doc it depends on. Reply time falls when people stop writing the same answer from scratch.
Judge each action on its own segment median, not on the total. Give a fix two weeks. If the segment has not moved by then, check the timestamps before you change the fix, because a segment that does not move is often a measurement gap.
Escalate before the deadline
Escalation needs a trigger that fires before the breach. Rule: at 45 minutes into a 60-minute target with no first reply, post to the named backup in an internal channel, not the shared channel. The 45-minute point is also a planning number. Name the person, not the team. At the deadline, log the breach and the segment where most of the time went. A breach log that says only “late” teaches nothing.
What not to do
- Do not count automatic acknowledgements as first responses unless the SLA says they count. A definition that works: “First response is the first reply from a person on our team that addresses your request. Automatic acknowledgements, emoji reactions, and holding messages that only give a time or name an owner do not count.”
- Do not send a bot “we got it” to every message. The customer reads it as a person on the way, and no one may be.
- Do not rely on a keyword trigger as your only capture. See action 1.
- Do not lower the average by answering easy questions first while hard ones wait. Report the 90th percentile next to the average, because the average hides the slow outliers.
- Do not set the first target from what you wish. Set it so your current 90th percentile for that customer tier already meets it, and tighten only after two periods in a row under it.
Where the clock starts in Slack Connect
Start the clock at the customer message’s own timestamp. Slack’s message event reference describes the ts field as “the unique (per-channel) timestamp”, so use that value. Do not start from when your integration processed the event. A three-minute ingestion delay then shows up in the capture segment, where you can see it, instead of quietly shrinking your team’s target.
Follow-ups need written rules:
- A new top-level message from the customer is a new request, unless it refers to an open one, such as “same issue” or “following up on this”. Then it joins that request.
- A message in an open thread, sent before you reply, stays on the first unanswered message’s clock.
- A message in a thread after your reply is a follow-up. It starts a new clock only if the SLA says a new question restarts it.
Decide whether waiting on the customer pauses the clock. This is the most common argument in shared channels. If it pauses, stop the clock at your question’s timestamp, restart it at the customer’s next message in that thread, and record the pause as its own field. If it does not pause, say so in the SLA, because the clock keeps running on requests you cannot answer yet.
Count a reply only when its sender is someone on your team. The message event reference describes the user property as “the ID of the user”, so keep an allowlist of your team’s user IDs. Exclude posts with the bot_message subtype, described as “A message was posted by an integration”, so your own automation stays out of the metric.
Nights, weekends and holidays
Pick one clock per SLA and state it.
- Business-hours clock. The clock pauses outside hours. A Saturday 10:00 am message with a two-hour target and hours of 9 am to 6 pm, Monday to Friday, starts at Monday 9:00 am and is due at 11:00 am Monday.
- 24/7 clock. You need on-call coverage that can see the alert. Slack’s help center says Workspace Owners/Admins and Org Owners/Admins can set default Do Not Disturb hours, and that the feature is “Available on all plans”. During those hours, “Slack will not send any desktop or mobile notifications to members during those hours”. Members can still change their own hours, so check each on-call person’s personal schedule as well. Slack’s work-hours article uses the example of 9 a.m. to 5 p.m. working hours with a daily Do Not Disturb schedule from 5:01 p.m. to 8:59 a.m. An on-call rota that falls inside that window needs an override.
Name one time zone for the business-hours calendar in the SLA. For customers in other regions, either keep the support team’s zone and say so, or define one calendar per region. Load public holidays into the calendar before you publish the SLA. A holiday missing from the calendar becomes a breach nobody staffed.
For a business-hours SLA, a holding reply tells a weekend sender when to expect an answer. Keep it accurate: “We received your message on Saturday. Our team is back Monday at 9:00 am Eastern, and someone will reply here by 11:00 am.” Under the definition in “What not to do”, it still does not count as the first response, because it only gives a time.
For a Monday morning sweep, Workflow Builder’s “On a schedule” trigger lets you “Specify a date, time, and cadence for your workflow”. Point it at an internal channel your team reads, not a Slack Connect channel, and post the list of everything open since Friday evening at 8:45 am. A step that posts to a channel needs posting permissions for that channel, so test it in the channel you pick.
Report it, then re-check
Report attainment (the share of requests answered within target) and the 90th percentile per customer tier, plus the four segment medians. The segment medians tell you what to fix next. For the definitions behind those numbers, see how to measure first response time in Slack Connect. For deadlines under a business-hours SLA, the first response time calculator works them out for any hours and days.