What SLA does your company need
An SLA (Service Level Agreement) is the part of an IT support contract that defines, in measurable terms, the quality of service your company will receive: how quickly the provider must respond to a failure, how quickly to a service request, how quickly it must be resolved, during which hours support is available, what commitments apply to data backups and restores (RTO — Recovery Time Objective, RPO — Recovery Point Objective), how incident priorities are assigned and how all of this is measured. The right SLA for your company is the one that matches the real cost of your downtime: a standard office typically does well with business-hours coverage, while manufacturing, e-commerce and organisations delivering critical services need wider availability windows and stricter commitments for top-priority incidents.
A common mistake is choosing an SLA by gut feeling: either the maximum tier for peace of mind, paid for without any real need, or the minimum tier, which looks good on the contract line but costs dearly during the first serious outage — or worse still, in the event of data loss. In this guide we explain which parameters an SLA consists of, how to map them to the nature of your business, and what to ask a provider before signing.
What an SLA is in plain terms
An SLA is a measurable promise. Instead of a vague statement that the provider reacts promptly to failures, the agreement records how quickly work on an incident of a given priority must begin, during which hours the service desk operates, and how performance is evidenced in reports. Without an SLA, an IT support contract remains declarative — there is no objective yardstick for judging whether you are getting what you pay for. We cover the broader contract scope in our guide on what an IT support contract should include.
One thing to understand up front: a higher SLA is not automatically a better SLA. It is a balance between risk and cost that every company sets according to its own operations.
The key SLA parameters
Response time
Response time is the period from the moment an incident is registered until a specialist actually starts working on it. It is not the automated message confirming your request has been received — it is the moment real work begins. The contract should state clearly when the clock starts and what counts as a response.
Resolution time
Resolution time defines how quickly an incident must be resolved, or a temporary workaround applied that allows people to keep working. Some providers commit only to response times, not resolution times — this is worth clarifying early, because for the business it is resolution speed, not response speed, that determines the cost of downtime.
Availability windows: 9×5, 12×5, 24×7 or others
- 9×5 — support during business hours on working days. Suitable for companies that operate on a standard office schedule and stop when the working day ends.
- 12×5 — extended hours on working days. Relevant when part of the team starts early or works late, there is shift work, or customers are served across longer hours.
- 24×7 — round-the-clock support, including weekends and holidays. Needed when a system outage at any hour directly stops revenue or critical operations.
The availability window can differ between systems: workplace support at 9×5, for example, with monitoring of critical servers at 24×7. Such a combination is often more rational than applying one uniform level to everything.
Priority categories P1–P4
Incidents are classified by their impact on the business. Below is a typical scheme with illustrative intervals — it shows how priorities work in practice, not any specific provider’s commitments; actual times are always fixed in the individual contract:
| Priority and incident type | Example | What response to expect |
|---|---|---|
| P1 — critical: the whole company or a critical system is down | A server is down, email is out for everyone, the online store or the production accounting system has stopped | Immediate response, for example measured in minutes or hours; continuous work until operations are restored |
| P2 — high: an important function is impaired, a workaround exists | One department cannot work, the ERP system is running slowly | Response the same working day, for example within a few hours |
| P3 — medium: inconvenience for one or a few users | One employee’s computer or printer fails | Response, for example, within one working day |
| P4 — low: planned work and service requests | Setting up a new workstation, installing software, a consultation | Scheduled work, for example within a few working days at an agreed time |
How to choose an SLA based on your business
There is no universal answer — the right level is driven by one question: what does an hour of downtime cost us? Guiding principles by type of operation:
- Office-based business (services, administration, project work). Downtime is unpleasant but rarely catastrophic — staff can temporarily switch tasks. A 9×5 window with strict P1 handling during business hours is usually sufficient. The smarter investment is not a round-the-clock hotline but prevention and smooth workplace support.
- Manufacturing. If production lines or warehouse systems run in shifts, the availability window must cover all shifts — 12×5 or wider. The critical parameter is resolution time for P1 incidents, because a stopped line generates direct losses.
- E-commerce. The store earns at night and on weekends, so critical systems generally need 24×7 monitoring with automated alerts — so the provider learns about a disruption before your customers do. Workstations, meanwhile, may only need 9×5.
- Critical services (finance, healthcare, infrastructure, public sector). Here the SLA is often dictated not only by business logic but by regulation — including NIS2 requirements. Critical systems need 24×7 coverage, defined escalation procedures and documented compliance.
A good sign of a mature provider: they help you classify your systems by criticality themselves and propose different levels for different groups, rather than one flat tier for everything.
What to ask a provider about SLA measurement and reporting
An SLA is only as valuable as your ability to verify it. Before signing, ask these questions:
- How are incidents registered, from which moment is response time counted and from which moment resolution time?
- Will we receive regular reports on request and incident volumes, priorities and SLA performance? How often?
- Will we see the status of our tickets in real time — or only take the provider’s word for it?
- What happens when the SLA is missed: what is the escalation path, and are there defined consequences?
- How is a priority assigned to an incident — against clear criteria or at the provider’s discretion?
- Is system monitoring automated, or are incidents only logged when users call in?
Mature providers manage IT operations according to ITSM and ITIL practices and automate systems monitoring — so a large share of incidents is detected and resolved before users even notice them. You will find more evaluation criteria in our guide on how to choose an IT support company.
Too high an SLA means wasted cost, too low means risk
The SLA level directly affects the price of the service: a wider availability window and stricter deadlines mean more on-call specialists and more expensive infrastructure on the provider’s side. If you order 24×7 for all systems while actually operating 9×5, you pay for capacity you will never use. Conversely, saving money on a minimal SLA can cost you more in a single serious outage than you saved over a year. We describe how the SLA level fits into overall service pricing on the page about how much IT support costs.
The rational approach is to review the SLA periodically and, from the outset, to set different SLA levels for different IT services according to how critical the operations they affect are: as the business grows, adds online channels or shifts, needs change — and the agreement should change with them.
Why Altic IT
Our advice on SLAs is not theoretical — we serve a large and diverse client base under service level agreements every day, so we know which levels actually prove themselves in different types of operations.
- 180+ clients served, ~3,500 computers and mobile devices and ~350 servers under management;
- ISO 20000 (IT service management) and ISO 27001 (information security) certifications — service levels are managed to international standards;
- IT operations managed according to ITSM, ITIL and COBIT best practices;
- automated continuous systems monitoring and regular client reports — SLA performance is visible, not merely declared;
- within the first 3 months, client incident volumes are reduced by up to 5 times;
- professional liability and cyber risk insurance of EUR 2 million;
- open-ended contracts — we stay as long as you are happy;
- the vast majority of clients come through referrals; clients include the Bank of Lithuania, Bitė Lietuva, CityBee and Vilnius City Municipality.
Frequently asked questions
-
What is the difference between response time and resolution time?
Response time is when a specialist starts working on an incident; resolution time is when the problem is fixed or a workaround is applied. Resolution time matters more to the business, because it determines the length of the downtime. When evaluating a provider, ask about both parameters.
-
Does a small company need an SLA at all?
Yes — an SLA is about clarity, not company size. Even for a company with a handful of employees, the agreement defines what to expect when systems fail and makes the provider’s performance objectively measurable. A small company simply needs a simpler, narrower level.
-
Can different systems have different SLAs?
Yes, and it is often the most rational approach. Critical servers or an online store can get a wider availability window and stricter deadlines, while workplace support runs at a standard business-hours level. That way you pay for the high tier only where it is genuinely needed.
-
How can I verify that a provider is meeting the SLA?
Require regular reports on incidents, their priorities and deadline performance, plus visibility into ticket status. A reliable sign is automated systems monitoring and tool-based incident logging, rather than manually maintained records.
-
Can the SLA level be changed during the contract term?
In well-drafted contracts — yes. Business needs change: new shifts, new sales channels, stricter regulatory requirements. Choose a provider that reviews the SLA periodically and proposes adjustments proactively, instead of waiting for the contract to expire.
Discuss the right SLA level for your business
Not sure what service level your operations actually require? Let us talk it through: we will assess the criticality of your systems, your working schedule and your cost of downtime, and propose a rational SLA model — no overpaying for capacity you do not need, and no gaps where the risk is highest. Reach us via the contact page or by phone at +370 5 2032018 — and read more about our services on the IT support services page.