How to Design ITIL SLA Structures?

Service Level Agreement (SLA) is the most fundamental aspect of the ITIL philosophy. Everything that ITIL recommends and suggests revolves around the assumption of an effective SLA. An SLA is a set of promises made by the service provider to the customer. However, it is essential to understand the difference between a customer and a user.

  • Customer: An internal entity, a person or a function in the organization that works with IT to deliver services to the user
  • User: The person who uses the IT services on a daily basis

You should carefully read the points discussed below to structure your SLA and implement ITIL effectively.

How to Structure an SLA

  • Structuring your SLA IT Support Services:

    Over the years, IT support services have consumed the majority of the IT budget in organizations. This is mainly due to the fact that support services have the most direct interaction with the business customer. It provides a variety of services to the business – infrastructure services, network support, application development, and maintenance. An SLA is the one single factor that keeps all these services functioning. Without a solid SLA, the relationship between IT and the business customer would disintegrate, and eventually, the entire service delivery of the organization fails.

  • SLA and Value:

    An SLA demonstrates the value created by one party for the other. Value is created when the services provided meet or exceed the expectations of the customer at an optimal cost. For value to be clearly demonstrated, the SLA should contain the list of support services that are being delivered, and more importantly, at what performance levels. The performance level is the key component here which translates into business value for the customer.

  • SLAs for Different Combinations:

    It is important to know that different SLAs are created for individual IT organization – business customer combinations. The underlying structure of the SLA will remain the same. However, specific services provided and associated performance levels and goals differ according to the customer. For example, a systems infrastructure SLA would be different from an application support SLA. This difference is critical because it has the potential to alter the entire scope of the services delivered and performance measurements.

Elements of an SLA

The following 8 sections are fundamental to any SLA:

  1. Introduction:

    This section will introduce the IT organization, the business customer, and the service relationship between them. For example, the application software group provides attendance tracking services to the human resources department.

  1. Description of Services:

    After the service provider and customer have been introduced, you need to list what services will be provided, what work will be performed, and the measurement parameters of service delivery. This could include:

    • Attendance tracking, hardware maintenance, application support, incident repair
    • Hours of support for different types and levels of service
    • Service contact points and contact information
  1. Description of Responsibilities:

    Both the service provider and the business customer need to fulfill certain responsibilities for the service to function smoothly. This section will talk about who is responsible for what within the scope of the service. Responsibilities of the service provider, responsibilities of the customer, and shared responsibilities of both parties need to be listed in this section.

  1. Operational Parameters:

    For the high-level service to meet its performance measurement goals, the underlying operational parameters which govern the service environment need to be defined, measured, and monitored. When these operational parameters move beyond the scope of the service, the SLA needs to be renegotiated.

For example, in the context of a maximum number of transactions per hour, the maximum number of employees who access the attendance tracker in an hour could be an operational parameter.

  1. Service Level Goals:

    Service level goals are the target metrics that the service needs to meet. These are the performance expectations for certain service metrics. Different sets of data may be required to determine these service level goals. It is critical to consistently collect real-time performance data and analyze it to determine if these service level goals have been achieved.

    Example metrics:

    • Number of Priority 1 incidents resolved within 2 hours
    • Number of Priority 2 incidents resolved within 24 hours
  1. Service Performance incentives or Penalties:

    Any agreement will be honored better when there are incentives to meet and exceed expectations. On the other hand, when expectations are not met, penalties also serve to motivate service providers. This section needs to mention financial incentives for the service provider for meeting expectations and penalty clauses for not meeting service performance goals.

  1. Service Performance Reporting:

    Service reports must be generated at frequent predetermined intervals for the customer to be able to track the performance of the service provider. These reports provide a picture of the comparison between the target parameters and the actual scenario.

  1. SLA Sign-Off:

    In this final section of the SLA, the above-mentioned services, responsibilities, performance goals, and incentives need to be agreed upon by the IT organization and business customer and signed off. Once this agreement is signed, it is binding on both parties.

The structure discussed above will serve as a starting point for your SLAs in your organization. These sections mentioned here are critical parts of an SLA that will help clarify and organize the service delivery process and formalize the relationship between the service provider and customer.

Related Posts:
ITIL Implementation Roadmap: 6 Tips to Adopt ITIL Effectively
How Cultural Dynamics Play an Important Role in ITIL Implementation
6 Essentials for a Successful ITIL® Implementation
Implementing ITIL Framework with Other Process Methodologies

Previous articleWhat is ITIL and its Levels of Certification?
Next articleTop 10 Communication Mistakes by Project Managers
Jacob Gillingham is an Incident Manager with 10+ years of experience in the ITSM domain. He possesses varied experience in managing large IT projects globally. With his expertise in the IT service management domain, currently, he is helping an SMB in their transition from ITIL v3 to ITIL 4. Jacob is a voracious reader and an excellent writer, where he covers topics that revolve around ITIL, VeriSM, SIAM, and other vital frameworks in IT Service Management. His blogs will help you to gain knowledge and enhance your career growth in the IT service management industry.

LEAVE A REPLY

Please enter your comment!
Please enter your name here