What Belongs in an ERP Vendor SLA: Uptime and Penalties
A distributor's cloud ERP system went down for 14 hours during a peak shipping week. The vendor's SLA triggered a service credit of $400 against a $12,000 monthly subscription fee. The outage itself cost the distributor an estimated $85,000 in missed and delayed shipments. Both numbers were technically correct under the contract the distributor had signed — the SLA had done exactly what it was written to do, which was protect the vendor from anything beyond a token refund, not protect the customer from the actual cost of downtime.
What uptime percentages actually mean, in hours
Vendors advertise uptime commitments as percentages, which sound reassuring and are easy to gloss over without doing the arithmetic. The gap between tiers is larger than it looks:
| Uptime commitment | Allowed downtime per year |
|---|---|
| 99.5% | 43.8 hours (about 1.8 days) |
| 99.9% | 8.76 hours |
| 99.95% | 4.38 hours |
| 99.99% | 52.6 minutes |
A vendor offering 99.5% as a "standard" tier and 99.9% or higher only on a premium plan is effectively selling the right to five times less downtime for a price difference that's usually much smaller than five times the base fee. Before accepting a vendor's default tier, it's worth running your own numbers through a downtime cost calculator — for a business where an hour of downtime costs $6,000, the difference between 43.8 and 8.76 allowed hours a year is roughly $210,000 in potential exposure, which usually justifies paying more for the higher tier.
Support response tiers by severity
Uptime is only half the picture — how fast the vendor actually responds when something breaks matters just as much. A reasonable SLA defines response time commitments by severity level, not a single blanket promise:
- Severity 1 (system down, no workaround): typically a 1-hour response commitment, often with 24/7 coverage
- Severity 2 (major feature broken, workaround exists): typically 4 hours, business hours
- Severity 3 (minor issue, cosmetic or low-impact): typically next business day
"Response" also needs a precise definition in the contract — it usually means acknowledgment that a support ticket has been received and assigned, not resolution. Vendors sometimes let that ambiguity slide in sales conversations and then hold strictly to the narrower definition when a real incident happens.
Penalty and service credit clauses, and why they rarely cover real losses
Almost every cloud ERP SLA caps its remedy at a service credit — a percentage discount off the next billing cycle — rather than compensation for actual business impact. That's a standard and largely unavoidable structure across the industry; vendors aren't going to accept open-ended liability for a customer's downstream losses. What is negotiable is the credit schedule itself: escalating credits for repeated breaches within a rolling period, and in some contracts, a right to terminate without penalty if the vendor misses its uptime commitment more than a set number of times in a year. A single 14-hour outage getting a flat $400 credit is a weak deal; a contract where a third breach in twelve months triggers a much larger credit and an exit right is a meaningfully different negotiating position.
On-premise vs. cloud SLA differences
The nature of the SLA changes depending on deployment model. With an on-premise system, the company owns the infrastructure and therefore owns uptime — the vendor's SLA typically only covers support response times, not the system staying online, since that's a function of the customer's own servers and IT staff. With cloud ERP, the vendor owns the infrastructure and the uptime commitment is real and central to the agreement. It's worth checking that assumption explicitly, since "SLA" gets used loosely enough that a customer moving from on-premise to cloud sometimes assumes uptime coverage that was never actually part of the on-premise contract to begin with — running the comparison through a cloud vs. on-premise calculator makes that tradeoff concrete rather than assumed.
What to negotiate before signing
- A precise definition of "downtime" — does partial degradation (the system is up but slow) count, or only a full outage?
- Whether scheduled maintenance windows are excluded from the uptime calculation, and how much advance notice they require
- An escalating credit schedule for repeated breaches, not a flat percentage regardless of frequency
- Data export rights and format if the relationship ends — can you get your data out in a usable form, and how long does the vendor retain it after termination
- Explicit response time definitions tied to severity levels, with severity criteria spelled out rather than left to the vendor's discretion
None of these clauses matter until the day something breaks, which is exactly why they need to be settled before the contract is signed, not renegotiated in the middle of an outage when the vendor holds all the leverage.
Data security and breach notification terms
A complete ERP SLA covers more than uptime and support response — it should specify where customer data is physically hosted (a data residency question that matters for regulated industries), what encryption standards apply to data at rest and in transit, and how quickly the vendor is contractually obligated to notify the customer of a security incident. A common and reasonable benchmark is notification within 72 hours of confirming a breach, mirroring the standard several data protection regulations use, though the specific number should be spelled out in the contract rather than left to whatever the vendor considers "prompt" after the fact.
Support channels and the escalation ladder
Response-time commitments only mean something if there's a clear path to actually reach someone when a ticket sits unanswered past its committed window. A well-structured SLA names the support channels available (ticket portal, phone line, dedicated account representative for larger accounts) and defines an escalation ladder — who gets contacted, and how quickly, if a Severity 1 ticket blows past its 1-hour response commitment. Without a named escalation path, a customer's only real recourse when support goes quiet is to keep calling the same queue that already missed its commitment once.
Checking a vendor's actual track record
An SLA describes a promise; a vendor's public status page and historical incident reports describe what actually happened. Before signing, it's worth asking a prospective vendor for their uptime history over the past 12-24 months, or checking their public status page's incident archive directly, rather than relying solely on the percentage printed in the sales contract. A vendor that has hit 99.95% uptime consistently for two years is a very different risk than one offering the same contractual number for the first time with no track record to back it up.
When the outage isn't the ERP vendor's fault
Modern ERP deployments rarely stand alone — a payment processor, an EDI network, a tax calculation service, or a third-party e-commerce integration often sits in the transaction path, and a single ERP vendor's SLA typically only covers their own platform, not the dependencies plugged into it. A distributor that can't process orders because its tax calculation integration is down has a real business problem even though the core ERP is technically up and within its SLA. It's worth mapping which third-party services a company's actual workflow depends on and checking whether those providers carry SLAs of their own, rather than assuming the ERP vendor's uptime number covers the full chain of systems a transaction actually has to pass through.