Most email SLAs fail on the clock, not on the numbers. Email arrives at odd hours, customers reply days later, and helpdesks disagree about what counts as an answer. The rules below are the ones to settle before a number goes into a contract.
Where the email clock starts
Start the clock at the Receipt Time, the moment your mail server accepts the message, not when an agent opens it. If your helpdesk stamps the ticket an hour after the mail lands, that hour disappears from the report and the customer still waited. Measure from your mail logs, not from the ticket.
Threads need a rule too. A reply from the customer on an open ticket belongs to that ticket and does not start a new first response clock. A message from the same sender with a new subject and no reference number is a new Request. Write that rule once and apply it to every mailbox.
Which events pause the clock
Pause only when the next move belongs to someone other than your team. Three events qualify: you asked the customer for specific information in writing (logs, an export file, a yes or no decision), the customer asked in writing to hold the Request until a stated date, or you are waiting on a third party that the contract names.
These never pause it: an autoreply, an internal note, a snooze you set for your own convenience, or a reply that says “looking into it” with no next step.
Tools differ, so write the rule per target. In Zendesk, the Requester Wait Time target is paused by a pending status. Total resolution time keeps running through pending and stops only at Solved, so one status pauses one metric and leaves the other running.
When you pause, say what you need and that the clock has stopped:
“We need the export file from your admin console to continue. We’ve paused the clock on this request until we hear from you.”
Every pause needs a cap, or a request waiting on a customer stays paused forever. Send one reminder after 3 Business Days without a reply, and close the Request if nothing arrives within 5 Business Days after the reminder. A reminder can read: “We’re still waiting for the export file. If we don’t hear from you by [day and time], we’ll close this request. You can reopen it within 5 business days.”
Worked example. A P2 Request arrives on Tuesday at 10:00. The first reply at 10:30 asks for logs, so the clock pauses after 30 minutes. The P2 resolution target is 5 business days, which is 40 business hours on a 09:00 to 17:00 window. The logs arrive on Thursday at 09:00. The remaining 39.5 business hours run from Thursday 09:00 and finish at 16:30 on the Wednesday of the following week. The Request was open for eight days, and the clock ran for exactly 40 business hours.
The working calendar
Set the calendar before writing any number. It has four parts: a time zone, open hours for each weekday, a list of closed dates such as public holidays and shutdowns, and the coverage for each priority.
The time zone matters for P2. If Business Hours follow your own time zone, a customer on the far side of the world waits through their night for every P2 reply. Count P1 in calendar hours if you can staff for it, and let the on-call rota carry the coverage.
The setting lives in a different menu in each helpdesk, so find yours before you write the contract. In Zendesk, the Hours of operation setting is picked per priority, as calendar hours or business hours. In Freshdesk, accounts on the Growth, Pro and Enterprise plans that signed up after December 2025 pick the calculation under operational hours, and the two options are the business hours you set or “Calendar hours (24*7)”. Zendesk’s documentation also says a business-hour target can carry over to the following business day. Its example is a Friday afternoon ticket with an eight-business-hour target that lands on Monday morning.
After-hours rule. For a target counted in Business Hours, a Receipt Time outside the window starts the clock at the next opening time. Take a P2 first response target of 8 business hours, a 09:00 to 17:00 window from Monday to Friday, and an email received at 17:40 on Friday. The clock starts at 09:00 on Monday, and the first response is due at 17:00 on Monday.
Decision rule. If you promise P1 response around the clock, count P1 in calendar hours and staff nights and weekends. If you cannot staff nights, say so in the contract and count P1 in business hours. Do not promise a 2-hour target your rota cannot keep.
Failure mode. A public holiday is missing from the calendar. The calendar is the only input the clock uses, so the clock runs through a day the team is off. A Friday email at 15:00 with an 8-business-hour target has 6 hours left at 09:00 on Monday, and it is due at 15:00 on Monday when nobody is in. Fix it by loading the closed dates before the year starts.
Targets by priority
This tiered table is a starting point, and the values are examples to adapt. They are not an industry benchmark.
| Priority | Example trigger | First response | Resolution | Clock |
|---|---|---|---|---|
| P1 | Production is down, or the customer cannot send or receive mail | 2 hours, then an update every 2 hours | 8 hours | Calendar hours, covered by an on-call rota |
| P2 | A feature is broken and a workaround exists | 1 Business Day (8 Business Hours) | 5 Business Days | Business Hours |
| P3 | Question, configuration help, feature request | 2 Business Days | None in the SLA | Business Hours |
Define a Business Day in the contract. With a 09:00 to 17:00 window, it is eight Business Hours. Let the customer choose the Priority from the trigger column when the Request opens, and let your team change it with a written reason. When the Priority changes, the time already run carries over to the new target.
First response, resolution and reopening
Two terms cause most disputes.
First response is the first message from a named person on your team that answers the Request or asks a specific question. It is not an autoreply, a “we’ve got this” from a shared inbox, or a bot message unless the contract says bots count. Make the autoreply say what it is, for example: “Thanks for writing in. This is an automatic reply. Your request is ticket #[number], and a member of the support team will reply by [day, time and time zone].”
Resolution needs one trigger. Pick one: the customer confirms in writing that the issue is solved, or your team sends a message stating the fix and closes the Request. A closing message with no fix is not a resolution, and that gap is a common source of disputed times.
Reopening needs a rule too. Otherwise a reply on a ticket closed last month either disappears into an old thread or is measured against a target that was already met. The clause below reopens the same Request within 5 Business Days of closure and restarts the resolution clock at the reply’s Receipt Time. A later reply opens a new Request. If your AI agent drafts replies, record its messages separately from human first responses, and say in the contract which kind counts.
How email differs from a Slack Connect SLA
Email changes three things from a Slack Connect SLA. The start is the Receipt Time in your mailbox, not a message posted in a shared channel. Threads are matched by reference number or the reply thread, not by a Slack thread. And one customer can write from several addresses, so the contract should say whether a Request is identified by sender, by domain or by reference number.
Slack’s own Slack Connect help article requires a paid plan on both sides before organizations can share channels, and it says nothing about response times or service levels. Every Slack target is therefore one your team has to define.
Decision rule. If the same customer writes twice within one business day about the same issue from different addresses, with no reference number, open a second ticket and merge only after an agent confirms it is the same request. Merging on the sender’s domain alone gives one customer’s unrelated second request the first response clock of the first.
A clause to adapt
This is a commercial template for support terms, not legal advice. Have counsel review it before you sign. Square brackets mark values from your order form.
Definitions. “Business Hours” means 09:00 to 17:00 Central European Time, Monday to Friday, excluding public holidays listed in Schedule A. “Business Day” means eight Business Hours. “Receipt Time” means the time a message sent by Customer to Provider’s support address reaches Provider’s mail server. “Request” means one issue, identified by its reference number. “Priority” means P1, P2 or P3, set under Schedule B. “First Response” means the first message from a named Provider support representative that answers the Request or asks Customer a specific question, and it excludes automatic replies. “Resolution” occurs when Customer confirms in writing that the Request is solved, or when Provider sends a message stating the fix and closing the Request, whichever comes first.
Targets. For a P1 Request, Provider will send a First Response within 2 hours of Receipt Time, counted in calendar hours, and an update at least every 2 hours until Resolution. For a P2 Request, Provider will send a First Response within one Business Day and achieve Resolution within 5 Business Days, counted in Business Hours.
Pause. The clock pauses from the time Provider asks Customer in writing for specific information until Customer replies, and while Customer has asked in writing to hold the Request until a stated date. The clock also pauses while Provider waits for a third party named in Schedule C. An automatic reply does not pause or stop the clock. If Customer does not reply within 3 Business Days of a request, Provider will send one reminder. If Customer does not reply within 5 Business Days after the reminder, Provider may close the Request without Resolution, and the clock stops at the closing message.
After hours. For a target counted in Business Hours, a Receipt Time outside Business Hours starts the clock at the next opening of Business Hours. Targets counted in calendar hours run continuously.
Reopening and Priority. Customer may reply within 5 Business Days after closure to reopen the same Request, and the Resolution clock restarts at the Receipt Time of that reply. A later reply opens a new Request. Customer sets the Priority when it opens a Request. Provider may change it with a written reason, and time already run carries over to the new target.
Remedies and exclusions. If Provider misses a P1 First Response target, Customer may claim the service credit set out in the Order Form, [credit amount]. Scheduled maintenance announced at least [notice period] in advance, and events beyond Provider’s reasonable control, do not count as missed targets.
Reporting. Each calendar month, Provider will report, by Priority, the share of Requests with a First Response within target and the 90th percentile of First Response times.