Service-based versus tier-based
| Service-based | Tier-based | |
|---|---|---|
| Clock comes from | The request type | The account’s plan |
| Best when | A late answer costs the same whoever asks | The contract sells named capacity |
Choose service-based unless the contract sells capacity a request type cannot express, such as a named engineer on a fixed rota. If you sell both, request type sets the default and a tier can only tighten first response. Zendesk’s article advises ordering policies with the most restrictive at the top; that is about policy order inside the tool, so treat putting the stricter clock first in the contract as our suggestion.
Deriving targets. Pull 90 days of tickets per type and set each target near the 90th percentile of what you already achieve. Then check load: 40 billing tickets a week at 20 minutes each is about 13 hours of work, so a 4 business hour first response needs someone looking at the queue at least every 2 hours.
Sample targets and clock rules
| Request type | First response | Resolution |
|---|---|---|
| Production outage | 1 hour, 24/7 | 8 hours, fix or workaround |
| Billing question | 4 business hours | 2 business days |
| Non-blocking bug | 8 business hours | 10 business days |
Illustrative, not benchmarks. Business hours run Monday to Friday, 9:00 to 17:00 in the zone the contract names, with that zone’s holiday calendar. Outage clocks ignore it: a Saturday message is due within 1 hour. Named accounts get 2 business hours on billing and non-blocking bugs.
The clock starts when the customer’s message lands in the thread. Example: a named account’s bug raised at 16:00 Friday is due 10:00 Monday, since one business hour runs Friday and one runs Monday.
Classification. Classify by impact: “is a customer-facing function down or blocked for users?” means outage. Keep six types or fewer. The type locks at first reply. Only the support lead may change it afterwards, with a logged reason, and the new clock counts from the original message time, so a downgrade cannot hide a breach.
Waiting on customer. First response never pauses. Resolution pauses after a public question to the customer and resumes at their reply. Zendesk’s article counts Pending time toward total resolution time, so write your own pause rule.
AI replies (our rule). A substantive answer contains the specific thing asked: a setting name, a price, a date or a fix. It counts as first response; “Thanks, we are looking into it” does not. If the customer answers “that did not help”, a human clock starts at half the original target. Example: the bot answers a billing question at 10:05, the customer objects at 11:00, and a person must reply by 13:00.
Resolution. Resolved means the customer confirms, or stays silent for 3 business days after the fix (our default). A workaround stops the outage clock and opens a bug ticket.
Internal discussion. Keep it out of the Connect channel. Use a private internal channel or the ticket’s internal notes, linking the thread, and post only the customer-facing line.
Breaches. Reassignment keeps the due time. When three quarters of the target has elapsed (our threshold), the owner gets a reminder with the thread link. On a miss, the lead is notified and someone posts within 30 minutes: “We have missed our first-response target on this. Next update by 15:00.” The contract should name, per request type, which miss triggers a remedy and what it is; the amount is a commercial choice.
Shared channels. One thread, one request type; mixed threads take the strictest. Slack’s Connect guide says only the owning organization can invite or remove organizations, and that each organization needs a paid Slack plan. It shows no update date, so confirm both sides first.