Post

Anyone asked to review a SaaS contract tends to read the price, the term and the liability cap first, and the service level schedule last. Yet it is the schedule that decides what happens on the morning the platform goes down: who measures the failure, what it is worth and when either side may walk away.

Our note on technology arbitration in SaaS service failure disputes covers what happens once a dispute has crystallised and a tribunal is involved. This piece sits before that point. It looks at the escalation matrix a well drafted agreement builds between the first missed target and the last resort of termination.

Key Takeaways

• An outage is not a breach until it is measured against the agreed metric, window and exclusions.
• Severity levels drive response times, escalation contacts and often whether credits accrue at all.
• A sole and exclusive remedy clause can turn service credits into a ceiling rather than a floor.
• Cure periods and chronic failure triggers decide when a customer may terminate without a fight.
• Exit terms on data return, format and deletion matter as much as the right to leave.

How an Escalation Matrix Is Built

Most enterprise SaaS agreements classify incidents by severity. A severity one incident is usually a complete loss of the service, or of a core function, with no workaround. Severity two is a material degradation, and the lower levels cover partial faults, cosmetic defects and general questions. Each level carries a response time, a target restoration time and an interval at which the vendor must provide updates.

The matrix then names who is told and when. A severity one incident not restored within the target time moves from the support desk to a named service manager, then to an account executive, and finally to a senior officer on each side. Those steps are useful only if the names and contact routes are kept current.

Classification is where the first disagreement arises. Most agreements let the vendor assign the severity, sometimes after consultation. A customer should look for a right to dispute the classification and for a definition that turns on business impact rather than on the vendor's view of the fault. A payroll module that cannot run on the last working day of the month is a severity one problem for the customer whatever the ticketing system says.

Escalation under the matrix is also distinct from the dispute resolution clause. Many contracts contain both, and the stages should not be confused. Our note on drafting traps in multi tier dispute resolution clauses explains why the negotiation and mediation steps that precede arbitration need their own timelines.

Measurement, Windows and Exclusions

An availability promise of 99.9 per cent sounds precise until one asks how it is calculated. The agreement should state the measurement period, the point of measurement and the tool that produces the figure. Monthly measurement is common, while quarterly measurement dilutes a bad week into an acceptable average. A target measured at the vendor's data centre can be met while users in Kochi cannot log in because of a component the vendor treats as outside scope.

Exclusions do most of the work. Scheduled maintenance, emergency maintenance, force majeure events, failures of third party hosting or network providers, problems caused by the customer and suspension for non payment are typically carved out. Each is reasonable in principle. Together, and drafted loosely, they can leave very little downtime that counts. Emergency maintenance with no notice requirement and no cap is the exclusion that deserves the closest reading.

The customer's own records matter here. Monitoring logs, ticket histories and captures of the vendor's status page are the evidence that will be set against the vendor's report. Where the agreement says the vendor's measurement is conclusive, the customer has accepted that the vendor marks its own paper, and that clause is worth resisting or at least qualifying with a right to verify.

Response and resolution times need the same discipline. Response often means an acknowledgement, not a fix. A schedule that promises a fifteen minute response and says nothing enforceable about restoration offers less than it appears to, and a service level agreement is only as strong as its least precise definition.

Service Credits and the Sole Remedy Clause

Service credits are the agreed price of missing a target. They are usually a percentage of the monthly fee that rises with the size of the shortfall and is capped at a fixed share of that fee. They are applied against future invoices, rarely paid in cash, and often lost if the customer does not claim them within a short window.

The legal character of a credit matters. Under the Indian Contract Act 1872, section 73 provides for compensation for loss naturally arising from a breach, and section 74 deals with a sum named in the contract as payable on breach, which a court will allow only as reasonable compensation not exceeding that sum. Vendors often draft credits as a price adjustment rather than as damages, precisely to keep them outside that analysis. Whether the label holds depends on the wording and the circumstances, which is a question for review rather than assumption.

