The short answer: An IT management SLA must clearly distinguish between request receipt, response, work commencement, service restoration and final resolution. It should also define priorities, support hours, escalation procedures, exclusions, responsibility for third parties, measurement methods and the consequences of non-compliance.
An SLA is not a promise that a technician will respond as soon as possible
An SLA is the measurable part of a service agreement. It should specify which services it covers, when the clock starts, who receives an incident, how its priority is determined and what happens if the agreed commitment is not met.
The statement „we prioritise critical requests" is not enough. It does not define what constitutes a critical request, how quickly someone will assess it or whether the provider guarantees the commencement of work or merely an initial response.
A single incident often affects several interdependent services. User sign-in may depend on Microsoft Entra ID, email on Exchange Online, remote work on the firewall and VPN, shared files on Synology DSM or QNAP QTS, and recovery on a separate backup repository. An SLA should therefore cover more than the technician’s response speed. It must also define their role when the fault lies with the internet connection, a cloud service, a licence or hardware.
Receipt, response and resolution are not the same
The agreement should contain separate definitions for at least five points in time.
- Request receipt: The help desk has created a ticket and recorded the delivery time. An automated acknowledgement confirms that the system received the message.
- Response: The responsible person has assessed the request, verified its impact, assigned a priority and communicated the next steps. If an automated message alone counts as a response, the agreement must state this unambiguously.
- Commencement of work: A technician has actually begun diagnosing the issue, mitigating its impact or restoring the service. A notice saying „we are aware of the problem" does not necessarily mean that work has started.
- Service restoration: Users can work again, possibly through a temporary workaround.
- Resolution: The cause has been eliminated, the permanent fix has been verified and the ticket has been closed.
A provider may guarantee a response time while stating only target times for restoration or resolution. This is understandable when, for example, the provider is waiting for a cloud service to be repaired or a replacement part to be delivered. However, the proposal must clearly distinguish between a binding commitment, an operational target and a non-binding estimate.
Priority is determined by the operational impact
A P1 to P4 label alone guarantees nothing. Each level must describe the impact, scope, security risk and availability of a workaround.
| Priority | Practical definition | Typical example |
|---|---|---|
| P1 – critical | A key operation has stopped, the incident is spreading or no viable workaround is available | unavailable core information system, connectivity outage affecting an entire branch, ongoing security incident |
| P2 – high | A significant group of users cannot work or is severely restricted | Microsoft 365 sign-in failure affecting an entire department, unavailable VPN with no alternative connection method |
| P3 – standard | The impact is limited or a viable workaround is available | problem with one computer, slow application, non-functional office printer |
| P4 – request | This is not a fault but a planned change | creating an account, installing an application, preparing a device for a new employee |
The agreement should also specify who assigns the priority, who may change it and how a customer’s disagreement is handled. A broken printer used by one employee will not usually bring the business to a halt. The same fault at the only workstation used to print shipping labels could interrupt dispatch operations and warrant a higher priority.
Without this rule, the customer may classify every request as critical, while the provider may arbitrarily downgrade serious incidents.
Support hours determine when the clock runs
The phrase „response within two hours" is incomplete unless it specifies whether this means two consecutive hours or two hours within the support window.
Consider this example: support operates on working days from 8:00 a.m. to 5:00 p.m., and the customer reports an incident at 4:30 p.m. on Friday. Half an hour of the two-hour response period elapses on Friday, and the remaining time begins to run on Monday morning. The response deadline is therefore 9:30 a.m. on Monday, unless a public holiday or separately contracted on-call service affects the calculation.
The SLA must therefore define:
- working days, hours and time zone;
- how public holidays are handled;
- which priorities are supported outside normal business hours;
- how on-call support is activated;
- telephone and escalation contacts;
- update intervals during a critical incident.
An ordinary email sent to the service mailbox may not activate on-call support. P1 incidents therefore often require a dedicated telephone number or an option in the customer portal.
The scope must reflect the actual environment
A flat-rate service described merely as „IT management" is difficult to assess. An annex to the agreement should list all managed users, devices, locations and services.
For a cloud environment, simply stating Microsoft 365 is not enough. The scope might include Entra ID, Exchange Online, SharePoint, OneDrive, Teams, licence management and multi-factor authentication. For on-premises infrastructure, the agreement should distinguish between managing the firewall, Wi-Fi, VPN, servers, workstations, Synology DSM or QNAP QTS, and the backup system.
The included activities should be described just as precisely:
- help desk and remote support;
- monitoring and alert assessment;
- operating system and managed application updates;
- user account and permission management;
- backup job monitoring;
- recovery testing;
- call-outs and on-site work;
- maintaining documentation and access records.
Migrations, major project changes, licences, hardware or forensic investigation of a security incident may be billed separately. However, the agreement must state where the flat-rate service ends, how out-of-scope work is approved and which price list applies.
If you need the scope tailored to your actual number of users, devices and branches, we will design your IT management service around your real environment, rather than a generic package.
An exclusion does not relieve the provider of its communication duties
An SLA may contain exclusions for situations that the provider does not directly control. These may include an internet service provider outage, cloud platform failure, intervention by another service company, waiting for a replacement part or the absence of access required for diagnosis.
A broad phrase such as „circumstances beyond the provider’s control" is risky. Without further rules, it could cover almost any complex incident.
For every third-party dependency, the agreement should clarify:
- who opens a service request with the network operator, manufacturer or distributor;
- who supplies logs, serial numbers and other technical information;
- whether the SLA clock is paused;
- from which recorded point in time the pause is calculated;
- what conditions must be met before the clock restarts;
- how often the customer receives an update;
- whether the provider seeks a temporary workaround.
An IT administrator cannot repair a network operator’s infrastructure or Microsoft’s systems. They can, however, verify whether the problem actually lies within the company network, open a case with the operator, provide diagnostic data and coordinate the next steps. This responsibility should remain in the agreement even when the third party’s repair time is excluded from the SLA.
The emergency checklist for a business internet outage also describes a practical procedure for a complete loss of connectivity.
Service availability is not the same as support availability
24/7 support describes when an incident can be reported and when a team is available to begin handling it. Percentage availability, by contrast, indicates the proportion of the monitored period during which a particular service was operational according to the agreed measurement method.
The agreement must define:
- which service the availability figure covers;
- where service functionality is measured from;
- the length of the assessment period;
- what counts as unavailability;
- whether announced maintenance is excluded;
- how partial outages are treated;
- who may verify the result.
For backups, you need RPO and RTO in addition to support availability. RPO defines the maximum acceptable age of the data to which the organisation can revert after an incident. RTO defines the target time for restoring the service or data. A fast help desk response alone does not indicate how recent the recovered data will be or when the business can start using it.
The agreed recovery process must be tested in practice. A green backup job status alone does not confirm that a database can be opened, a virtual server mounted or a requested folder restored. For more information, see the guide to backup recovery testing and its documentation.
Clock suspension must follow clear rules
The provider may need additional information, system access or a decision from the customer. The SLA may allow the clock to be suspended in such cases, but simply changing the ticket status to „waiting" should not be sufficient.
Every suspension should record:
- exactly what is missing;
- who is responsible for the next step;
- when the request for cooperation was sent;
- when the customer was notified;
- when the requested cooperation was provided;
- when the clock resumed.
A vague request such as „send more information" is not an adequate basis for suspending the clock for several days. The technician should specify whether they need, for example, the time of the error, the user’s name, a screenshot of the message, remote access or approval for downtime.
Escalation must work even without a specific technician
An SLA should not depend on the personal telephone number of a single administrator. There must be a service channel, appropriate cover for absences and a clear escalation path.
For a critical incident, you need to know:
- where to report the incident;
- who confirms its priority;
- when a senior technician or support manager becomes involved;
- who communicates with the customer’s management;
- how often updates are provided;
- who decides on a temporary workaround or planned outage.
Escalation does not simply mean forwarding a ticket to someone else. It should raise the level of incident management, bring in the necessary expertise and ensure regular communication.
An SLA cannot be evaluated without measurement
The source used for evaluation should be a ticketing system or another predefined record from which timestamps can later be retrieved.
Each request should record:
- receipt;
- first qualified response;
- commencement of work;
- service restoration;
- final resolution;
- priority and any changes to it;
- clock suspension and its reason;
- communication with third parties;
- the customer’s approval of closure or the automatic closure method.
The monthly report should present performance separately by priority and type of commitment. A single overall average can hide a delayed critical incident among dozens of quickly resolved minor requests.
Before signing, request an anonymised sample report. Verify that it contains the data used by the agreement to calculate SLA performance and that the reason for every exception can be traced.
Continuous infrastructure monitoring can detect some incidents before a user reports them. However, it must be clear what the monitoring actually checks and whether an alert automatically creates a ticket.
The consequences of non-compliance belong in the agreement
The SLA should describe the complaint procedure and how a disputed incident will be assessed. It may provide for a service credit, discount, corrective action or the right to terminate the relationship in the event of repeated non-compliance.
It is important to specify:
- who may report non-compliance;
- the deadline for submitting a complaint;
- which records will be used;
- how any compensation is calculated;
- whether compensation is subject to a monthly cap;
- what constitutes a repeated breach;
- how access credentials, documentation and data will be transferred when the service ends.
Compensation will not restore a failed operation. It does, however, require both parties to define precisely which parameter is binding and how compliance with it will be demonstrated.
Checklist for comparing proposals
Copy the exact wording of both proposals into the middle columns. Mark any blank entry or verbal promise as an unresolved issue.
| Checkpoint | Proposal A | Proposal B | What must be explicitly stated |
|---|---|---|---|
| Scope | ___ | ___ | devices, users, locations and services |
| Ticket receipt | ___ | ___ | permitted channels and the authoritative timestamp |
| Response | ___ | ___ | specific action and deadline by priority |
| Commencement of work | ___ | ___ | separate definition and measurement method |
| Restoration and resolution | ___ | ___ | commitment, operational target or estimate |
| Priorities | ___ | ___ | impact, scope, security and workaround |
| Support hours | ___ | ___ | days, hours, public holidays and time zone |
| On-call support | ___ | ___ | activation method and included priorities |
| Escalation | ___ | ___ | contacts, sequence and update intervals |
| Exclusions | ___ | ___ | specific and comprehensible list |
| Clock suspension | ___ | ___ | reasons, start, end and required cooperation |
| Third parties | ___ | ___ | who communicates and what they continue to manage |
| Backups | ___ | ___ | scope, RPO, RTO and recovery testing |
| Reporting | ___ | ___ | data source, frequency and content |
| Consequences of non-compliance | ___ | ___ | complaints, corrective action and any compensation |
| Termination of the relationship | ___ | ___ | transfer of access credentials, documentation and data |
What to have added before signing
A good SLA enables two people reviewing the same ticket to reach the same conclusion: its priority, the start and end of the measurement period, the duration of any justified suspension and whether the commitment was met.
Before signing, use the agreement to evaluate three scenarios from your own organisation:
- the internet connection is down across an entire branch;
- one user cannot sign in;
- the company needs to schedule the creation of an account for a new employee.
If the priority, clock calculation, responsible person and escalation method cannot be determined for any of these situations, the SLA needs more detail. Uncertainties belong in the agreement or its annex, not merely in an email from a salesperson.
Frequently asked questions
Is response time the same as resolution time?
No. A response is the qualified acceptance and assessment of a request. Commencement of work means the first actual intervention, restoration returns the service to a usable state, and resolution represents a permanent, verified remedy. Each point in time should have its own definition.
Does a small business need 24/7 support?
Not automatically. It depends on the company’s operating hours, the importance of its systems and the impact of an outage at night or over the weekend. For some businesses, support during business hours supplemented by on-call cover for critical incidents is appropriate.
What if Microsoft 365 or the internet service provider causes the problem?
An IT administrator cannot guarantee the repair time of third-party infrastructure. However, the SLA may require diagnosis, opening a case with the third party, providing logs, seeking a workaround and regularly updating the customer.
Is backup automatically included in IT management?
No. The agreement must explicitly state which data is backed up, where it is stored, how often backups are performed, how long copies are retained and who checks the outcome of backup jobs. Recovery testing, RPO and RTO should be agreed separately.
How can I recognise a good SLA before signing?
For the same incident, the customer and provider should determine the same priority, authoritative start of measurement, support hours, responsibility and escalation method. If the outcome depends on a salesperson’s verbal explanation, the wording is not yet precise enough.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).