How to keep an SLA in Slack channels

Your contract with a customer says something like "first response within four business hours". In email or a help desk, a clock starts when the ticket arrives and everyone can see it. In a shared Slack channel, there is no clock. There is a message, a few people who might have seen it, and a promise in a contract that nobody on the team has open.

This post covers how to run an SLA in Slack channels: what to measure, how to count time fairly, and how to find out a request is at risk while you can still do something about it.

What the SLA actually measures

Most support SLAs come down to two clocks.

• First response: the time from the customer's message to the first reply from someone on your team.
• Resolution: the time from the customer's message until the request is done.

In Slack, both need a precise definition, because the edges are blurry.

The clock should start on a new top-level message from someone on the customer's side. A reply in an existing thread belongs to the request that thread already is.

A first response should be a reply in the thread from a person on your team. An emoji is not a reply. Neither is an automated message from a bot, even a helpful one, because the customer still hasn't heard from anyone.

The resolution clock should pause while you're waiting on the customer. If you asked for logs and they take two days to send them, those two days are theirs, not yours.

Set targets per tier, not one number

A single target for every customer is either too strict for small accounts or too loose for the large ones. Most teams end up with two or three tiers, each with its own first-response and resolution targets.

Tie each shared channel to an account and each account to a tier. Then a request's target follows from where it came from, and nobody has to remember which customer gets what.

Decide what happens when you change a target. The fair rule is that a new target applies to new requests only. A request that is already running keeps the target it started with, so a change on Tuesday doesn't turn ten open requests red at once.

Count business hours, in a time zone, with holidays

An SLA counted in wall-clock hours punishes your team for sleeping. Count business minutes instead: your working hours, in the time zone the policy states.

Holidays matter more than people expect. Without them, a message posted on a public holiday is overdue by the next morning, before anyone was supposed to be at work. Add your public holidays to each policy a year at a time, and add company days off as they come up.

If your team covers several regions, give each region its own hours, and attach the right policy to the accounts that region serves.

Warn before the breach, not after

An alert that fires when the target has already passed tells you what went wrong. An alert that fires before it gives you time to fix it.

A good pattern is two alerts per clock:

1. At 75% of the target, a warning to the owner and to a channel the team watches.
2. At 100%, an overdue alert to the same places.

Send the alert to the owner by DM, so it reaches the person who can act, and to a shared triage channel, so someone else can step in if the owner is out. If the request has no owner, say so in the alert.

Then make alerts stop the moment the state changes. An alert for a request that someone just answered teaches people to ignore alerts.

Tell customers what to expect

Many teams write their response times into the channel topic or a pinned message, because customers otherwise treat a shared channel as a hotline that is staffed around the clock. It's a reasonable fix. A customer who knows your hours and targets is much less likely to chase you at night.

Keep anything you show customers short and accurate: your hours, your time zone and the response time for their tier. Update it when the targets change, or it becomes one more thing that's wrong.

Be careful about automated replies in the customer's channel. Some customers find an off-hours note useful. Others see it as bot noise. Make it something you turn on per account, not a default for everyone.

Look at the numbers every week

Each week, look at the share of requests that got a first response inside the target, the median first response, and the list of requests that went over. Compare with the week before. One bad week is noise. Three in a row on the same account is a conversation to have.

How Thorpe handles it

Thorpe runs both clocks for every request in your customer channels, using the definitions above.

• You set first-response and resolution targets per account tier, with working hours, a time zone and holidays. A one-click option adds public holidays for the US, the UK, India, Germany, Australia and Canada.
• A request keeps the policy it opened under. Edits apply to new requests only.
• Only a teammate's reply counts as a first response. Bot messages never do.
• The resolution clock pauses while the request is waiting on the customer or snoozed.
• At 75% and 100% of each target, Thorpe posts in your triage channel and sends the owner a DM. If the owner is away, the triage alert says so. Alerts stop once the request moves on.
• Each owner gets a morning DM listing their open requests, sorted by when they're due. A weekly digest in your triage channel shows the first-response hit rate against the week before, the median first response and the requests that went over.

Two customer-facing pieces are coming, and both will be off unless you turn them on for a tier: an off-hours note that tells the customer when your team is back, and a channel bookmark that links to a page with your support hours and response times.

Setting up policies is part of the getting started guide.