Uptime commitments get most of the attention in SLA negotiations, but enterprise buyers routinely care just as much about what happens when something goes wrong. How quickly will you respond? Who do they call at 2am if their integration breaks before a board presentation? Is there a human on the other end or a ticket queue?
Support response time commitments are the second half of the SLA conversation, and for many enterprise customers they’re the more operationally meaningful half. A service that’s up 99.9% of the time but takes 48 hours to respond to a critical issue is not enterprise-ready.
This post covers how to structure support tiers, what to promise and what to avoid, and how to set commitments that are realistic for your team size without sending enterprise buyers to a competitor.
Response Time vs. Resolution Time
The most important distinction in support SLAs is between response time and resolution time. Commit to the former. Never commit to the latter.
Response time is the time between a customer submitting a support request and your team acknowledging it. This is something you can control. You staff a support queue, you set routing rules, you monitor for incoming tickets. Whether a ticket gets a first response within two hours is a function of your processes, not the complexity of the underlying problem.
Resolution time is the time between submission and the problem being fixed. This is not something you can reliably control. A P1 issue might be a misconfiguration that takes 15 minutes to resolve. It might be a data corruption bug that takes three days to diagnose and patch. Committing to resolve critical issues within four hours is a promise you will eventually break, and when you break it during a genuinely complex incident, you’ll be in breach on your worst day.
Enterprise buyers will push for resolution time commitments. The honest response is that resolution time depends on the nature of the issue and cannot be contracted reliably, but that you commit to continuous communication throughout the incident: updates every hour for P1 issues, every four hours for P2, until resolution. Cadenced communication commitments are achievable and often more valuable to customers than an aspirational resolution SLA you can’t honor.
Severity Classification
Support SLAs are structured around severity tiers. The tier determines the response time commitment and the level of escalation. A standard four-tier framework:
P1 — Critical. The service is completely unavailable or a core workflow is broken for all users. Business operations are materially impacted. Examples: production outage, data inaccessibility, authentication failure preventing all logins.
P2 — High. A significant feature or workflow is degraded or unavailable for a subset of users, with no viable workaround. Business operations are impacted but not halted. Examples: intermittent errors in a core workflow, a major integration failing for some accounts, significant performance degradation.
P3 — Medium. A non-critical feature is impaired or behaving unexpectedly, with a viable workaround available. Examples: a reporting feature returning incorrect data, a UI element behaving unexpectedly, a minor integration issue with a workaround.
P4 — Low. General questions, feature requests, documentation issues, and non-urgent configuration assistance. No operational impact.
The classification framework matters because customers will try to classify everything as P1. Your SLA should include a definition for each tier precise enough that you can push back when a feature request arrives marked critical. It should also give you the right to reclassify tickets based on your assessment of actual impact, subject to good faith dispute resolution if the customer disagrees.
Setting Response Time Commitments
Response time commitments need to be calibrated to your team size and support coverage model. A two-person founding team cannot credibly commit to one-hour P1 response around the clock. An enterprise SaaS company with a dedicated support function can.
A realistic framework by team size:
| Severity | Small team (1-3 support staff) | Mid-size team (4-10 support staff) | Dedicated enterprise support |
|---|---|---|---|
| P1 | 4 hours, business hours | 1 hour, extended hours | 30 minutes, 24/7 |
| P2 | 8 hours, business hours | 4 hours, business hours | 2 hours, business hours |
| P3 | 2 business days | 1 business day | 4 business hours |
| P4 | 5 business days | 3 business days | 2 business days |
A few structural points:
Define business hours explicitly. “Business hours” is not self-defining. Your SLA should specify the timezone, the days, and the hours. 9am to 6pm Eastern, Monday through Friday, excluding public holidays is precise. “Business hours” is not.
Be honest about 24/7 coverage. If you don’t have 24/7 support, don’t commit to it. Enterprise buyers will test this commitment. If your P1 response SLA is one hour around the clock and a critical incident opens at 11pm on a Friday and gets no response until Monday morning, you’ve failed the most important test in the relationship. An honest 4-hour P1 response during business hours is a better starting point than a 24/7 commitment you can’t staff.
Escalation paths matter as much as response times. Enterprise buyers want to know that if a P1 goes unresolved after the initial response, there’s an escalation path to someone with authority and technical depth. Define it: P1 tickets unresolved after two hours escalate to a named technical contact or engineering on-call. This is often more reassuring than the initial response time commitment.
Support Channels
Enterprise buyers will ask about support channels. Email ticketing is the baseline. Beyond that, the options are live chat, phone support, a dedicated Slack channel, and a named customer success manager.
Each channel carries different staffing implications. A dedicated Slack channel per enterprise customer creates an always-on communication expectation that is difficult to manage across a large customer base. Phone support requires staffing a phone queue. Named CSMs don’t scale below a certain ACV threshold.
The provider-friendly position is to define your standard support channels clearly, reserve premium channels for enterprise tiers, and price accordingly. A reasonable tiered structure:
Standard: Email ticketing with defined response times. Professional: Email ticketing plus live chat during business hours. Enterprise: All of the above plus a dedicated Slack channel, a named customer success manager, and quarterly business reviews.
If an enterprise customer wants a dedicated Slack channel on a standard plan, the answer is a plan upgrade, not a one-off accommodation that sets an unsustainable precedent.
Connecting Support SLAs to Uptime SLAs
Support response time commitments and uptime commitments are not independent. During an active P1 incident, both are in play simultaneously. Your SLA should address this explicitly: uptime measurement is paused or the incident is classified as a single downtime event, not a compounding failure that triggers both uptime credits and support SLA remedies for the same event.
The remedies for support SLA failures are also worth addressing separately from uptime credits. The standard approach is a similar credit mechanism: failure to meet a P1 response time commitment triggers a credit, tiered by severity and capped per period. The same sole-and-exclusive-remedy logic applies: credits are the remedy for support SLA failures, not damages claims.
One additional point that founders often miss: your support SLA commitments affect your cyber insurance and Tech E&O premiums. Underwriters look at your incident response procedures and support commitments as indicators of operational maturity. Documented escalation paths, defined response times, and a named on-call structure signal that you have a process for managing failures, which affects how underwriters assess your risk profile.
What Enterprise Buyers Are Actually Evaluating
When an enterprise buyer reviews your support SLA, they’re evaluating three things: whether you’ve thought about failure scenarios, whether your commitments are realistic, and whether they’ll be able to reach a human when something breaks.
Overpromising on support is as damaging as overpromising on uptime. A support SLA that commits to 30-minute P1 response around the clock from a five-person startup will be disbelieved, or believed and then broken at the worst possible moment. The enterprise buyers most worth closing are experienced enough to know what’s realistic at your stage.
What signals enterprise readiness is not the most aggressive response time on the page. It’s a clearly structured severity framework, honest coverage hours, defined escalation paths, and evidence that you’ve built a support function rather than an ad hoc inbox. That’s a credible foundation to build on as you grow, and enterprise buyers who’ve worked with enough early-stage vendors know the difference.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.