Support schedules are among the shortest annexes in an enterprise software agreement and among the most frequently argued. The table of severity levels and response times is usually agreed quickly, because it looks standard, and the standard version leaves most of the operative questions open.
Those questions surface during the first serious incident. Was this a severity one or a severity two. Did the clock start when the ticket was raised or when it reached the right queue. Was the three days spent waiting for the customer to provide a log file counted against the vendor. None of these can be settled by reference to a table that lists four severities and a response time against each. They are settled, in practice, by whichever party has the better record of what happened, which is usually the vendor, because the ticketing system is theirs.
The commercial stakes are usually modest, since support credits are typically capped at a small share of fees. The relationship stakes are not. A disputed severity classification during an outage does more damage to a renewal than almost anything else, because it happens at the moment the customer is least able to be reasonable and most likely to remember. A vendor that wins the classification argument and loses the account has not had a good day. That asymmetry is one reason it is worth treating support terms with the same rigour applied elsewhere in a managed SaaS portfolio.
The five components of a defensible schedule
A support annex that survives contact with an incident addresses five things. Most standard templates address two of them, which are the severity labels and a response number, and leave the other three to be worked out while something is broken.
- Impact-based severity definitions, describing the effect on the customer's business rather than the vendor's view of the component involved.
- Separate response, update and resolution targets, so acknowledgement, communication cadence and restoration are each committed independently.
- Clock rules, stating the start event, the named pause triggers, the resumption condition and the coverage hours that apply.
- Reclassification and escalation, covering who assigns severity, how a disagreement is resolved and the time-based escalation ladder.
- Measurement basis, naming the ticketing system of record, the report, the period and the right of access to underlying data.
Clock rules are where most value sits and where most templates are silent. A support obligation with no pause provision is unfair to the vendor, since a vendor cannot resolve an issue it cannot reproduce, and one with an unbounded pause provision is worthless to the customer, because any ticket can be paused indefinitely by asking a question. Naming the specific dependencies that pause the clock, and requiring the vendor to state in the ticket that it is waiting, converts an argument into a record that either supports the pause or does not.
A severity definition the customer cannot apply without vendor knowledge will be applied by the vendor. Describe the business effect, such as a production process that cannot run, and classification becomes a matter of observable fact rather than of interpretation.
What belongs in the contract and what belongs in an annex
Support terms age faster than the agreements that contain them. Contact lists change within months, coverage calendars change annually, and the commercial commitment should not change at all. Separating the stable commitments from the operational detail keeps both usable and avoids an amendment every time a support manager moves on.
- In the contract: severity definitions. These are the commercial commitment and should require an amendment to change.
- In the contract: response and resolution targets. The numbers the customer is paying for, with the credit mechanism attached.
- In an annex: escalation contacts. Roles and contact methods, updatable by notice so the ladder stays current.
- In an annex: coverage calendars. Holiday schedules and regional coverage hours, which change annually.
- In an annex: report formats. The layout of the monthly performance report, which both sides will want to refine.
A five-step implementation roadmap
Step 1, Rewrite severity around business impact
Draft each level in terms the customer can assess without vendor input, and test the definitions against the last ten real incidents. If a past incident cannot be classified confidently from the new wording, the wording needs another pass.
Step 2, Split the single target into three
Commit separately to initial response, update cadence during an open incident and resolution or workaround. The update cadence is the cheapest of the three to provide and the one customers value most during a live outage.
Step 3, Name the pause triggers
List the customer dependencies that stop the clock, require the vendor to record the dependency in the ticket, and resume automatically on receipt. This single change removes the majority of retrospective measurement disputes.
Step 4, Move the ladder to a maintained annex
Put escalation roles and contacts in an annex updatable by notice, and review it twice a year. An escalation path that lists departed individuals is worse than none, because it consumes time during an incident before anyone realises.
Step 5, Store the schedule as contract data
Load severity levels, targets and coverage hours as structured fields on the contract record so the commitments can be compared across a portfolio. Vendor management teams routinely discover that two suppliers of similar criticality carry very different terms.
Compare support terms across the portfolio
Severity tables, targets and coverage held as fields rather than buried in annexes.
Why portfolio visibility changes the negotiation
Individually negotiated support terms drift apart. One vendor commits to a one-hour response with a four-hour workaround target; another, supporting an equally critical process, commits to next business day with no resolution target at all. Neither position was unreasonable at the time, since each was negotiated by a different team against a different counterparty with different leverage, and the inconsistency is invisible until the terms sit side by side in a table. Holding them as structured data makes that comparison routine and turns the next renewal into an evidence-led conversation, which is the same effect that structured renewal data has on auto-renewal exposure across a SaaS estate.
Severity levels and what each should commit
The table shows a conventional four-level structure. Targets are illustrative and should be set against the criticality of the service and what the vendor can genuinely sustain.
| Severity | Business impact | Initial response | Update cadence |
|---|---|---|---|
| One, critical | Production unavailable, no workaround | Minutes, around the clock | Hourly until downgraded |
| Two, high | Major function degraded, workaround painful | Hours, business coverage | Daily |
| Three, medium | Non-critical function impaired | One business day | Weekly |
| Four, low | Question, cosmetic issue or enhancement | Two to three business days | On change of status |
| Reclassification | Either party disputes the assigned level | Escalate on stated timeline | Record original and final level |
The best test of a support schedule is to replay the last significant incident against it on paper. Classify it under the new definitions, apply the clock rules to the actual ticket timeline, and see whether the result matches what both parties believed at the time. Where it does not, the schedule has told you exactly which clause to rewrite before the next renewal. The exercise takes an hour and is considerably more productive than negotiating response times downward by fifteen minutes, which is what these discussions usually become.
For related guidance, see When the order form and the MSA disagree, Open source license clauses in customer contracts and The channel leader’s guide to OEM and reseller terms.
