Monday, 9 a.m. Sales can’t get into the system. Customer orders aren’t coming in. You call the vendor. They say: “We’ve received it and will handle it as soon as possible.” At 3 p.m. the system still doesn’t work. You call again. Same line: “The engineer is working on it.” You dig out the original maintenance contract. It says: “Party B shall assist in resolving the issue as soon as possible upon receiving notice.” How soon is as soon as possible? The contract doesn’t say.
I’m Johnny Yang, founder of Brightstream Technology in Taiwan. In seven years I’ve handled more than 252 projects across 32+ industries, and we deliver over NT$20,000,000 in custom-built systems a year. What happens when the system breaks after go-live is the thing every maintenance contract should spell out most clearly, and the thing it most often leaves vague.
An SLA (Service Level Agreement), in plain terms, is an agreement that turns “how long until a broken system gets fixed” into numbers. An SLA that actually protects you needs at least five things: how severity is classified and who decides; response time and resolution time written separately; when the clock starts and whether holidays count; whether a temporary workaround counts as fixed; and what happens when the targets are missed. A number like 99.9% uptime looks professional, but for a custom-built system you use every day, severity levels plus resolution deadlines are more useful than an uptime percentage. “As soon as possible” without a number is, in a contract, no commitment at all.
What is an SLA? In one line: replace “as soon as possible” with a number
SLA sounds technical. The idea is simple. You order food delivery and the app says it will arrive in about 30 minutes. You send a parcel and the courier says next-day delivery. These are service level commitments: the people providing the service agree to do something within a set time.
A system SLA is the same. It answers three questions: when something goes wrong, how soon will someone respond? How soon will the problem be fixed? And what happens if they can’t do it in time?
A maintenance contract without an SLA is like a courier with no agreed delivery time. The package arrives eventually. When depends on their mood, how busy they are, and whether you’re a big customer. Most days it doesn’t matter. When you’re actually in a hurry, it hurts.
The flip side: an SLA also protects vendors who want to do the job properly. With deadlines and severity levels written down, they know which issues mean dropping everything and which can go into next week’s schedule. Not every phone call gets treated as an emergency. When both sides define “fast” the same way, the working relationship lasts.
“Responding” and “fixing” are two different things
This is the most common SLA trap. Plenty of contracts say “response within 2 hours.” The owner reads that, feels reassured, and assumes the system will be back within two hours. In reality, a “response” may just be an email saying “received,” which is a long way from fixed.
These are the terms you will definitely see in an SLA. Here they are in plain language, with what you need to watch for.
| Term | Plain meaning | What the owner should watch for |
|---|---|---|
| Response time | How soon someone starts working on it | “Received” is not a response. Someone has to actually start investigating |
| Resolution time | How soon normal use is restored | This is the number you really care about. It must be written down |
| Workaround | Get the system usable first, fix the root cause later | Specify the deadline for the root-cause fix after the workaround |
| Service hours | Which hours count toward the clock | If only business hours count, a Friday-night failure waits until Monday |
| Uptime | Share of time the system is usable over a period | Ask how it’s measured and whether scheduled maintenance is excluded |
| Severity levels | Different problems get different deadlines | Specify who decides and what happens when there’s a dispute |
Service hours is the one people miss most. Two contracts can both say “fixed within 4 hours.” If only business hours count, a failure at 5 p.m. on Friday may not count as overdue until Monday at noon. If your business runs on weekends too, you have to negotiate this clause.
99.9% uptime sounds impressive? Convert it to minutes first
Many vendors put “99.9% system uptime” in their proposals. The more nines, the more professional it looks. Your instinct is right: higher uptime really is better. But first convert it into a unit you can feel.
A 30-day month has 43,200 minutes. 99.9% uptime means the system can be down up to about 43 minutes a month. 99.5% is 216 minutes, roughly 3.6 hours. 99% is 432 minutes, roughly 7.2 hours. This is just arithmetic. You can check it on a calculator.
The real problem is that uptime is an average. 40 minutes of downtime in a month could be a few small interruptions spread across the middle of the night, and you’d never notice. Or it could be 40 minutes on the afternoon of month-end closing, with the whole finance department stuck. Same uptime number. Completely different damage to you.
You also need to ask: how is uptime measured? Who measures it? Is scheduled maintenance excluded? If it is, the vendor can file a lot of downtime under “scheduled maintenance,” and of course the number looks good.
So my view: for large cloud services, uptime is a reasonable metric. For the custom-built systems small and mid-sized businesses use every day, instead of arguing over a percentage, write down severity levels and resolution deadlines clearly. What you care about isn’t the average minutes of downtime per month. It’s how fast things come back the one time it breaks.
How to classify severity? One table is enough
The core of an SLA is the severity levels. A system that won’t open at all and a report with misaligned columns cannot be handled on the same deadline. There is only one principle for classifying: judge by the impact on operations, not by how technically hard the fix is.
| Level | How to judge | Common examples | Handling principle |
|---|---|---|---|
| Level 1: Down | Core operations completely stopped, no workaround | System won’t open, can’t issue orders or ship, data errors keep spreading | Shortest deadline, handled around the clock |
| Level 2: Severe | Some functions broken; a workaround exists but is painful | One type of document can’t be issued, an integration is down | Second-shortest deadline; workaround first, then root-cause fix |
| Level 3: Normal | Doesn’t block operations, but inconvenient to use | Report formatting is off, a query has slowed down | Goes into routine handling |
| Level 4: Change request | Nothing is broken; you want it changed | Add a field, change a workflow, new report | Not covered by the SLA; goes under maintenance scope or separate development |
Level 4 matters most. A lot of SLA disputes come from treating “I want it changed” as “it’s broken.” The owner thinks the report should have one more column and calls to say the system has a problem. The vendor says it’s not a problem, it’s a new requirement. Each side thinks the other is being unreasonable. Write this level down explicitly and both sides save trouble.
As for who decides the level, I recommend writing it like this: the party reporting the issue assigns the level first based on the table. If the two sides disagree, handle it at the higher level first and review afterward. That way nobody wastes time arguing about the level while the system is down.
For Brightstream’s own maintenance, our commitment is: critical issues patched within 24 hours of being reported, high-risk issues handled within 72 hours. Both deadlines are written into our maintenance terms, not just said out loud. Your vendor’s deadlines don’t have to match ours. But there have to be numbers.
How to write the SLA clauses in your contract, one by one
The items below are what the SLA section of a maintenance contract should contain. Hold them up against the contract you have now. Whatever is missing, add it.
- Severity definitions: Write them as a table like the one above, with examples, and state who decides and what happens in a dispute.
- Reporting channels: Which channels count as an official report: phone, form, LINE, or email. Whether a verbal report needs written follow-up.
- Clock start: The clock starts the moment the report is made, not when the engineer sees the message.
- Service hours: For each level, whether the clock runs 24/7 or only during business hours.
- Response and resolution deadlines: Two numbers for each level: response time and resolution time.
- Workaround rules: Whether restoring use first counts as meeting the target, how long the root-cause fix can take, and whether a written explanation is required.
- Exclusions: Which situations fall outside the SLA, such as problems caused by the client’s own modifications, outages of third-party services themselves, or force majeure. Exclusions must be specific. No catch-all lines like “other factors beyond Party B’s control.”
- Handling missed targets: What happens when they don’t deliver. It can be a credit against the service fee, or escalation to a higher level. Both sides agree on the ratio and method, but it has to be written down.
- Records and reports: Every incident gets a ticket number, a timeline, and a resolution note, compiled into a summary monthly or quarterly.
Items 7 and 8 are the ones most often left out. Without exclusions, both sides end up fighting over “is this your responsibility or not.” Without handling for missed targets, the SLA is just a wish. For the other clauses a maintenance contract needs, such as scope, source code, and handover, check the 12 items in What a system maintenance contract should include.
On the day it breaks, your side needs three things ready
An SLA isn’t only a requirement for the vendor. It’s a requirement for your own company too. Many incidents drag on not because the vendor is slow, but because nobody inside the company knows how to report it, and when they do, they can’t explain it clearly.
First, name a reporting contact. One or two people in the company are responsible for reporting. Everyone else who hits a problem goes to them first. Don’t have ten people calling the vendor separately, each telling a different version. The contact person needs to know the severity table and be able to decide on the spot which level it is.
Second, when you report, state four things clearly: when it started, which function, how many people or orders are affected, and what message appears on the screen. Attach a screenshot if you can. Get those four right and the vendor’s response time goes straight into fixing the problem instead of back-and-forth questions.
Third, decide in advance how you’ll get through downtime. During the hours the system is down, how do you take orders, how do you ship? You need a stopgap, for example recording everything on paper or in a fixed-format form, then entering it once the system is back. Make sure the relevant people know this stopgap ahead of time. Don’t figure it out in the middle of the incident.
After the incident is resolved, ask the vendor for a short write-up: what caused it, how it was fixed, how they’ll prevent it from happening again. If the same problem happens a second time, bring it up for review instead of treating it as a new incident every time.
However well the SLA is written, it’s useless if they can’t deliver
That’s how to write it. Now something very practical: an SLA is written on paper. Whether it can be met depends on whether the other side actually has what it takes to back the commitment.
You can tell whether it’s real from three places.
First, ask who picks up when something breaks. If only one person on their team understands your system, and that person is sick, abroad, or busy with another client, it doesn’t matter how short the SLA deadlines are. Ask whether there is a second person who can take over, and whether the system documentation is good enough for that second person to understand it.
Second, ask how they know the system is down. A good maintenance provider has monitoring and is often already working on the problem before you notice. If they only find out when you call, their resolution times will naturally be longer.
Third, ask what they need from you. Server accounts, error screenshots, steps to reproduce: some prerequisites depend on your side cooperating. Agree on these in advance so neither side is waiting on the other when something breaks.
This is also why, when owners weigh hiring their own engineer against signing a maintenance contract, the real comparison is “who can actually back an SLA.” A setup that depends on one engineer has a gap whenever that person takes leave or quits. For how to run those numbers, see Hire your own engineer or sign a maintenance plan. I broke down how maintenance fees themselves should be calculated in What a reasonable system maintenance fee looks like. Brightstream’s maintenance starts at NT$20,000 a month, with the quotation based on system size. During the maintenance period, adjustments to interfaces, fields, and report layouts within the written feature list carry no extra charge. That is also what lets us write the severity levels clearly: what counts as broken and what counts as an adjustment is settled when the contract is signed.
FAQ
What’s the difference between an SLA and a warranty?
A warranty means that for a period after delivery, problems where the system fails to do what it was supposed to do get fixed for free. An SLA means that when something goes wrong, it has to be handled within a set time. A warranty answers “do we pay for it.” An SLA answers “how fast.” Both can exist at the same time, and they’re best written separately in the contract.
Do small and mid-sized businesses need an SLA, or only big companies?
If a day of downtime would affect shipping, collecting payment, or serving customers, you need one. An SLA doesn’t have to be complicated. A severity table plus response and resolution deadlines for each level is already far better than “as soon as possible.”
If the vendor misses the SLA, can I demand compensation?
It depends on the contract. If the contract specifies how missed targets are handled, such as a credit against the service fee, you can claim it under the contract. If it doesn’t, you’re usually back to an ordinary breach-of-contract dispute, which drags on. So the point is to write the handling of missed targets in when you sign. For other questions to ask before signing, see 12 questions to ask before signing an ERP contract.
Are shorter SLA deadlines always better?
Not necessarily. The shorter the deadline, the more staff and monitoring the vendor has to commit, and the higher the cost. The sensible approach is to tier by impact: Level 1 problems that actually stop operations get short deadlines, problems that don’t block work go into routine handling. Spend the money where you actually care.
“As soon as possible” isn’t a commitment. Numbers are
In the end, an SLA isn’t a technical appendix to a legal document. It’s you and your maintenance provider agreeing in advance on “who does what, and how fast, when something breaks.” Write the severity levels clearly, write response and resolution separately, spell out the clock and the exceptions, and on the day it breaks there’s nothing to argue about. You just follow it.
If your maintenance contract only says “as soon as possible,” or you’re not even sure who to call when the system goes down, start by looking at how system maintenance and takeover is set up, then go back and check which clauses your own contract is missing.
