"4-hour response time" and "99.5% uptime" look serious in the offer. After you sign, it turns out those are promises within 8:00–16:00 on business days, with a penalty of 5% of the monthly fee. And you still have to fight to claim it.
An SLA — Service Level Agreement — is the attachment most SME owners read for the first time only when something breaks. That's exactly the moment when it's too late. A good SLA does not protect you from an outage. It protects you from an outage turning into three days of paralysis and expensive overtime.
A story from our practice. A 30-person furniture maker selling under its own brand signed an agreement with an IT vendor promising "service response within 4 business hours". On Friday at 16:35 their Comarch ERP XL server died. The first response from the vendor came on Monday at 9:15 — because the vendor's working hours were written as 8:00–16:00, business days only. The company lost two days of its planned production cycle. We estimated the cost of overtime and delivery shifts at around 80,000 PLN. The penalty the vendor paid for breaching the SLA: 540 PLN — 5% of the monthly service fee.
The SLA worked exactly as written. The trouble was that nobody on the client side knew how to read it.
Response, resolution, availability — three different things
The most common misunderstanding: the owner reads "response in 4 hours" and pictures the system working again within 4 hours. That's wrong. Response is first contact — a phone call, an email, a ticket accepted. The person on the other end said "yes, I see it, I'm on it". Nothing more.
How long the resolution (restoring the service) takes is, in most standard contracts, not bounded at all. Some contracts say the vendor will "make best efforts" — that's poetry; it means nothing in court. Others say nothing at all. Before you sign, negotiate a separate SLA on time-to-resolve for critical systems. It can be longer than the response time (e.g. 8 or 24 business hours), but it must be written down.
The third thing: monthly availability (e.g. "99.5% uptime"). Easy to accept without doing the math. 99.5% over a month means 3.6 hours of acceptable downtime. 99% means 7.2 hours. For an ERP in a manufacturing company, the difference between 99% and 99.9% is the difference between "a painful situation once every six months" and "expensive paralysis every month".
Service hours — the biggest gotcha
A standard Polish service agreement assumes working hours of 8:00–16:00 on business days. The client reads "4-hour response" and doesn't notice that the clock only ticks during those hours. A breakdown on Friday at 16:30 = first response on Monday before noon. A breakdown on Christmas Eve at 10:00 = response after 1 January.
For most internal processes (accounting, HR), that's acceptable. For production systems, warehouses, e-commerce, and anything that generates revenue outside office hours — it's not. For those systems you need either:
- a 24/7 SLA (more expensive, but it's just a differently written time window),
- an "extended" SLA — e.g. 7:00–22:00, 7 days a week (a cost compromise),
- a dedicated on-call number for critical outages outside service hours.
Each of these costs money. Typically 20 to 60% more than standard. It only matters when the system is down on a Friday night.
What an SLA doesn't cover
Every service contract has a list of exclusions. Read them as: "in these situations, the vendor is not responsible for anything". The classic items:
- Third-party outages — your ISP, power utility, cloud provider. If the ISP cuts the office off for 6 hours, your ERP SLA does not kick in. It pays to have link redundancy (a second ISP or LTE failover).
- Misuse on the client side — an employee changed something in the database, somebody uninstalled a component, somebody opened a phishing attachment. Excluded.
- Acts of God and force majeure — fire, flood, ransomware attack (sometimes!). What helps here is insurance, not the SLA.
- Vendor updates — when Microsoft, Comarch or enova365 ships a patch that breaks something, your service vendor cannot fix it in 4 hours either.
- Hardware outside the contract — if the physical server is your property and the contract covers only the software, a disk failure is not the vendor's problem.
The list of exclusions is not bad in itself. What's bad is the situation in which you read it for the first time during the outage.
Penalties — usually theatre
The standard penalty for an SLA breach is 5% of the monthly service fee, sometimes up to 10–20% in tighter contracts. At a fee of 1,500 PLN/month, that's 75–300 PLN. These amounts are wildly disproportionate to the losses you take from a critical outage. From the vendor's perspective, they're a cheap hedge. From yours, they're symbolic.
What's actually worth negotiating instead of a higher penalty (which won't cover the losses anyway):
- Escalation after the response time is breached — automatic involvement of the service manager, not just the technician.
- A monthly report with the number of tickets, response times and resolution times. Without the report, you will never prove later that the SLA is being breached systematically.
- A termination clause without notice period if the SLA is breached more than X times in 3 consecutive months. That's real leverage — vendors defend against losing a customer much harder than they defend against a 300 PLN penalty.
What to negotiate before you sign
A short list of things to bring up in negotiation, not after the first outage:
- Ticket category — who decides a ticket is "critical" vs "normal". Usually the vendor decides. That's comfortable for the vendor.
- Response time vs resolution time — demand both, even if resolution is longer.
- Time window — for critical systems, at least 7:00–20:00, 7 days a week.
- Contact channels — one phone number, one email address, one portal. Not five different paths, of which three never reply.
- Exclusion list — read it point by point. Cross out the items that don't match your reality.
- Periodic review — a meeting with the vendor every six months to go through the numbers. Without it, the SLA is a dead document.
What next
The SLA is the document that has to work on your company's worst day. Don't read it for the first time on that day. If you have a contract with an IT vendor and you don't remember what it says about service hours or resolution time — that's the signal to pull it out and read it.
If you'd like us to look at your contract with an IT vendor and tell you where the holes are — the first call is free and takes half an hour.
An SLA does not protect you from an outage. It protects you from the outage turning into three days of paralysis and expensive overtime.