Email SLAs: how to set response targets your team can actually hit

The customer wrote at 17:50 on Friday. Somebody replied at 08:40 on Monday. The website promised an answer "within 24 hours," and both sides walked away from that thread convinced they were right, because nobody had ever written down whether those 24 hours were supposed to tick over the weekend.

That's the argument almost every email SLA eventually produces, and it isn't caused by a target that's too ambitious. It's caused by a target with no rules under it. "24 hours" isn't a commitment yet. It's a number waiting for six other decisions: which messages it covers, when the clock starts, when it stops, whose calendar it runs on, what happens when the customer replies again, and what you do on the day you miss it.

If you landed here looking for the uptime clause in an email provider's contract, that's a different document. This one is about the promise you make to the people who write to your support address.

What an email SLA actually is

An email SLA is a written commitment about how quickly your team replies to inbound email: to which messages, measured on a clock you've defined, over a scope you've named. It's measured on elapsed time between two events you can point at in the mailbox, not on how busy the week felt. What separates it from an internal goal is that somebody outside your team has been told about it and can hold you to it.

The standards world says the same thing in drier language. NIST's glossary, quoting SP 800-47 Rev. 1, describes a service level agreement as something that "[r]epresents a commitment between a service provider and one or more customers and addresses specific aspects of the service, such as responsibilities, details on the type of service, expected performance level (e.g., reliability, acceptable quality, and response times), and requirements for reporting, resolution, and termination." Note the tail of that sentence. Reporting, resolution and termination are the parts teams skip, and they're the parts that decide what happens when things go wrong.

Three things get called an SLA in casual conversation, and they behave differently on the day you miss one.

The OLA is the one teams skip, and it's usually the thing propping up the customer-facing number: your resolution promise is only as good as the internal commitments underneath it. If engineering won't commit to a response target for escalations, you can't honestly promise a resolution time that depends on them. Either the internal agreement gets made first, or the public commitment stays limited to responses.

You want all three eventually, and you want to know which one you're writing at any given moment. Teams get into trouble by publishing an SLA while only having built an internal target: the number goes on the website, the mechanics to hit it don't exist, and the first bad week turns into an email you don't want to send.

The three clocks, and why one number isn't an SLA

Most published email SLAs quote a single figure, and that figure is almost always first response time. It's the easiest to measure and the least representative of what your customers experience. There are three clocks, and they fail for different reasons.

First response time is a promise about attention. Resolution time is a promise about outcome, and you control much less of it: a refund you have to request from finance, a bug that needs a release, a shipment nobody can find. Next response time sits between them, gets measured by almost nobody, and is the one customers actually feel. A four-hour first reply followed by three days of silence is a worse experience than a one-day first reply and steady contact after it, and a dashboard reporting only the first clock will show that thread as a success.

If you want the wider metric set that these sit inside, we've written up first response time and SLA adherence alongside the other numbers worth tracking. This page is about the operational definitions: when each clock starts and when it stops.

What starts and stops the clock

Every rule you don't write down becomes an argument later, usually with a customer, occasionally with a colleague who reported the month's numbers differently than you'd have reported them. Here are the ones that come up, with the answer that holds up.

An auto-acknowledgement isn't a first response. "We got your message and we'll be in touch" is a courtesy, and it's worth sending, but if it stops the clock then your SLA measures nothing except whether your mail server is running. The clock stops when a person answers the question or explains what happens next.

The clock starts when the message arrives, not when somebody opens it. Arrival time is in the mailbox and isn't editable. Anything based on when a person got to it will quietly measure your reaction to your own backlog.

Duplicate messages don't restart anything. A customer who sends three emails in four minutes because they forgot an attachment is one conversation, and the clock started with the first one. Measure from the earliest unanswered message in the thread. The alternative rewards you for a customer's impatience.

Reopens get a fresh clock, on the next-response target. A resolved thread that comes back to life two days later is a next response, and counting it as a brand-new first contact will flatter your first-response numbers while the customer waits.

