Please enable JavaScript to view the comments powered by Disqus. Importance of SLA & SLM in Serving Customers

 

Importance of SLA & SLM in Serving Customers

NovelVista

NovelVista

Last updated 17/06/2020


Importance of SLA & SLM in Serving Customers

SLAs. They are the foundation of conveying items and administrations to clients. Clients need them since they give an outline of 'what they will get' from a specific item or administration, how accessible the item or administration will be, the means by which rapidly we will react, how frequently we will keep them refreshed, and, above all, how we will fix them when something turns out badly. The rundown goes on. Specialist co-ops don't for the most part love making and distributing SLAs as we're frequently held to these requesting principles. Notwithstanding, I would contend that, without them, we're held to the unimaginable standard of everything, constantly, for nothing. In the event that you don't have SLAs set up, set up them. On the off chance that they've gone stale or clients loathe them, it merits seeing approaches to improve them. 

This blog article will give an outline of some Service Level Management-related ideas and definitions including SLAs and the new idea of Experience Level Agreements (XLAs). We'll likewise take a gander at what's going on and fascinating about the ITIL 4 SLM practice and contrast it with what existed in ITIL v3 (for those of you that know about that rendition). At that point, I'll share my contemplations on why getting this stuff right can represent the deciding moment our clients' impression of us, how they interface with us, and the general soundness of that relationship.

 

WHERE DO SERVICE LEVEL MANAGEMENT AND SLAS FALL IN ITIL 4?

How about we start with the reason behind the ITIL 4 Service Level Management (SLM) practice: 

Reason: to set clear business-based focuses for administration levels, and to guarantee that conveyance of administrations is appropriately evaluated, checked, and oversaw against these objectives.

As referenced over, one of the most incredible assets a specialist organization has available to them is setting up a type of SLA that sets desires, drives beneficial and important discussions with clients and permits better administration and improvement of our general execution. That is done as a major aspect of the ITIL 4 Service Level Management practice. Here's a chart from the ITIL 4 SLM practice that is useful in picturing the exercises associated with it.

Service Level Management Concepts from ITIL v3

The SLM practice in ITIL 4 falls into the general classification of "Service Management" rehearses, essentially those ideas that have been a piece of the ITIL books since the beginning and structure the premise of the idea driving Service Management. For any of you that have considered or taken an ITIL v3 instructional class, the SLM practice (which used to be known as a procedure, more on that wording change here), has been around for over 10 years. 

A ton of the fundamental ideas from ITIL v3 is the equivalent: the significance of making SLAs that are quantifiable and reasonable to accomplish, composing SLAs in the plain, client-centered language (basically, maintaining a strategic distance from tech language that befuddles clients), just as surveying our group's presentation against SLAs, talking about approaches to improve execution, and updating SLAs varying. The distinction in the ITIL 4 SLM practice is that there's significantly more detail around every one of these things and reasonable exhortation all through – 33 pages of good data.

 

Does Service Level Management Still Reside in ITIL’s Service Design Phase?

The short answer is no. ITIL 4 gets rid of the service lifecycle, supplanting it with the idea of the Service Value Chain or SVC, which is a substantially more iterative and gradual approach to see how the function is really done while conveying items and administrations; and Service Design is presently its own different practice.

New Service Level Management Concepts in ITIL 4 (and Some That Have Gone Away)

There are, nonetheless, some intriguing increases to the SLM practice in ITIL 4, to be specific the incorporation of business-based targets, various sorts of SLAs (past what you may have realized in ITIL v3), which we will discuss in the accompanying areas. One eminent exclusion in the ITIL 4 SLM practice is that of Operational Level Agreements (OLAs) and Underpinning Contracts (UC). Before you get your tissues out, we'll talk concerning why these ideas left.

WHAT IS A SERVICE LEVEL AGREEMENT IN ITIL 4?

The definition of an SLA, though it has changed slightly from the ITIL v3 definition, remains essentially the same, namely:

SLA: a documented agreement between a service provider and a customer that identifies both services required and the expected level of services.

SLAs can have all levels of formality and be legally binding or not. What matters is that our SLAs promote common understanding, are measurable, and are reviewed and changed as things change (more so with a tailored service than an out-of-the-box service), either internally or on the customer side.

A ‘tailored’ service means that there is significant flexibility in target service levels that should be agreed before service delivery and consumption start, whereas an ‘out-of-the-box’ service has one or more pre-defined service levels to choose from, without much flexibility.

WHAT ARE THE 3 TYPES OF SLA IN ITIL V3 AND HOW DO THEY LOOK IN ITIL 4

