Service level agreements (SLA) sit at the heart of ITIL practices. For the uninitiated, SLAs define expectations for both the service provider and the “customer” when engaging in a service. For example, a critical issue that carries the high risk of server downtime might have a 15-minute SLA for an initial response, while an information request might carry a 48-hour SLA.
There are several issues that impact SLAs and their definition. Smaller organizations that have fewer help desk incidents might have a 2-hour response time on urgent issues, while larger organizations that manage thousands of users and their hardware may require a longer response period due to different priorities.
You may also have multiple SLAs within a single incident response. An employee who brings their laptop to the help desk due to frequent crashes may come across SLAs covering the initial response, triage, a loaner computer, and problem resolution.
SLAs go beyond fixing employee computer issues. They are utilized to define IT responsibilities like server uptime, network speed, and storage issues. In all these cases, the IT team works together with the business units to create realistic SLAs designed to both keep the business teams running effectively, and allowing the IT team to provide any necessary services within the parameters of its team size, budget, and expertise.
While SLAs are an invaluable tool to many businesses, when applied indiscriminately, they can create more headaches than they solve. For example, an SLA that requires the IT team to fix an employee laptop within 30 minutes might seem like a good idea on the surface. However, having IT members drop everything they are doing to immediately fix minor issues inevitably means that more pressing issues, such as applying security patches, may end up being overlooked as IT members upgrade an employee’s software.
Here are a few best practices your business and IT teams should focus on when developing SLAs, which will help keep your operations running smoothly.
Be Specific About Your SLA
There are a few components found in any good SLA. First, they start out by defining and describing the services that are to be provided. Once defined, your SLA needs to be specific about the level of service that is being provided, and the timeframe for that service.
Essentially, there are two components here. The first, services that are being provided, make up a key piece of the SLA, and it should include conditions for service availability, time frames for each service, and situations that may include exceptions. Issues that take place during a snowstorm may have different terms and conditions than issues that take place during normal operations, while issues that happen during off-peak hours, such as in the middle of the night, might not have the same SLA as an event that happens at eleven o’clock in the morning.
Service definitions need to include the responsibilities of each party, escalation procedures, and cost-service tradeoffs.
The second component covers SLA management. This includes creating reporting processes, definitions of methodologies and measurement standards, dispute resolution processes, and processes for updating the agreement as required.
All this information needs to be specific in order to limit areas that are open to interpretation and ensure that both parties have realistic expectations of the resolution process.
SLAs Must Be Measurable and Trackable
For an SLA to be effective, it must be both measurable and trackable. Saying that servers need to have a high degree of uptime, or computer issues need to be resolved as quickly as possible, is not effective.
When the goals aren’t clear, it leaves far too much room for subjectivity and judgment rather than being able to rely on a single truth. An IT team might claim that 98% uptime is a high degree of uptime, and consider that SLA to be achieved, while the business teams might argue that they expect 99.999% uptime and consider the service provider to be in breach of the SLA.
In addition to being measurable, the data must be trackable. Agreeing to respond to any urgent computer issues within 90 minutes is ineffective if there isn’t a productive and accessible time-stamp system capable of measuring the data.
Don’t Create Pie-in-the-Sky SLAs
Your SLAs must be achievable. A company with a small, understaffed help desk needs to be realistic about what it can and should expect in terms of support. Similarly, companies that choose to run older hardware on their networks can’t reasonably expect the same level of service as they would get with newer hardware deployments.
While everyone wants SLAs that keep systems running and operating efficiently, creating SLAs that are misaligned with the reality on the ground is an invitation for disagreements and SLA breaches.
The Bottom Line on SLAs
Defining realistic SLAs that your business units and IT teams can work with is vital in keeping your operations running effectively. Ensuring that your SLAs have been fully thought through will help in ensuring a spirit of cooperation between IT and operations.
Make sure your SLAs don’t leave room for interpretation and can be easily measured for reporting purposes. Keeping everything realistic helps protect all sides from disappointment when unachievable targets go unmet.
Your SLAs need to be considered a living, evolving agreement. As processes change, hardware ages or is upgraded, and needs of the organization shift, your SLAs will need to adapt as well.
Effective organizations schedule semi-annual SLA reviews to manage the changes that take place within their network and organization. In addition, whenever there is a major change taking place, be it personnel or network related, relevant existing SLAs should be reviewed, to ensure that the agreement is aligned with the changing reality on the ground.