"Waiting on customer" pauses the clock, and it's the easiest number to fake. You need the pause, because you can't be held to a two-hour target while the customer takes a week to send you their order number. You also need a rule that stops it from swallowing your misses: the pause only applies when you asked the customer a specific question, it ends the moment they reply, and a thread that's been parked for a couple of weeks gets closed rather than left pausing forever.

A message a colleague forwards in from their personal inbox starts its clock at the customer's original send time, not at the forward. This one hurts, which is why it's worth writing down: the customer has been waiting the whole time.

Business hours or calendar hours: pick one and publish it

Take the Friday evening message from the top of this page. Under a calendar-hours clock, a 24-hour promise expired at 17:50 on Saturday, and the Monday morning reply landed almost 39 hours after that deadline. Under a business-hours clock with coverage from 09:00 to 17:00 Monday to Friday, the clock started Monday at 09:00 and the 08:40 reply arrived before the clock ever began. Same message, same reply, opposite verdicts. The only thing that decides which one is right is which one you published.

For a team of two to fifteen people, the honest answer is nearly always a business-hours clock plus a stated coverage window, and the reason is that you can hit it. A calendar-hours promise you break every weekend is worse than a slower one that holds, because the first teaches customers that your published numbers are decoration.

Two details to settle while you're there. Time zone: name yours, in your policy and in your auto-acknowledgement, especially if your customers aren't in it. "Within one business day (we're in CET, 09:00 to 17:00)" prevents the whole class of argument. Holidays: decide whether public holidays are non-working days for the clock, then use the same list in your reporting, or your December numbers will look like a collapse in service quality when they're really just Christmas.

Picking targets you can actually hit

Start with what you're already doing. The figure in somebody else's guide was set by somebody else's staffing. Pull the last month of conversations, measure the gap between arrival and first human reply, and look at the whole distribution.

The average is the trap. Twenty conversations answered in ten minutes and one that sat for three days averages out to something under four hours, and that four hours describes nobody's experience. An SLA is a promise about the bad cases, so measure at a percentile: sort your response times, take the 90th percentile, and you've got the number that says "nine out of ten people got an answer at least this fast." Set your first target near that figure. It'll feel pessimistic, which is the point, because it's the number your slow days have to clear.

Then work backwards from coverage. If one person is on the inbox from 09:00 to 17:00 and volume peaks after lunch, a two-hour target across the whole day is a staffing calculation dressed up as a goal, and it will fail every afternoon. Set the first target close to what you already deliver, hold it for a quarter, then tighten it. Targets that ratchet down slowly stick, and aspirational ones get quietly dropped around week six.

If the honest answer is that you need more hands before the number moves, capacity and coverage planning is the prior question. Our support team size calculator will give you a rough staffing shape to argue from.

Once you've got a target, compliance rate is what you report:

Conversations that met the target, divided by conversations in the window, times 100.

State the window (a calendar month is fine) and state the exclusions in the same breath. Two ways teams accidentally lie to themselves with this formula, both common:

1. Excluding the inconvenient cases. Spam, yes. Internal test messages, yes. "The ones that came in during the outage," no. Once the exclusion list grows past a couple of mechanical categories, the number is measuring your list, not your service.
2. Counting only conversations that got a reply at all. A thread nobody ever answered is an infinite response time, and if your report silently drops it, your worst failures are invisible. Count unanswered conversations as misses.

Tiering: not every email deserves the same clock

One target for everything is either too slow for the outage or too fast for the feature request. Two or three tiers is the right amount at this team size, and the tiers should hang off categories you already sort by rather than a new taxonomy nobody remembers.

If you've already got a working sorting pass, tier on top of it: the same categories you use for triage usually map straight onto urgency. An outage or "I've been charged twice" tier measured in minutes. A billing and account tier measured in hours. Everything else, including how-to questions and feature requests, measured in business days. Contract customers with a support clause of their own get whatever the contract says, which is a separate tier by definition.

Two traps. A tier nobody owns will fail quietly: if the fast lane doesn't have a named person watching it during the coverage window, then the fast lane is a label rather than a lane. And if everything can be marked urgent by the sender, everything will be. Urgency is assigned by whoever triages, using rules you wrote, not by the customer's subject line.

The deadlines you don't get to choose

Some clocks aren't yours to set, and they sit on top of whatever your policy says.

