What is a support addendum?
Are support response and resolution targets enforceable in South Africa?
“When a supplier undertakes to perform a service, the consumer has the right to the timely performance of that service, and to performance in a manner and quality that persons are generally entitled to expect — a non-excludable baseline that sits behind a support addendum where the customer is a consumer.”
“Where a missed support target is backed by a service credit, that credit is a valid and enforceable penalty; but a court may reduce it to such extent as it considers equitable if satisfied that it is out of proportion to the prejudice suffered by reason of the breach.”
When you need a Support Addendum
- When a cloud or SaaS provider offers tiered support plans and the customer needs the support promise — channels, hours, and severity-based response times — written down rather than left to a marketing page.
- When the customer’s operations depend on faults being handled quickly, and the parties want enforceable target response (and ideally resolution) times for critical incidents.
- When the provider needs to define what support does and does not cover — ring-fencing the customer’s own environment, misuse, customisations, and third-party products as out of scope.
- When a master cloud or SaaS agreement is in place and the support commercials need to live in a separate schedule that can be updated without reopening the whole contract.
- When the customer is a consumer (or small business under the CPA) and the parties want the support terms to align with the section 54 quality-of-service baseline.
What a Support Addendum should contain
Support tiers / plans and what each includes
Set out the support plans on offer (for example standard, business, premium) and exactly what each includes — channels, coverage hours, named-contact limits, and the severity targets that attach. The customer should be able to see, from the addendum alone, precisely what level of support it has bought, rather than inferring it from sales material that is not contractual.
Channels and coverage hours
Specify the channels through which the customer may log a request (portal, email, phone, chat) and the coverage window — business hours in a stated time zone, extended hours, or 24/7 — including how public holidays are treated. Coverage hours are what determine when the response clock runs, so an ambiguous “business hours” without a time zone or holiday treatment is a common source of dispute.
Severity / priority levels with response and resolution targets
Define the severity matrix — typically Severity 1 (critical / service-down) through to Severity 4 (low-impact query) — with objective criteria for each, and assign a target response time, and where offered a target resolution time, to each level. Distinguish carefully between a binding commitment and a “target”, and state which clock runs only within coverage hours. This matrix is the operational heart of the addendum.
Scope of support and exclusions
State what support covers and, in detail, what falls outside it: faults in the customer’s own environment, network, or configuration; misuse or use contrary to documentation; the customer’s own customisations and integrations; and third-party products the provider does not control. Clear exclusions stop the support team being drawn into work it never agreed to do and prevent disputes over whether a fault was “supportable”.
Escalation path
Set out how an incident is escalated when it breaches its target or the customer is dissatisfied — the internal tiers it moves through, the contacts at each level, and the timeframes. A defined escalation path is often the real remedy for a missed support target (in place of, or alongside, credits), so it should be concrete rather than a vague promise to “escalate appropriately”.
End-of-life and version-support policy
State how long each release or version of the product is supported, the notice the provider must give before a version reaches end-of-life, and what support (if any) continues afterwards. This protects the customer from being stranded on an unsupported version and gives the provider a clean basis to retire old releases on agreed notice.
Customer responsibilities and dependencies
List what the customer must do for support to work — for example providing reproduction steps and diagnostic information, maintaining a supported configuration, granting reasonable access, and using authorised contacts. Where the customer’s failure to meet a dependency causes or prolongs a fault, the addendum should make clear that the response/resolution clock is paused or the matter falls outside scope.
Boundary with the SLA and remedies
State expressly that this addendum governs support (response and resolution of faults) while availability is governed by the SLA, and that the two use consistent severity definitions. Set the remedy for a missed support target — escalation, service credits, or both — and say whether any credits are the sole financial remedy, so the customer is clear on exactly what a breach entitles it to.
Support addendum vs SLA addendum
| Feature | Support addendum | SLA addendum |
|---|---|---|
| Question it answers | How quickly are faults responded to and resolved? | Is the service up and meeting its uptime target? |
| Core metric | Response (and sometimes resolution) time by severity | Availability percentage over a measurement window |
| Structured around | Severity / priority matrix and support tiers | Uptime formula, downtime definition, and exclusions |
| Typical remedy | Escalation; sometimes credits for missed response | Service credits (often the sole financial remedy) |
| SA touchpoint | Contractual targets; CPA s 54; Conventional Penalties Act if credit-backed | Conventional Penalties Act (credits as penalty); CPA s 54 |
Common South African pitfalls
- Vague targets: a support addendum that promises “prompt” or “reasonable” support, without a severity matrix and defined response (and ideally resolution) times, gives the customer little to enforce. Targets must be precise and objective, and the addendum must say whether they are binding commitments or merely aspirational targets.
- Confusing support with availability: response and resolution times answer how quickly faults are handled — they are not an uptime guarantee. Customers who rely on a support addendum for availability, or providers who let the two documents use inconsistent severity definitions, end up with a gap no one priced for. Keep the SLA and support addendum aligned but distinct.
- Loose or missing exclusions: failing to put the customer’s own environment, misuse, customisations, and third-party products clearly out of scope draws the support team into work it never agreed to and fuels disputes over whether a fault was “supportable”. The exclusions and customer-dependency clauses do much of the heavy lifting.
- Ignoring coverage-hour mechanics: a target with no stated time zone, no public-holiday treatment, and no rule on when the clock pauses for the customer’s delays is a dispute waiting to happen. Define exactly when the response clock runs and when it stops.
- Contracting below the CPA where it applies: where the customer is a consumer, section 54 of the Consumer Protection Act guarantees a service of the quality persons are generally entitled to expect, and that cannot be excluded. A support addendum that purports to drop the provider’s obligations below that baseline is, to that extent, unenforceable against a consumer.
Frequently asked questions
What is the difference between a support addendum and an SLA?
A support addendum governs how quickly the provider responds to and resolves faults and queries, organised around a severity matrix and target response (and sometimes resolution) times. An SLA governs availability — whether the service is up and meeting its uptime target. They are complementary schedules that should share consistent severity definitions, but they measure and remedy different things.
Are support response times legally binding in South Africa?
Yes, if drafted as clear, certain commitments. Response and resolution targets are ordinary contractual terms and are enforceable like any other. A precise target — for example “Severity 1 response within 1 hour” — binds the provider, whereas a vague promise of “prompt” support gives the customer far less to enforce. Many addenda frame times as targets, not guarantees, which the document should make explicit.
What is the difference between response time and resolution time?
Response time is how long the provider takes to acknowledge a logged fault and begin work; resolution time is how long it takes to fix or provide a workaround. Many support addenda commit firmly to response times but treat resolution times as targets, because resolution often depends on the nature of the fault and the customer’s cooperation.
What does a support addendum exclude from scope?
Standard exclusions are faults in the customer’s own environment, network, or configuration; misuse or use contrary to the documentation; the customer’s own customisations and integrations; and third-party products the provider does not control. These exclusions define the real boundary of support and prevent disputes over whether a fault was the provider’s responsibility.
What happens if the provider misses a support target?
It depends on the remedy the addendum sets. Some addenda provide for escalation up defined tiers; others attach a service credit to a missed target; some do both. Where a credit is payable it is a penalty under the Conventional Penalties Act 15 of 1962 — valid and enforceable, but reducible by a court if out of proportion to the customer’s prejudice.
How are severity levels defined?
By objective impact criteria. A typical matrix runs from Severity 1 (critical — the service is down or a key function is unusable) through to Severity 4 (a low-impact question or cosmetic issue), with each level given its own response and resolution targets. Defining severity by objective criteria, rather than leaving it to the parties to argue, is what makes the matrix work in practice.
Does the Consumer Protection Act apply to a support addendum?
It can. Where the customer is a consumer — including a small business below the CPA threshold — section 54 of the Consumer Protection Act gives a right to a service of the quality persons are generally entitled to expect, and that right cannot be excluded. A support addendum should align with that baseline rather than purport to drop the provider’s obligations below it.
What is an end-of-life or version-support policy?
It states how long each release of the product is supported, the notice the provider must give before a version reaches end-of-life, and what support continues afterwards. It protects the customer from being stranded on an unsupported version and gives the provider a clean, agreed basis to retire old releases on proper notice.
Sources & authority
This guide is general information, not legal advice. It reflects the law as at June 2026.