Why your Slack SLA should stop at 6 pm

A customer posts a question in your shared channel at 17:40 on a Friday. Your team has gone home. On Monday at 9:05 someone answers it, politely and correctly. The weekly report then says the first response took 63 hours, and the request shows up in red next to the ones your team really did miss.

Nobody did anything wrong. The clock did. An SLA that counts every hour of the week measures how long your team sleeps, not how well it supports customers, and after a few weeks people stop trusting the report.

This post covers how to count SLA time so that it matches the promise you made: business hours, a time zone, holidays and the time a request spends waiting on the customer.

What a 24-hour clock gets wrong

Most B2B support contracts already say "business hours", even when the tracking doesn't. The mismatch shows up in three places.

• Evenings and weekends. A message that arrives after hours looks late before anyone was supposed to see it.
• Holidays. A public holiday turns every request that arrived the day before into a breach.
• Waiting on the customer. If you asked for logs and the customer took two days to send them, a wall clock charges those two days to your team.

The result is a hit rate that is lower than it should be, and an overdue list full of requests nobody could have answered sooner. The requests that really went wrong get lost among them.

Write down the hours you are promising

Start with the promise itself, before any tool. For each tier of customer, write down:

1. The working days, for example Monday to Friday.
2. The hours, for example 9:00 to 18:00.
3. The time zone those hours are in.
4. The first-response target and the resolution target, in those hours.

The time zone is the part teams most often leave out. "Four business hours" means something different to a customer in Sydney and a team in London. Pick the time zone your team works in, say it in the contract or the channel description, and count in it.

If your team covers more than one region, give each region its own hours, and attach each account to the hours of the team that serves it. A single set of hours stretched across three continents ends up wrong for everyone.

Count holidays as closed time

Holidays belong in the SLA as much as weekends do. Add your public holidays a year at a time, and add company days off as they come up.

Two details matter:

• Which country's holidays. Use the holidays of the team doing the work, not the customer's. Your promise is about when your team is working.
• What happens to running requests. If you add a holiday next week, decide whether requests that are already open should get the extra time. The safe rule is that a change applies to due times set after it, so nobody's queue jumps when an admin edits a calendar.

Stop the clock while you wait on the customer

The resolution clock measures how long your team takes to finish the work. Time spent waiting for the customer's reply isn't your team's time.

Pause the resolution clock when your team has replied and the next move is the customer's, and when someone has snoozed a request until a date the customer gave you. Restart it with the time it had left when the customer writes back.

Leave the first-response clock alone. Once it starts, it should only stop when a person on your team replies. Pausing it would hide exactly the delay customers notice most.

Tell customers your hours

A customer who knows your hours is far less likely to chase you on a Saturday. Put your support hours, time zone and response targets somewhere the customer will see them, such as the channel description or a pinned message, and keep it current.

Be careful with automated replies in the customer's channel. An off-hours note helps some customers and annoys others, who see it as bot noise in a space they think of as a direct line to people. If you use one, make it something you turn on per account, not a default for everyone.

Keep a separate route for real emergencies

Business hours shouldn't mean "nothing happens until Monday" for an outage. If your contract promises cover for severe incidents, give customers a separate, named route for them, such as a status page or an on-call address, and keep it out of the normal SLA. Mixing the two makes the everyday numbers meaningless and still leaves the emergency to whoever happens to be looking at Slack.

Check the numbers against the calendar

Once the clock counts business hours, the weekly numbers start to mean something. 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. When a request is on that list, it should be because someone missed it, not because it arrived on a Friday evening.

For more on targets per tier and alerts before a breach, see how to keep an SLA in Slack channels.

How Thorpe handles it

Thorpe counts both SLA clocks in business hours, in the time zone of the policy.

• Policies per tier. Each SLA policy holds a first-response target in minutes and a resolution target in business hours, plus the hours they count against. Every workspace has a Default policy with Monday to Friday, 9:00 to 18:00, in the time zone of the browser used for setup. You can add a policy for each account tier, and give one channel its own policy with an override.
• Holidays. Add single dates, or add the public holidays for the US, the UK, India, Germany, Australia or Canada. Clocks don't run on a holiday. A new holiday applies to due times set after you save it.
• Pauses. The resolution clock pauses while a request is waiting on the customer or snoozed, and resumes with the time it had left. If a customer channel is disconnected, the resolution clock pauses until it is shared again.
• First response. The first-response clock starts at the customer's message and stops at your team's first reply in the thread.
• Alerts. At 75% and 100% of each target, Thorpe posts in your triage channel and sends the owner a DM. Each alert is sent once per request.
• Requests keep their policy. A request keeps the policy it opened with, so editing a policy changes new requests only.

With hours of 9:00 to 18:00 on weekdays, a one-hour first-response target on a request asked at 17:30 on a Friday is due at 9:30 on Monday.

Thorpe posts nothing in the customer's channel about your hours today. An off-hours acknowledgement and an SLA bookmark for customer channels are coming, and each will be off until an admin turns it on. The SLAs and business hours guide covers every setting.