Privacy requests are the first source, and the ones support inboxes see most often. If a customer emails your support address asking what data you hold on them or asking you to delete it, that's a statutory request in a lot of jurisdictions, with a statutory deadline. Under the CCPA, the California Attorney General's consumer guidance states that "[b]usinesses must respond to your request within 45 calendar days" and that they "can extend that deadline by another 45 days (90 days total) if they notify you." Calendar days, and the clock doesn't care that the message landed in a shared inbox rather than a privacy portal. One qualifier that matters at this team size: the CCPA only binds businesses over defined revenue and data-volume thresholds, so a ten-person company may well sit outside it. Whether you're in scope turns on your own size and data volumes, and other regimes set both their own thresholds and their own deadlines, so it's worth finding out which ones apply to you instead of assuming either way.

Contracts are the second source. An enterprise MSA with a support clause in it usually names response times per severity, and those override your public policy for that customer. If you've signed any, they belong in your tier list rather than in a folder nobody's read since the deal closed.

Payment processors are the third: dispute and chargeback windows are set by the processor, and a customer email that's actually a dispute has a deadline attached that has nothing to do with your SLA. None of this is legal advice, and the point is operational: know which messages in your inbox carry a clock somebody else set, and route them to the person who owns them on arrival.

Writing the policy down: a one-page email SLA template

A usable email response time policy fits on one page and has eight fields. Fill them in and you've got your template. If you can't fill one in, that's the part that will cause the argument later.

Write it in plain language, publish the customer-facing half of it (scope, coverage, targets), and keep the mechanics half internally. The published version can be three sentences on a contact page. The internal version is the one that settles disputes, so it's the one that needs the clock rules from earlier in this article spelled out.

How to measure it without a helpdesk

You don't need to buy a system to start, and whether your team can carry help desk software yet is a separate question worth answering on its own terms. What you do need is honesty about what each of these methods can and can't tell you.

Gmail: find the aging threads. Google's search operator reference documents older_than: and newer_than: with day, month and year units (older_than:1y, newer_than:2d), plus after: and before: with explicit dates. Combined with a label you apply to anything still waiting on you, that gives you a standing list of the threads that have been sitting too long. Two limits worth saying out loud. The smallest unit these operators take is a day, so they'll catch the message from Tuesday and do nothing at all for a four-hour target. And is:unread is a poor stand-in for unanswered: the thread that hurts you is the one somebody read, meant to come back to, and didn't. It's a queue check rather than a report, and at low volume it's most of what you need.

A spreadsheet: get a defensible number. Export a month of conversations with arrival and first-reply timestamps, then compute elapsed time. For a business-day view, Google Sheets' NETWORKDAYS "[r]eturns the number of net working days between two provided days," with the syntax NETWORKDAYS(start_date, end_date, [holidays]) and an optional holidays range. Two honest caveats: it counts whole working days, so a target measured in hours needs its own arithmetic on top, and the export is only as good as the timestamps you can get out of your mailbox. Sort the resulting column and read the 90th percentile off it.

Microsoft 365: arrival timestamps from message trace. In Exchange Online, message trace gives admins the received date and time for messages. Microsoft documents the limits clearly: you can specify ranges up to 90 days but only query 10 days at a time for instant results, anything longer comes back as a downloadable CSV that "might take several hours" to prepare, and there "might be a five to ten minute delay" between actual and reported delivery status. It'll tell you when things arrived. It won't do your reply-time math, so it feeds the spreadsheet rather than replacing it.

Then the honest ladder. Manual sampling works at genuinely low volume: read the queue twice a day, note the stragglers, fix them. A monthly export holds up to a few hundred conversations. Past that, exports stop being a measurement and start being a monthly archaeology project, because by the time you find the misses they're weeks old and nobody remembers the thread.

That's the point where the queue has to carry its own state instead of a spreadsheet carrying it for you, which is what a shared inbox tool like TriageFlow does: every conversation has an owner and a status the whole team can see, so "nobody has answered this one" is a property of the thread while it still matters, rather than a line in next month's export. How much structure you need on top of that varies, and what a ticketing system adds beyond an ID and a clock is worth reading before you pick.