For those that have gone through ITIL v3 training, you may recall that there were three common types of SLAs that we as service provider organizations would create. They are as follows:

  • Service-based SLAs, which defined one particular service for multiple customers
  • Customer-based SLAs, which defined all of the services that one customer consumed
  • Multi-level SLAs, which often contained a combination of services and customers

In the ITIL 4 practice, these types have been pared down to two simple types: tailored and out-of-the-box SLAs.

SLA REQUIREMENTS AND METRICS IN ITIL 4

I like this recommendation from the ITIL 4 SLM practice – based on ITIL’s guiding principle of “keep it simple and practical”: Do not try to put everything in the agreement, but focus on what matters and can be realistically measured and managed.

Not everything is going to fit within an SLA, nor should it. Instead, the SLM practice guide recommends getting those things “…through the collection of [frequent customer feedback].” This can be done in several ways, including: through conversations like service review meetings, automated dashboards that provide SLA data, and the ability for customers to interact with the dashboard and provide feedback, customer surveys, and even social media sentiment.

NEW CONCEPT IN ITIL 4 SLM: CREATING SLAS WITH BUSINESS-BASED TARGETS

The SLM practice currently incorporates verbiage around setting "business-based focuses" as it focuses on how we as specialist organizations can compose better SLAs by putting together everything with respect to what our clients care about and what they're attempting to accomplish, not simply on operational measurements that sound good to us. SLAs serve us (and those we serve) best when they are written in plain English, are straightforward, consider our clients' needs and viewpoints, take a gander at how they are utilizing the administration, and what the administration is permitting them to do, and advance discussion. The SLM practice incorporates another term, that of "administration quality", which ought to be considered as a major aspect of SLAs.

Service Quality: the totality of a service’s characteristics that are relevant to its ability to satisfy stated and implied needs.

Administration quality can allude to things that are settled upon and recorded in the SLA; in any case, it can likewise allude to desires that are suggested or expected by our clients, so it's essential to comprehend what those things are, gather criticism, and address them to improve as an association. 

This announcement is discovered in the SLM practice very supportive when taking a gander at administration quality: "To keep up a viable assistance relationship, administrations ought to be monetarily suitable for both specialist co-ops and administration purchasers." This is critical—especially when conveying administrations that get income—to guarantee that we hold ourselves in line and don't give an excessive amount of away for nothing. With the goal for SLAs to function admirably, administrations should be savvy for clients and beneficial for suppliers. Regardless of whether we're not "charging" for administrations, there is an incentive in seeing how much time and cash we're spending supporting specific administrations so we can all the more likely oversee where our staff is investing their energy (and whether it's in the correct spots).

 

NEW CONCEPT IN ITIL 4 SLM: FOCUS ON THE USER EXPERIENCE

In ITIL v3, there tended to be an emphasis on Warranty. In ITIL 4, this has been updated to include an equal focus on Warranty (when a service will be there), Utility (what the service does), and user experience. We know that how you provide a service is just important as, if not more than, what you provide. In fact, under the section that speaks to ITIL’s Guiding Principles, it recommends to, “Focus on outcomes for the service consumer organization and on user experience more than on technical details and associated metrics.”

NEW CONCEPT IN ITIL 4 SLM: THE INTRODUCTION OF XLAS

One of the ideas that is insinuated in the SLM practice (with notice of the client experience and business-based targets), yet not explicitly got out, is that of Experience Level Agreements (XLAs). XLAs are significant in understanding the effect we're having on the client experience. Sadly, not very many KPIs utilized in IT divisions depend on factors like client experience, compassion, and feelings; and XLAs can help us as an association build up our ability for computerized sympathy.

How XLAs are Different from SLAs

One of the ideas that is insinuated in the SLM practice (with notice of the client experience and business-based targets), yet not explicitly got out, is that of Experience Level Agreements (XLAs). XLAs are significant in understanding the effect we're having on the client experience. Sadly, not very many KPIs utilized in IT divisions depend on factors like client experience, compassion, and feelings; and XLAs can help us as an association build up our ability for computerized sympathy.

THE EXPANDED DETAILS ON SERVICE REVIEW MEETINGS IN THE ITIL 4 SLM PRACTICE

ITIL 4 has an emphasis on service review meetings. The SLM practice document includes a lot more guidance than what was contained in the ITIL v3 version. Here’s the essence:

“Service reviews can be interval-based or event-based. Interval-based reviews take place regularly at agreed time periods. The intervals depend on factors such as previous satisfaction with the service, the number of changes introduced to the service since the last review, the likelihood of changes to service expectations/requirements, and so on. However, regular service reviews do not usually occur more than once a month. Yet, service reviews do not work effectively if performed at intervals longer than three months. Event-based service reviews may be triggered by events such as a major incident, a request for a significant change in the service, or a change in the business needs/requirements of the service.”

