In summary<\/p>\n
- \n
- Response time and resolution time are two different things.<\/strong> Many contracts only guarantee the first \u2014 and it is the second that matters to the business.<\/li>\n
- An SLA without defined consequences is merely an intention<\/strong>, not a compromise.<\/li>\n
- The severity classification is the most important clause<\/strong> and the one that is least often read: it is this one that determines which deadline applies.<\/li>\n
- Before negotiating deadlines, work out how much an hour of downtime costs you<\/strong>. Without that figure, you\u2019re buying blind.<\/li>\n<\/ul>\n<\/div>\n
\nIn this article<\/p>\n
- \n
- What is an SLA?<\/a><\/li>\n
- A response is not a solution<\/a><\/li>\n
- The severity classification<\/a><\/li>\n
- Availability: the new ones<\/a><\/li>\n
- Consequences and exclusions<\/a><\/li>\n
- How to negotiate your<\/a><\/li>\n<\/ol>\n<\/div>\n
Almost all IT support contracts include an SLA. Hardly any customers read it carefully before signing \u2014 and when they do read it, it is usually after a system outage, when they are trying to find out what they were entitled to demand.<\/p>\n
This article explains what a service level agreement should contain, where the pitfalls in the wording lie, and what questions to ask before signing.<\/p>\n
What is an SLA?<\/h2>\n
SLA \u2014 Service Level Agreement<\/em>, or service level agreement \u2014 is the part of the contract that sets out what constitutes an acceptable service, in figures<\/strong>, and what happens when that threshold is not met.<\/p>\n
That is what distinguishes \u201cwe provide IT support\u201d from a verifiable commitment. Without an SLA, the quality of the service is a matter of opinion, and discussions always end up in the same place: the customer thinks it took too long, the supplier thinks it was reasonable, and there is no way to break the deadlock.<\/p>\n
![\"The](\"https:\/\/www.helpdesk-lisboa.pt\/wp-content\/uploads\/2026\/08\/dataroad-ciclo-suporte-gerido-1024x327.png\")
A proper SLA sets out the full cycle: monitoring, detection, resolution and reporting \u2014 with deadlines for each stage.<\/figcaption><\/figure>\n A response is not a solution<\/h2>\n
This is the most important distinction of all, and the one that most contracts exploit to the supplier\u2019s advantage.<\/p>\n
Response time<\/strong> It is the time it takes for someone to acknowledge receipt of the request and start processing it. Resolution time<\/strong> is how long it takes for the problem to be resolved.<\/p>\n
A contract that guarantees a \u201cresponse within one hour\u201d and nothing else technically allows a server to be down for three days without breaching the SLA \u2014 provided that someone responded within the first hour.<\/p>\n
\nThe question to ask before signing:<\/strong> \u201cApart from the response time, what resolution time is contractually guaranteed, and for what types of incident?\u201d If the answer is vague, so is the commitment.<\/p>\n<\/div>\n
In practice, reputable suppliers commit to resolution times for critical incidents and work with targets \u2014 not guarantees \u2014 for the rest. That is reasonable and honest. What is not reasonable is for the contract to fail to distinguish between the two concepts at all.<\/p>\n
The severity classification<\/h2>\n
All SLAs define incident categories with different response times. This is where, in practice, it is decided which service you will receive \u2014 and it is the section that almost nobody reads.<\/p>\n
The standard structure usually has three or four levels, typically:<\/p>\n
- \n
- Critic<\/strong> \u2014 the company has come to a standstill or an essential service is unavailable to everyone.<\/li>\n
- High<\/strong> \u2014 a significant impact, with many users affected or having no alternative means of working.<\/li>\n
- Medium<\/strong> \u2014 a localised impact, with a contoured shape.<\/li>\n
- Bass<\/strong> \u2014 routine enquiries, queries, minor changes.<\/li>\n<\/ul>\n
The crucial issue is not the list. It is who grades<\/strong>. If the supplier is the one to decide unilaterally on the severity of each incident, all tight deadlines become purely theoretical \u2014 all it takes is to classify as \u2018medium\u2019 what the customer considers \u2018critical\u2019.<\/p>\n
A balanced contract sets out objective assessment criteria and an escalation mechanism for when the parties disagree.<\/p>\n
Availability: the new ones<\/h2>\n
Availability commitments are expressed as a percentage, and the difference between similar figures is greater than one might intuitively expect:<\/p>\n
- \n
- 99%<\/strong> \u2014 around 7 hours of downtime per month<\/li>\n
- 99,5%<\/strong> \u2014 around 3.5 hours a month<\/li>\n
- 99,9%<\/strong> \u2014 around 43 minutes a month<\/li>\n
- 99,99%<\/strong> \u2014 about 4 minutes a month<\/li>\n<\/ul>\n
There is a tenfold difference in the tolerated downtime between 99% and 99.9% \u2014 and a substantial difference in cost, because each additional nine requires redundancy that someone has to pay for.<\/p>\n
Also worth a read such as<\/em> The following are taken into account: the period over which it is measured, whether scheduled maintenance windows are included, and who carries out the measurement. A 99.9% service level agreement, measured annually, allows for a continuous eight-hour outage without constituting a formal breach.<\/p>\n
Consequences and exclusions<\/h2>\n
An SLA without clearly defined consequences is not a commitment \u2014 it is a declaration of good intentions.<\/p>\n
The usual consequences are credits against the next month\u2019s instalment, scaled according to the severity of the breach, and the right to terminate the contract without penalty in the event of repeated breaches. Neither of these compensates for the actual loss caused by a stoppage, but both provide a tangible incentive for compliance.<\/p>\n
Equally important is the list of exclusions<\/strong> \u2014 which does not count as a supplier\u2019s fault. Faults attributable to the telecoms operator, hardware faults not covered by the maintenance contract, changes made by the customer without notice, and force majeure. Reasonable exclusions are normal; the key is that they should be specific rather than so broad as to render the agreement meaningless.<\/p>\n
How to negotiate your<\/h2>\n
Don\u2019t start with the deadlines. Start with this calculation: How much does an hour of downtime cost your company?<\/strong> Add to that unproductive wages, lost turnover and the cost of catching up.<\/p>\n
With that figure, the conversation changes. It\u2019s no longer a case of \u201cwe want the issue resolved within two hours\u201d; it becomes an economic decision: if one hour of downtime costs X, it makes sense to pay an extra Y per month to reduce the expected downtime.<\/p>\n
Four questions that make it worth reading the whole contract:<\/p>\n
- \n
- What times those were resolution<\/em> Are they guaranteed, and for what levels of severity?<\/li>\n
- Who assesses the severity, and how can that assessment be challenged?<\/li>\n
- What cover is available outside working hours, and who actually answers the phone?<\/li>\n
- What happens, in practical terms, when the SLA is not met?<\/li>\n<\/ul>\n
And here\u2019s a simple sign of a good supplier: anyone who offers to report on SLA compliance on a monthly basis, without being asked, is confident in what they\u2019ve signed up to.<\/p>\n
DataRoad works with contracted and reported service levels<\/a>, tailored to each client\u2019s specific needs, within the managed IT services<\/a>.<\/p>\n
\nA chat before making a decision<\/p>\n
Whether you\u2019re tackling a specific problem, planning a move or simply looking for a second opinion, we always start in the same way: by understanding your situation before making any suggestions. No obligation, no jargon and no catalogues.<\/p>\n
- 99,5%<\/strong> \u2014 around 3.5 hours a month<\/li>\n
- High<\/strong> \u2014 a significant impact, with many users affected or having no alternative means of working.<\/li>\n
- A response is not a solution<\/a><\/li>\n
- An SLA without defined consequences is merely an intention<\/strong>, not a compromise.<\/li>\n