Post

Software disputes are a poor fit for a generalist forum. The evidence sits in monitoring dashboards, incident tickets and release notes, and a judge without sector familiarity needs months to absorb it. This is why technology and arbitration work well together. This article explains how a SaaS service failure claim is actually proved, where standard contracts leave the customer exposed, and what to preserve before escalating.

Key Takeaways

• A SaaS claim stands or falls on the service schedule. Availability targets, exclusions and measurement windows decide whether a failure is a breach at all.
• Service credits are frequently drafted as the customer's only remedy, and they are usually far smaller than the operational loss suffered.
• Preserve monitoring data, tickets and vendor status pages before escalating. Once a contract terminates, access to the vendor's own records often disappears.

Why SaaS Disputes Are Harder to Prove Than They Look

A customer whose business stopped for two days feels the failure clearly. Converting that into a provable breach is another matter. The first question is what the vendor actually promised, and the answer is rarely in the main agreement. It sits in a service schedule or an online service level page that the contract incorporates by reference and that the vendor can amend.

The second question is how availability is defined. A ninety nine point nine per cent commitment measured monthly permits around forty three minutes of downtime. The same figure measured annually permits nearly nine hours. Most schedules also exclude scheduled maintenance, force majeure, third party network failures and any issue attributed to the customer's own configuration. After the exclusions are applied, a visible outage sometimes produces no contractual breach at all.

The third question is who measures. Where the contract makes the vendor's own monitoring the definitive record, the customer is arguing against data it does not control. Our note on software licensing and SaaS agreements deals with these provisions at the contracting stage, which is where they are best fixed.

Service Levels, Credits and the Limits of the Remedy

Most SaaS contracts respond to a service failure with a credit against future fees. The credit is typically a small percentage of the monthly charge, and it is very often drafted as the customer's sole and exclusive remedy for that failure.

The commercial mismatch is obvious once stated. A logistics business that cannot dispatch for two days does not lose the value of two days of subscription. It loses orders, incurs penalties with its own customers and spends heavily on manual workarounds. A clause capping recovery at a service credit transfers all of that to the customer. Credits are also usually issued against future invoices rather than paid out, so a customer that leaves the platform after a serious failure may never receive the benefit at all.

Two further provisions compound it. Liability caps commonly limit total recovery to the fees paid over the preceding twelve months. Exclusion clauses typically remove indirect and consequential loss, which is where most real damage sits. A tribunal will generally enforce these terms between commercial parties. The time to address them is during negotiation, and our note on when a SaaS licence needs legal vetting sets out what to look for.

Data, Exit and What Happens When Access Stops

The most damaging moment in a SaaS dispute is rarely the outage. It is the point at which the customer loses access to its own data. Vendors frequently reserve a right to suspend service for non payment, and a customer who withholds fees because of a service failure can trigger exactly that right.

A well drafted agreement addresses this with a data export commitment stating the format, the window after termination during which data remains retrievable, and the assistance the vendor will provide. Where the contract is silent, the customer may find that its records are in a proprietary structure it cannot use even if a copy is released.

This is also where interim relief becomes relevant. An application to restrain suspension or to compel release of data is a realistic use of the urgent remedies available before and during an arbitration, because the harm is immediate and difficult to repair with money afterwards. Our case study on SaaS licence management for a fintech client illustrates how these obligations are structured.

Customers can reduce the exposure without any contractual change by taking regular exports in a neutral format as a matter of routine. A monthly extract held outside the vendor's environment converts an existential problem into an inconvenience. Businesses that depend on a single platform for order processing, billing or customer records should treat this as basic operational hygiene rather than as dispute preparation, because the same practice protects against vendor insolvency and acquisition as well as disagreement.

Choosing a Tribunal That Can Read the Evidence

The central advantage of arbitration in technology disputes is the ability to appoint someone who understands the material. A tribunal familiar with software delivery can read an incident postmortem, follow a discussion about database contention and assess whether an acceptance test was genuinely met, without the parties funding weeks of basic explanation.

That advantage depends on the clause. An appointment mechanism can require sector experience, or name an institution whose panel includes technology practitioners. Left unspecified, the parties may end up with a distinguished generalist and a longer, more expensive reference.

Sole arbitrator or panel is the related question. Most SaaS disputes are mid value and suit a sole arbitrator, who is faster to appoint and cheaper to run. A panel of three is justified where the amounts are large or the technical issues genuinely contested. The difference in scheduling alone can add months to the timetable, because three diaries are harder to align than one.

Document production deserves a word too. Technology disputes generate enormous volumes of electronic material, and an unlimited disclosure exercise can cost more than the claim. The tribunal can be asked at the first procedural hearing to set a narrow, targeted regime: specific custodians, specific date ranges, specific systems. Agreeing that early is one of the few reliable ways to keep a technology reference proportionate.

Preserving Evidence Before You Escalate

Preservation should begin the moment a dispute looks likely, and certainly before any termination notice is served. Export monitoring data and uptime reports covering the relevant period. Capture the vendor's public status page, which is frequently edited or removed once an incident closes. Preserve the full ticket history, including timestamps showing when each issue was reported and when the vendor responded.

Equally important is the version of the contract that applied. Where service levels live on a web page the vendor controls, capture the version in force when the failure occurred, with its date. Vendors update these pages, and a customer arguing about a commitment that no longer appears anywhere is in a weak position. Archived captures with visible timestamps are far more persuasive than a screenshot pasted into a document, because the date can be independently checked.

Internal records complete the picture. Notes of what the business could not do, the manual workarounds used and their cost, and any communications with the customer's own clients about the disruption all support the loss claim. Our case study on technology liability in Ernakulam IT contracts shows how these threads combine, and the Ministry of Electronics and Information Technology publishes the wider regulatory framework that increasingly touches these agreements.

Conclusion

Technology and arbitration suit each other because the tribunal can be chosen to understand the evidence. What decides a SaaS failure claim, though, is the service schedule and the records rather than the forum. Customers who negotiate meaningful remedies, secure a data exit commitment and preserve monitoring evidence early are in a far stronger position than those who rely on the general sense that the service was unacceptable. To see how these disputes are handled in practice, explore our technology dispute case studies.