An IT service level agreement (SLA) commits a service provider and its client to specific objectives, such as response times, availability of a service and incident tracking. But a written commitment is not enough: it must be measurable, adapted to the needs of the company and verifiable using understandable data. Discover the service levels that an SLA can cover, the difference between support time and resolution time, as well as the indicators that allow you to evaluate the results. You will also see how to define realistic commitments for an SME in Geneva, monitor performance and identify clauses likely to create a gap between the expected service and the service provided.
Key Points
- Define the services covered and the responsibilities of each party so that the commitments are understandable.
- Distinguish the time taken to take an incident into account from the time needed to restore service.
- Interpret the availability objectives with their measurement period and the conditions provided for in the contract.
- Associate each commitment with a verifiable metric, then regularly review results and incidents.
Table of contents
What is an IT Service Level Agreement or SLA?
An SLA formalizes the expected services and commitments agreed between an IT provider and its client. It establishes a common framework for assessing the quality of the service, specifying responsibilities and dealing with discrepancies.
Definition and objectives of an IT SLA
An IT service level agreement (SLA), also called a service level agreement, describes the expected results for an IT service. It helps the client and the supplier to agree on the scope covered, responsibilities and the method of evaluating the service.
For an SME, the interest is concrete: users know how to report an incident, and managers have a common basis for discussing it. A trustee can, for example, distinguish a problem accessing her accounting software from a request for installation on a workstation.
Service level management involves defining commitments, monitoring their compliance and reviewing them with the supplier. It links the service to operational needs. A useful SLA uses precise formulations, understandable by both the administrative manager and the technical team.
In Switzerland, the SLA describes the agreed service commitments, while the service contract governs the service as a whole. To determine which obligations apply to a situation, review the relevant contract documents and the services they cover. The SLA does not constitute, on its own, a general list of legal deadlines applicable to all IT service providers.
The difference with a performance indicator is also important. An indicator measures a result; the SLA organizes the commitments and responsibilities linked to the service. An isolated measure therefore does not specify who should act when the expected result is not achieved.
Penalties and compensation
Penalties and compensation are measures that the parties can include in the contract in the event of non-compliance with an agreed commitment. They clarify the follow-up to be given and avoid negotiating a case-by-case response after each incident.
Terms may provide for additional support or a price reduction. The contract must then describe the commitment concerned, the elements allowing a deviation to be noted and the manner of applying the planned measure. It must also distinguish a measurable failure from general dissatisfaction.
For example, if a service becomes unavailable and the agreed response time has passed, the parties can review the gap based on reporting traces and reports. The applicable mechanism depends on the accepted clauses: compensation does not apply automatically.
Compensation does not restore service. The SLA can therefore also specify incident monitoring, corrective measures and communication with the users concerned. An SME has an interest in clearly distinguishing these actions from possible contractual consequences.
Before agreeing to a clause, check that it specifies how both parties identify the breach and document its resolution. This precision facilitates the application of the system and exchanges between the company manager and the supplier.
Uptime and Uptime Metrics
An SLA can track service availability, outages, and processing times. To correctly interpret these measurements, identify the period observed and the events taken into account.
Availability rate
The availability rate expresses the portion of the expected time during which a service remains usable. It helps to assess whether access to the service meets the needs of the business.
For an SME, specify the service measured: a business application, a network connection or all work tools. An application accessible from offices, but not remotely, can give a different image depending on the scope chosen.
The measure must also define what “usable” means. If a colleague can log in, but cannot register an invoice, the application technically works without meeting the expected use. Describe the essential operations that users must be able to perform.
Authorized unavailability
Authorized unavailability designates the downtime duration compatible with the agreed availability objective. It translates a performance threshold into a concrete consequence for the activity.
Its interpretation depends on the measurement period. The same target can correspond to a different shutdown duration depending on whether the calculation covers working hours or the entire calendar. The SLA must therefore specify the period retained and the processing of planned maintenance.
Also take into account when the shutdown occurs. For a fiduciary, the unavailability of accounting software during a closing period can be more inconvenient than a comparable interruption when the team is not using it. The threshold should reflect operational needs, not just show a favorable percentage.
Uptime and downtime
Uptime is the period when a service fulfills its intended purpose; downtime refers to periods when this use is no longer possible. This distinction makes monitoring easier for teams.
Define the conditions that mark the start and end of an interruption. An SME can, for example, consider its invoicing tool unavailable as soon as a user can no longer create or save an invoice, even if the login screen opens normally.
Finally, distinguish unavailability from slowdown. A slow application can remain accessible while preventing a task from progressing properly. A separate indicator allows this situation to be documented without confusing it with a complete failure. The monitoring report thus becomes more precise and better reflects the user experience.
Performance measurement and key performance indicators
A useful SLA associates each commitment with a calculable metric and a tracking method. To choose the right criteria, start from the services used by your SME, then specify the content of the reports and their frequency.
Include metrics that the provider can document, such as response times, resolved incidents, and availability. Then present the results in regular reports and revise objectives as the business or infrastructure evolves.
Performance criteria and indicators
A performance indicator, or KPI, measures a specific result in relation to a defined objective. It helps to check whether the service provider is respecting commitments and to identify difficulties affecting users.
Use verifiable metrics: time between reporting and response, recovery time or share of requests processed within the agreed time frame. An SLA can also target 99.9% availability. For an SME, distinguish critical incidents from routine requests so that the numbers reflect real priorities.
Define for each indicator the calculation period, data source and included events. Without these criteria, the parties risk interpreting the same result differently. The number of unanswered calls, for example, should be related to the volume of calls received during the measured period.
Performance reporting
Reporting brings together the results of the indicators in a report shared between the service provider and its client. It makes the relationship more readable and allows discrepancies to be discussed based on common data.
The SLA may include a monthly service level report and a quarterly meeting. For an SME, the report can present incidents, their response times, interruptions observed and objectives achieved. Each figure must be accompanied by its period and method of calculation.
Weekly monitoring may be appropriate for a particular situation, such as an IT transition period. Frequency is less important than consistency: the same indicators must appear from one report to another. A simple chart helps an administrative manager distinguish a trend from an isolated incident.
Service levels to include
The service levels to be included are the commitments that describe the expected results for each service covered. They link indicators to concrete situations, instead of tracking numbers unrelated to the activity.
Specify support hours, incident categories, response times and resolution targets. Add availability criteria when a tool directly supports operations. In a fiduciary, for example, access to accounting software may require separate monitoring from that of a shared printer.
An indicator must correspond to an identified service and relate to elements that the service provider can control. Avoid grouping different tools into a single measure: a network outage and an application incident do not necessarily have the same origin. This distinction makes the results more useful during a contractual exchange.
Performance monitoring and review
Monitoring involves collecting planned data, comparing results to objectives, and reviewing gaps with the provider. A periodic review allows the SLA to be adapted to the evolving needs of the SME.
Retain tickets, reporting times and incident reports. These traces make it possible to verify compliance with deadlines and to explain a discrepancy. If users report slowness despite good availability indicators, add a metric related to the observed functionality.
During a quarterly review, compare reports, identify recurring incidents and agree on corrective actions. If a team regularly reports a defect after an update, for example, monitoring must show the dates, consequences and follow-up actions. The measurement then becomes a tool for improving the service, not just a control of the figures.
SLA Types: Customer Level, Service Level, and Multi-Level
The scope of a service level agreement varies depending on whether it covers a customer, a specific service or several levels. The model chosen must link the supplier's commitments to the concrete needs of the company.
Customer-based SLA
A customer-based SLA brings together the agreed commitments for a given customer and its services. It allows specific needs to be taken into account, without applying the same conditions to all users.
An SME can thus combine support for its workstations and access to its business application in a single agreement. The agreed levels may vary depending on the importance of each tool. This formula gives an overview, but requires a clear description of each service covered.
This model is suitable when the expectations of a fiduciary differ from those of a business, even if both use a similar IT service. The contract then specifies the responsibilities, support schedules and response objectives specific to this relationship.
Service-based SLA
A service-based SLA defines the same commitments for every customer who uses a given service. It makes it easier to compare results because the provider applies a common framework to this service.
For a cloud service, the agreement may provide for 99.9% uptime over a monthly period. A host can also set a target of 99.95% for its clients' websites. The percentage must be associated with the service concerned and its method of measurement.
This approach is suitable for standardized services, but does not always reflect the specific needs of an SME. A tool used during business hours and a platform that receives orders continuously may require different expectations.
Multi-tier SLA
A multi-level SLA combines common commitments and provisions linked to a service or customer. It avoids repeating the same conditions while providing rules adapted to specific needs.
The general level can define the reporting process for all users. A level specific to the service then specifies the response times for a business application. In an SME, an internal agreement between teams can also distribute the tasks necessary to respect the commitment made with the supplier.
This structure clarifies the interventions of each party at each stage. However, it must avoid contradictions between the general level and the specific requirements of the service.
Examples in Cloud and Customer Service
The cloud and support examples show how an SLA translates a service into observable objectives. They help to compare commitments, without constituting universal thresholds.
A customer service agreement can aim for first-call resolution for 70% of requests. It can also provide a response to emails within 24 hours, then escalation of unresolved calls to level 2 support within one business day.
For an SME, these commitments show why the contact channel and the definition of a request matter. A received email and a call transmitted to level 2 do not follow the same processing step. The SLA must therefore associate each objective with a service, a measurable event and an identified manager.
Control of service commitments
An SLA sets out the expected results and the means to control them. A maintenance contract describes maintenance operations, while an managed IT services contract entrusts the management of IT services. The SLA can complement these contracts by specifying service levels, tracking evidence and handling of deviations. In Switzerland, agreed expectations must be clearly formulated in the contract.
Monitoring of service commitments
Monitoring involves comparing agreed commitments to observed data during the planned period. It allows you to verify results and examine discrepancies based on specific facts.
Retain tickets, reporting times and incident reports. For a Geneva SME, these elements make it possible to trace an application failure, from its reporting to its return to service. The report must identify the service concerned, the period measured and the method used.
Also plan a regular exchange on the results. An SLA may, for example, include a monthly service level report and a quarterly meeting. There, managers can review recurring incidents, agree on corrective actions and assign each action to a party.
Differences with maintenance and managed IT services
The SLA specifies the expected service levels, while maintenance and managed IT services mainly describe the services. This distinction helps to know what is achieved and how the results are evaluated.
A maintenance contract may provide for equipment upkeep or corrective interventions. It does not necessarily specify response times or performance indicators. The SLA can complete these elements, for example by distinguishing a blocking failure from a current request.
Managed IT services entrusts the service provider with the management of all or part of the IT services. Its scope can include several tasks, while the SLA specifies the expected levels for these services. An SME that entrusts the management of its positions can therefore separately define the incident response times and reporting methods.
To monitor a gap, first identify the commitment involved and the available evidence. Then compare the data to the agreed threshold and record the finding in the report. If the contract provides for compensation, the report must document the expected conditions and the period concerned.
Useful control also takes into account user expectations. For example, a report might show that tickets are being processed on time, but an application remains difficult to use. The parties can then specify an indicator linked to the functionality or agree on a separate action, rather than concluding that all needs are covered.
The scope of the control depends on the written commitments. Define the data reviewed, responsibilities for collecting it, and the process for contesting a result. This method avoids basing a report on criteria different from those accepted by the service provider and the SME.
Flux Group SARL: Flux ICT
Flux Group SARL supports SMEs who wish to better organize their IT services and incident monitoring. Its services include IT support, cybersecurity as well as VoIP telephony and telecommunications. They are useful for clarifying the services covered by commitments and support expectations.
A fiduciary may, for example, want to distinguish routine support requests from an incident that blocks access to its tools. Precise indicators then make it easier to monitor the relationship with the service provider and read the results. To discuss your IT support or telephony needs, contact Flux Group SARL.
Prepare the next review of your commitments
Before reviewing your IT service level agreement (SLA), gather recent incidents, tools affected and difficulties reported by your teams. These elements will help you distinguish between commitments that still fit your needs and those that need clarification. You can then define priority services, expected results and the monitoring method with your service provider.
Also plan for a review after a significant change, such as the deployment of a new application or changing work schedules. An agreement adapted to the activity facilitates discussions and provides managers with concrete criteria to monitor the service. Go point by point, starting with the department that most directly affects your operations.
A clear approach allows agreements to evolve at the pace of your business.
Frequently asked questions
What is an IT SLA or Service-Level Agreement?
An IT SLA, also called Service-Level Agreement, formalizes the levels of service expected between a supplier and its customer. It serves as a common reference when you evaluate a service or discuss an incident. For example, if a business application becomes inaccessible, the parties can rely on the agreed criteria to determine the service concerned and the action to be taken.
How to calculate the availability of an IT system?
Divide the uptime by the expected service time, then multiply the result by 100. The calculation must be for a defined period and take into account interruptions according to the SLA rules. In particular, check how planned maintenance and partial failures are handled. An app may appear accessible, but still prevent users from performing a key action.
How to choose, write and implement an effective SLA?
Start by listing the services involved and the operations they support. For each, specify the scope covered, responsibilities, measurement criteria, reporting methods and handling of deviations. During the negotiation, check that the teams have the data necessary for monitoring. Once the agreement is drafted, communicate incident reporting instructions to users.
How to adapt the type of SLA to IT governance and why supervise commitments?
Choose an SLA per customer if their specific needs take precedence, per service if the same service concerns several customers, or multilevel if general rules coexist with specific requirements. Supervision helps identify deviations and recurring incidents based on monitored data. A review with operational managers makes it possible to determine whether priorities, tools or the distribution of responsibilities have changed.
What response and resolution times should be expected depending on the priority of the incidents?
For a critical incident, examples include response in less than 30 minutes or within an hour, and resolution within four hours. For a minor incident, an example provides for a response within 24 hours and resolution within 72 hours; for a major incident, resolution can be expected within eight hours. Always distinguish response time from recovery time.
Article by
Delyan TZONEV
Passionate entrepreneur and manager, I am CEO of Flux Group and Hype Swiss. I support companies in their digital transformation thanks to innovative solutions in IT, telecommunications and software development. My goal is to design high-performance technologies that simplify the daily lives of businesses and support their growth.
Disclaimer
The articles published on the Flux Group blog aim to share our expertise, our field experience and best practices in IT, cybersecurity, cloud, telecommunications and digital transformation of SMEs.
We strive to provide reliable, up-to-date and relevant information at the time of publication. However, technologies, regulations and service offerings are evolving rapidly. The published content is therefore provided for informational purposes and does not constitute personalized, legal, tax, financial or technical advice.
Each company has specific needs, we recommend that you seek professional support before making a decision or implementing a solution presented in our articles.
The opinions, recommendations and comparisons published on this blog reflect our analysis and experience. When we talk about partners or publishers such as Microsoft, Swisscom or Infomaniak, our objective is to present the solutions objectively, highlighting their advantages as well as their limitations depending on the different contexts of use.
Flux Group cannot be held responsible for any direct or indirect consequences resulting from the use of the information published on this blog. Links to external sites are provided to complete the information; their content is the responsibility of their respective publishers.
© Flux Group – All rights reserved.
Our services
If you wish to be supported in the choice, deployment or optimization of your IT solutions, the Flux Group experts are at your disposal. We support SMEs in Geneva, Switzerland and Pays de Gex in their Microsoft 365, cybersecurity, cloud, telecommunications, managed IT services and IT infrastructure projects.
Questions fréquentes
What is an IT SLA or Service-Level Agreement?
An IT SLA, also called Service-Level Agreement, formalizes the service levels expected between a supplier and its customer. It serves as a common reference when you evaluate a service or discuss an incident. For example, if a business application becomes inaccessible, the parties can rely on the agreed criteria to determine the service concerned and the action to be taken.
How to calculate the availability of an IT system?
Divide the uptime by the expected service time, then multiply the result by 100. The calculation must be for a defined period and take into account interruptions according to the SLA rules. In particular, check how planned maintenance and partial failures are handled. An app may appear accessible, but still prevent users from performing a key action.
How to choose, write and implement an effective SLA?
Start by listing the services involved and the operations they support. For each, specify the scope covered, responsibilities, measurement criteria, reporting methods and handling of deviations. During the negotiation, check that the teams have the data necessary for monitoring. Once the agreement is drafted, communicate incident reporting instructions to users.
How to adapt the type of SLA to IT governance and why supervise commitments?
Choose an SLA per customer if their specific needs take precedence, per service if the same service concerns several customers, or multilevel if general rules coexist with specific requirements. Supervision helps identify deviations and recurring incidents based on monitored data. A review with operational managers makes it possible to determine whether priorities, tools or the distribution of responsibilities have changed.
What response and resolution times should be expected depending on the priority of the incidents?
For a critical incident, examples include response in less than 30 minutes or within an hour, and resolution within four hours. For a minor incident, an example provides for a response within 24 hours and resolution within 72 hours; for a major incident, resolution can be expected within eight hours. Always distinguish response time from recovery time.
Besoin d'un accompagnement IT à Genève ?
Parlons de votre infrastructure, de votre sécurité ou de votre téléphonie. Sans engagement.
Contacter Flux Group