A service level agreement is a promise about response, written down, so that when something breaks you already know what happens next. The problem is that most AI support promises are written to sound reassuring rather than to be useful. "We offer dedicated support" tells you nothing. Dedicated to what, responding in what time, to which kind of problem.
A real SLA answers three questions in advance. How bad is the problem, how fast will someone respond, and who owes you that response. Get those three right and support stops being a hope and becomes a commitment.
Severity is the right axis, not uptime
The most common mistake is to anchor the whole agreement on an uptime percentage. Uptime sounds precise and is mostly theater for a custom system serving one organization. Ninety nine point nine percent uptime still allows for nearly nine hours of downtime a year, and it tells you nothing about how fast a human responds when the system is the one tenth of a percent that is down during your month end close.
The better axis is severity. Severity ties the response to the impact on your business, which is the thing you actually care about. A typo in a report and a system that is completely down are not the same problem, and they should not get the same response time. A severity based SLA says so explicitly.
Availability based promises measure the system. Severity based promises measure your impact. You do not run your business on a percentage. You run it on whether the thing that just broke is stopping work right now. Severity is the axis that matches how the breakage actually feels from your side of the table.
The three tiers, and what each one means
A clean AI support SLA has three severity tiers. More than that and the boundaries blur. Fewer and you lose the distinction between a catastrophe and an annoyance. Here is the shape Heed uses, with representative targets. Exact terms are set per engagement.
| Severity | Definition | Target Response |
|---|---|---|
| Critical | System down or core function unusable | Within hours, same business day |
| High | Major feature degraded, workaround exists | Next business day |
| Standard | Minor issue, question, or enhancement | Within the service week |
Critical is reserved for the real emergencies. The system is down, or a core function your operation depends on has stopped working with no workaround. The response target is measured in hours, on the same business day, because every hour the critical issue persists is an hour your business is paying for. Critical is the tier the whole agreement exists to handle.
High covers a major feature that is degraded but has a workaround. The thing is painful but the business is still moving, so the response target is the next business day. The distinction from critical is the workaround. If there is a way to keep working, even an ugly one, it is high and not critical.
Standard is everything else. A minor issue, a question, a request for an enhancement. These are handled within the service week. Standard is not a dumping ground for things the vendor does not want to do. It is the honest tier for work that genuinely is not urgent, which keeps the urgent tiers meaningful.
Who owes you the response
This is the clause most buyers never think to check, and it is the one that matters most for continuity. Read the agreement and find out who the support obligation is owed by. If the answer is a named individual, you have bought a single point of failure with a response time attached. The SLA is only as reliable as that one person's availability, which means it is not reliable at all.
A real AI support SLA says the obligation is fulfilled by a team, tooling, and documented procedures, and is not contingent on the availability of any single individual. That sentence is what makes the response targets above worth anything. A four hour critical response target means nothing if the only person who can deliver it is on a plane. It means everything if the obligation is owed by a team operating from documented runbooks.
The tie to compliance
The same machinery that makes the SLA real makes your compliance posture real. Severity classification, response tracking, and audit logging are exactly what ISO 42001 and NIST AI RMF expect from a managed AI system. When every action is logged, you can prove what happened, when, and who handled it. That evidence serves the support agreement and the audit at the same time, which is the recurring theme across every part of how Heed structures an engagement.
What to ask before you sign
Three questions filter a real SLA from a reassuring one. First, are response targets defined by severity, with critical, high, and standard each carrying a written target. Second, is the support obligation owed by a team and documented procedures rather than by one person. Third, is every action audit logged so the commitment can be verified after the fact.
If the answer to all three is yes, you have a support agreement you can run a business on. The Heed managed support model is built exactly this way, and it sits alongside the escrow and ownership options that protect you in the scenario the SLA is not designed for. Read the full Support and Continuity policy for the complete picture, or the next post on why a clean exit is the strongest trust signal a vendor can offer.