A managed IT SLA — what it actually commits to

This distinction decides what the whole document is worth, and it is the one that disappears during a sales conversation. Response time is the deadline by which somebody acknowledges a ticket and starts working on it. Resolution time is the deadline by which the problem stops existing. A response-time commitment is the rule in these documents; a resolution-time commitment is the exception — worth checking whether yours mentions one at all.

There is a good reason for that. Nobody knows in advance whether a failure comes from a dead disk, from an update the vendor shipped overnight, or from an outage at a telecoms operator the IT provider has no influence over. Promising to fix every fault within a set time would mean taking responsibility for other people's systems and for the physics of hardware — so a contract that promises resolution times across the board is either narrowly scoped somewhere you have not read, or it is not serious.

That does not mean nothing can be written about the fix. What a contract can commit to is conduct: continuous work on a critical incident, progress updates at agreed intervals, a workaround offered when the proper repair needs time or a part. It is also worth checking whether the contract defines when a ticket is closed — and whether the provider closes it or the person who raised it does. The second is rarer, and it is worth more than a good many clauses about deadlines.

A response time without severity levels means nothing, because one deadline cannot cover both company-wide email going down and a request for an account for a new intern. Which is why any sensible SLA sorts tickets into levels — two or three, no more. With more levels than that, the choice stops being obvious to somebody who reports a problem once a quarter — and then they reach for the highest one, or pick at random. A model in which everything is critical has no priorities at all.

The split we work with rests on one question: who cannot work because of this.

Every deadline in an SLA runs in some unit of hours, and which unit changes it more than the number does. “A response within 12 hours” and “a response within 12 working hours” look almost identical. For a ticket raised at four on a Friday afternoon, the first expires that same night; the second, on an eight-to-four working day, not until noon on Tuesday. Same number, more than three days apart.

Hence the second question: what hours does the provider actually work. Three different things are easy to confuse — the hours when tickets are accepted, the hours the response clock runs in, and the hours somebody is genuinely working on the problem. A contract can have a round-the-clock reporting channel and still count its deadlines only on working days; that is honest, as long as it is written down rather than assumed.

For a company working Monday to Friday in office hours, a window counted in working hours is usually enough and costs less. For a company that ships goods on Saturday or runs shifts, the same clause is a trap — and that is something to say on the first call rather than after the first weekend. Extending the hours always costs money, because somebody has to be available whether or not anything happens.

Until you see the list, “full IT support for your company” is a name, not a scope. The scope annexe is the document both sides will return to on the day of a dispute, so it deserves closer reading than the confidentiality clauses. A well-written one has two columns: what sits inside the monthly fee and what is billed separately.

In practice, the line between the two is the line between maintenance and projects. Creating accounts, updates, help with everyday problems, backup oversight and access reviews are maintenance — and any plan should say plainly which of them sit inside the fee and which are an extension of the scope. A mail migration, a server replacement, rewiring the network in a new office or rolling out an industry system are projects with their own schedule and their own price. A provider who claims a migration fits inside a helpdesk subscription has either quietly padded the fee or does not intend to do the job properly.

Exclusions are read separately, because that is where the surprises live: hardware out of vendor support, industry software whose vendor has left the market, on-site work beyond the agreed travel area, the cost of licences and parts. An exclusion is not a bad thing in itself — every scope ends somewhere. What is bad is an exclusion you discover on the first invoice for “additional work”.

A deadline nobody measures is not a deadline. If tickets arrive by phone and into a technician's personal mailbox, then six months later nobody can answer a simple question: how many requests came in, how many were answered within the agreed window, and which ones ran over. The reporting clause is therefore not an extra on top of the SLA — it is the mechanism that makes the rest of the document enforceable.

Three things are usually enough: one defined reporting channel, a log carrying the time a ticket arrived and the time of the first reply, and a periodic summary somebody on your side actually reads. A summary is useful when it answers business questions — what happened, what needs your decision, what is planned — and useless when it is a dump from a ticketing system. A report nobody opens is a cost to both sides.

And there is one more thing almost nobody asks about: who owns that history. If the ticket log lives only in the provider's system, it leaves with them on the day you part — and it is knowledge about your company, not about their work. A clause giving you an export of the ticket history on termination costs one sentence and is often worth a great deal more.

The termination clause is the least-read part of the document, and it shapes the real cost of the arrangement more than the rate does. A provider you cannot leave without expensive chaos does not have to try very hard — and usually knows it. A reasonable notice period is therefore not a courtesy; it is a statement that the contract intends to defend itself on quality.

Leaving a managed-IT arrangement is not a single act but a list of things that have to change hands. That list belongs in the contract before anyone needs it.

We work at three levels of scope — IT Essential, IT Business and IT Critical — and with the three severity levels described above. The contractual baseline for ongoing support is a response within three working days for a standard request and within twelve hours for an urgent one. Those are contract terms rather than a best-effort promise. The urgent channel is available continuously, but how much work happens outside business hours depends on the plan and on what we wrote into the SLA.

We do not publish the shorter response windows for the IT Business and IT Critical plans in a table, and that is deliberate. A response window is a commitment to readiness, and readiness depends on the number of users, the hours the company works, whether the environment contains a server everything hangs off, and how far somebody has to drive when nothing can be done remotely. A number put on a web page before that conversation would be true for one company and false for ten others — a slogan rather than a commitment. We agree it after the audit and write it into the SLA, where it has effect.

For the same reason we do not commit to a resolution time across the board. We commit to responding, to giving critical incidents precedence, to reporting progress and to finding a workaround when the repair needs time or a part. Where a company needs a hard recovery deadline for one specific system, we are willing to discuss it and write it separately — that is the only way such a deadline is deliverable. The rest is held together by one reporting channel and a log, a monthly summary on IT Business and formal reporting on IT Critical.

The notice period is agreed before we start, and we propose one that does not make leaving a punishment. Documentation of the environment is written from the first weeks and it is yours; accounts, domains and licences are registered to your company. The contract should be the reason you stay, not the reason you cannot go.