WHAT HAS GONE AWAY IN THE ITIL 4 SLM PRACTICE – OLAS AND UCS

What's absent in the ITIL 4 distribution is any notice of reports called Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). There are a few reasons these terms were evacuated, most outstandingly that, practically speaking, everybody calls everything a SLA. The main contrast is your point of view. Sometimes, you might be offering an assistance; and in different cases, you might be devouring a help from, state, a seller. Nonetheless, the understanding is still between the two gatherings. The main distinction is the thing that side of the relationship you're on. 

Holding fast to exacting phrasing for different kinds of records was, frequently, mistaking for specialist organizations and didn't increase the value of the discussion. Actually, it was regularly a zone of disarray for ITIL v3 understudies and the vast majority just remembered the terms to effectively breeze through the test – and returned to calling everything a SLA after class. I, for one, think the change is a decent one as it disentangles the phrasing we use. (side note: If you discover an incentive in utilizing the terms OLA and UC, don't hesitate to continue utilizing them. Nobody's revealing to you that you shouldn't or can't, they're only no longer terms that are characterized as a major aspect of the ITIL 4 structure). 

So, we certainly need to be careful to abstain from placing ourselves stuck an imbroglio by consenting to a SLA when there are supporting SLAs that contention with it or make it difficult to compose. Quite a long while prior, we worked with a huge retail client that couldn't adequately set up a SLA with their clients on the grounds that the supporting SLA with a merchant did exclude any subtleties around goals times – just reaction times. Tragically, their legitimate division set up the SLA without talking with IT first, coming about in, basically, a goals time of "interminability". Not all that good times

 

ADDITIONAL RESOURCES THAT CAN HELP YOU IN YOUR SLM JOURNEY

AXELOS's Service Level Management practice control gives bunches of extra subtleties and is accessible for nothing concerning those that have taken an  ITIL 4 Foundation course and test (in any case, it's $50 for a one-year membership). In the event that you are answerable for making, checking on, or improving SLAs for your association, it's an advantageous read.

Pro Tips for Creating and Revamping Your SLAs

One of the foundational items to have in place to be able to write good SLAs, however, is to first have a solid list of the services you offer as part of a service catalog (it’s hard to write SLAs when you’re missing clarity around the “S”). Otherwise, you’ll end up re-writing your SLAs before long, and that is definitely no fun for anyone involved. Putting a great Service Catalog together is a deceptively difficult thing to do, and most organizations stop short before getting it to “great”. Don’t have a solid list? Not to worry, we can help (and have helped hundreds of customers with this very thing), and in a matter of days, no less. Here’s a link to our Service Offerings and Agreement course to learn more.

If you have a passable catalog in place, but need a little help crafting or refining your existing SLAs, we’ve got a Service Design Course that can help your team – complete with SLA templates and everything you need to make them great.

Topic Related Post

Is ITIL certification worth your time & efforts?
Is ITIL certification worth your time & efforts?
How to implement ITIL?
How to implement ITIL?
What are the Most Common Root Cause of Major Incidents?
What are the Most Common Root Cause of Major Incidents?

About Author

NovelVista Learning Solutions is a professionally managed training organization with specialization in certification courses. The core management team consists of highly qualified professionals with vast industry experience. NovelVista is an Accredited Training Organization (ATO) to conduct all levels of ITIL Courses. We also conduct training on DevOps, AWS Solution Architect associate, Prince2, MSP, CSM, Cloud Computing, Apache Hadoop, Six Sigma, ISO 20000/27000 & Agile Methodologies.

 
 

SUBMIT ENQUIRY

 
 
 
 
 
 
 
 
 

Upcoming Events

ITIL-Logo-BL
ITIL

Every Weekend

AWS-Logo-BL
AWS

Every Weekend

Dev-Ops-Logo-BL
DevOps

Every Weekend

Prince2-Logo-BL
PRINCE2

Every Weekend

Topic Related

Take Simple Quiz and Get Discount Upto 50%
     
  18002122003
 
  
 
  • Disclaimer
  • PRINCE2® is a registered trade mark of AXELOS Limited. All rights reserved.
  • ITIL® is a registered trade mark of AXELOS Limited. All rights reserved.
  • MSP® is a registered trade mark of AXELOS Limited. All rights reserved.
  • DevOps® is a registered trade mark of DevOps Institute Limited. All rights reserved.