What actually breaks SLAs

The misses cluster. In practice it's almost always one of these five, and each has a fix that isn't "try harder."

Nobody owns the queue first thing. Overnight mail sits until someone decides it's theirs, which is usually mid-morning, which eats the whole target before the day starts. Fix: name the person who opens the inbox each morning, by rota, in writing.

One specialist is the only person who can answer a class of question. Every billing question waits for the one person who understands billing, and their sick day is a bad week for the numbers. Fix: write down the three most common answers in that class so a second person can handle the routine version, and keep the specialist for the exceptions.

"Waiting on engineering" with no internal clock. The customer's thread is technically active, nobody's lying, and three weeks pass. This is exactly what an OLA is for: agree a response target between support and engineering, and give support a standing rule to update the customer on a schedule even when there's nothing new. Silence is what customers escalate about, not delay.

Coverage gaps nobody planned for. Holidays, sick days, the Friday when both people who watch the inbox are at an offsite. Fix: put coverage on the same calendar as time off, and if you can't cover a window, change the published coverage rather than quietly missing the target.

The long thread where the clock restarts and nobody notices. The customer replies, the conversation looks handled because someone answered it three days ago, and the next-response clock runs unwatched. Fix: measure next response, or at minimum sort your queue by "oldest customer message without a reply after it" rather than by thread start date.

When you miss one

You will. What matters is what happens in the next hour and at the next review.

To the customer, send something short and specific. Say what happened in one clause, say what happens next with a time attached, and don't over-apologise or invent a cause you haven't verified: "Sorry, this sat over the weekend and shouldn't have. I've got it now and you'll have an answer on the refund by 15:00 today." That's it. A paragraph of contrition just makes them read further to reach the part that helps, and a made-up explanation ("our system flagged your message") is the thing you'll regret when it turns out not to be true.

Internally, review misses in a batch rather than one at a time. One late reply is noise; six late replies in a month that all arrived between 16:00 and 18:00 is a coverage problem with an obvious answer. Look for the pattern, then change one thing.

And be willing to change the target instead of the process. A target you miss most weeks isn't ambitious, it's wrong, and every week it stands it teaches your team that the number is theatre. Publish the slower target you always hit and you never have to defend it. The same logic argues for not having an email SLA yet: if you're three people who all see every message and answer within the hour without thinking about it, a policy document buys you nothing. What you need is a rule about who opens the inbox first and a note of when that stops working. Write the SLA when the queue gets big enough that somebody can wait without anybody noticing.

Frequently asked questions

What is an email SLA?

It's your published answer to "how fast will somebody reply to me," with the rules attached: which messages are covered, when the clock starts and stops, and which hours it runs on. Without those rules you've got a number rather than an agreement, and the number won't survive its first disputed weekend.

What is a good SLA response time for email?

The one your coverage can support, measured at the 90th percentile of what you already do. There's no universal number worth copying, and most of the figures circulating on this topic trace back to somebody's marketing page. Measure your own distribution, set the first target near your current p90, then tighten it once it holds for a quarter.

What's the difference between response time and resolution time?

Response time stops when a person replies. Resolution time stops when the customer's problem is actually gone, which often depends on people outside support: finance for a refund, engineering for a bug. Give them separate targets, because a team that's fast at replying can be slow at finishing, and a single number hides which one you've got.

How do you calculate SLA compliance?

Divide the conversations that met the target by all conversations in the window, then multiply by 100. Two rules make it honest: count unanswered conversations as misses rather than leaving them out, and keep the exclusion list to mechanical categories like spam and automated mail.

Is an email SLA measured in business hours or calendar hours?

Either works, as long as you pick one and publish it along with your coverage window and time zone. Business hours is the realistic choice for most small teams. Undefined is the choice that produces the Friday-evening argument this article opens with.

What happens when you miss an email SLA?

For an internal target or a published one, nothing contractual: you tell the customer where their issue stands, and you review the misses as a batch to find the pattern. For an SLA embedded in a signed contract, whatever remedy that contract names, which is usually a credit rather than a penalty. Either way the useful response is a change to coverage, ownership or the target itself.