The sharper issue is exclusivity. A clause stating that credits are the customer's sole and exclusive remedy for service level failures converts them from a floor into a ceiling. A month of severe disruption may then yield a credit worth a fraction of the fee, with no claim for the operational loss. Add the liability cap and the exclusion of indirect loss, and real recovery can be very small.

A balanced clause keeps credits as the exclusive remedy only for ordinary misses, and preserves other rights, including termination and damages, for chronic or severe failure. That carve out is the bridge to the next stage of the matrix. Our note on liability risks in multi tenant SaaS arrangements discusses how caps interact with shared infrastructure.

Cure Periods and Chronic Failure

Most termination for breach clauses require notice and an opportunity to cure, and thirty days is common. For a service level failure that structure fits poorly. An outage is usually over before the notice is served, the vendor can say it has cured, and the next outage starts a new cycle.

Chronic failure provisions fill that gap. They define a pattern that entitles the customer to terminate without a further cure period, for example missing the availability target in three months out of any rolling six, or a stated number of severity one incidents in a quarter. The trigger should be objective and measured on the same data as the credits, so that there is no argument about whether it has been met.

Cure periods also run the other way. A vendor's right to suspend for non payment is usually exercised after a short notice, and a customer that withholds fees because of poor service may find access cut before any dispute is resolved. The agreement should distinguish undisputed sums from amounts disputed in good faith, and suspension should not be available for the latter.

Where no chronic failure clause exists, the customer is left with the general law. Section 39 of the Contract Act allows a promisee to put an end to the contract where the other party has refused to perform, or disabled itself from performing, its promise in its entirety. Repeated but partial failure rarely fits that description neatly, which is why the contractual trigger is worth negotiating.

Termination Triggers and Data Return on Exit

The right to terminate is worth little if leaving means losing the data. Exit terms should state what the vendor returns, in what format, within what period and at what cost. A machine readable export in a common format, including attachments and audit logs, is the reasonable standard. A proprietary dump that only the vendor's own tools can read is not.

The retrieval window needs attention. Many agreements give the customer thirty days after termination to export, after which the data is deleted. After a dispute, that window may close while the parties are still corresponding. A clause that keeps the data available until a confirmed export, or for a defined period after a dispute notice, avoids a loss that no award can reverse.

Transition assistance is the third element. For systems that run payroll, billing or patient records, the customer needs the vendor's cooperation for a period after termination at agreed rates. A matter involving licence management for a group of Kerala hospitals shows how much operational risk sits in the exit phase.

Deletion should be certified. Once the customer has its data, it is entitled to know that the vendor and its sub processors have deleted their copies, subject only to retention that the law requires. That certificate also supports the customer's own obligations under data protection law.

What the Customer and the Vendor Should Each Check

The same schedule reads differently from each side. A customer's review normally covers the following points.

• Whether severity turns on business impact and whether classification can be challenged
• How availability is measured, by whom, and what is excluded
• Whether credits are automatic or claimed, and whether they are the sole remedy
• Whether a chronic failure trigger exists and disputed fees are protected from suspension
• What happens to the data on exit, and for how long

A vendor's review is about predictability. It wants exclusions that reflect how its infrastructure actually works, a credit cap it can price, a chronic failure trigger it can monitor internally before the customer does, and a clear statement that credits are its full exposure for ordinary misses. It should also check that its own hosting contracts give it back to back protection, since a vendor promising more than its cloud provider promises it carries the gap alone.

Both sides benefit from escalation steps that can actually be followed. A matrix requiring a meeting of senior officers within forty eight hours is useful only if both organisations know who those officers are, and the best schedules are short, measurable and kept up to date.

Conclusion

Most SaaS disputes are decided long before anyone files a claim, by the definitions, exclusions and triggers in the service level schedule. A schedule that measures fairly, prices ordinary failures through credits and preserves real remedies for chronic failure gives both sides a predictable path from the first incident to an orderly exit.

Customers and vendors should read that schedule as carefully as the commercial terms, and revisit it at each renewal. The licensing and technology contracts practice page sets out how such a review is normally scoped.