Imagine a world where you can effortlessly prioritize and resolve customer issues, proactively identify bottlenecks, and constantly improve your service delivery. The power to achieve this lies within ServiceNow’s robust SLA framework, allowing you to set clear expectations, monitor performance, and drive your teams towards delivering exceptional service experiences.

A service-level agreement (SLA) sets the expectations between the service provider and the customer and describes the products or services to be delivered, the single point of contact for end-user problems, and the metrics by which the effectiveness of the process is monitored and approved.

Gartner

Please note that SLM application is built to handle an SLA of just about any type. It can be used for the traditional SLA metrics (often between vendors and customers), but it can also be used for SLA’s between departments.

Who typically creates SLA’s?

In most situations the service provider creates the SLA. However, it is very important to include the customer, or the department, in reviewing the SLA’s. It could impact their business if not accurately set up, or if they favor the service provider too much, and need further negotiation.

When should my Enterprise start using SLA’s?

Depending on your Enterprise’s IT maturity level, the question really is how advanced should my SLA’s be? Right from the very start it is suggested to take advantage of using the SLM application. The image below outlines the various stages of SLM growth and advanced reporting for your companies needs.

Where do I start with setting up SLA’s?

Per ServiceNow, the following should be included in your SLA data.

Agreement summary

Possibly the most-important part of the SLA is the summary of the agreement itself. This should clearly outline and summarize the service, the stakeholders involved, and the metrics that will be used to measure success.

Party objectives

• In some cases, the SLA will focus heavily on the customers’ goals, and fail to connect those goals with organizational objectives and important KPIs. When this is the case, it’s important for service providers to establish their own measurable goals that may be applied to help promote client success. For internal SLAs, every involved department will need to outline their own goals and objectives.

Schedules for reviews

• SLAs may also need to establish a review schedule. These reviews will allow parties to periodically reassess the SLA and make changes when necessary.

Points of contact

• The SLA must make fully clear who is responsible for what aspects of the service. This section should detail who is involved, who should be contacted regarding which issues, etc.

Compensation for unmet goals

• The SLA is a legally binding contract, and if the promised service levels are not delivered, then there will need to be consequences. This section outlines what those consequences are, and what compensation the service recipient can expect in remediation. For internal SLAs, this may involve plans detailing how the defaulting party can ensure that their dependent parties are still able to meet their objectives.

Cancellation conditions

• SLAs are not forever — they’re usually designed to apply for a limited amount of time, and there may even be occasions when one or both parties may wish to terminate the SLA and replace it with something better during the contract. Whether because the SLA isn’t working, circumstances have changed, or the agreed-upon end date has been reached, this section formally established the conditions in which the SLA may be revoked.

10 Best Practices for Configuring SLA’s

The following are guidelines to consider when gathering requirements and setting up SLA’s for your enterprise:

1. Understand and define SLA requirements: Clearly understand the SLA requirements of your organization or customers. This includes response times, resolution times, and any other relevant metrics or targets.
2. Identify and prioritize SLA-impacted services: Identify the services or department requests that require SLAs based on their criticality and impact on business operations. Prioritize SLA configuration accordingly.
3. Use appropriate SLA measurement criteria: Determine the appropriate criteria for measuring SLAs. This could include task completion, incident resolution, or other relevant metrics. Define the conditions and calculations for each SLA metric.
4. Define SLA calendars and business hours: Configure SLA calendars and business hours based on the operational hours and working days of your organization. Consider different calendars for different locations or departments if needed.
5. Configure SLA stages and milestones: Define SLA stages and milestones to track the progress of SLA metrics. Configure appropriate start and end conditions for each stage and ensure accurate escalation and notification settings.
6. Set up SLA notifications: Configure notifications to inform stakeholders about SLA breaches or impending breaches. Use email notifications, pop-up notifications, or other appropriate communication methods.
7. Test and validate SLA configurations: Before deploying SLAs to production, thoroughly test and validate the configurations in a non-production environment. Ensure that SLAs are functioning as expected and meeting the defined criteria.
8. Provide user education and awareness: Educate and communicate SLA policies, expectations, and benefits to users and stakeholders. Ensure that they understand the SLA metrics, their responsibilities, and the consequences of breaching SLAs.
9. Monitor and review SLA performance: Regularly monitor SLA performance using SLA reports and dashboards. Analyze trends, identify bottlenecks, and take corrective actions if SLAs are consistently being missed.
10. Continuously improve SLA management: Regularly review and refine SLA configurations based on feedback, lessons learned, and changing business requirements. Continuously improve SLA management processes and workflows.

Remember, SLA configuration for business process is an active and evolving lifecycle. Once the initial groundwork for SLA reporting has enough data to show trends or be used for compliance and audit reporting, that is when the next evolution of your SLA lifecycle should begin.