When operating the Service Level management process, we need to make sure we have the following “bases covered”.

Here are our 12 Top Tips...

1. Are The Service Level Agreements (SLAs) Succinct?

SLAs need to be short and to the point – we should simplify them by removing everything that is not actually necessary. Also bear in mind that the SLA is a customer facing document and should not have too much jargon.

A glossary may be needed to explain certain key terms for the customer (e.g. what we mean by availability) but also so that IT staff can understand any customer jargon that has to be in the SLA.

2. Have We Ensured That Both The Service Provider And All The SLA Signatories Have Understood Whether The SLAs Are Offering Targets Or Guarantees?

Guarantees have to be hit - no exceptions. This means having a great many resources available to run the service, usually beyond what the stakeholders wish to fund and often well beyond their actual needs in terms of service performance.

Targets are to be aimed for – by definition they will be missed occasionally. We should discuss with the customer how often we can miss the target and by how much. It might be useful to have a secondary target related to a primary target, e.g. if the primary target for incidents is to fix them within 2 hours, we could have a secondary target that not more than 5% of incidents should exceed 2 hours and another target that any incidents that exceed 2 hours should not do so by more than 30 minutes.

Obviously the stricter the targets, the greater the level of funding that will be required. Stakeholders that fund the service need to think carefully about what they are comfortable paying for.

If the customer says a target “can’t be missed” then we need to clarify if they really are wanting a guarantee and crucially, if they are able to fund it.

Of course the time to have these discussions is when the SLA is being initially negotiated for a new service and again during the (at least) annual review of the SLA. It is not a good idea to be clarifying with the customer their understanding of targets and guarantees during a service failure!

(Before we continue, take a look at this link if you want to read about service transition manager roles).

3. Which Targets Should We Offer To Our Customers?

Common targets that are offered to customers include an incident management target (e.g. MTRS, MTTR or similar) and an availability target. However the targets that we negotiate and agree with customers should reflect their needs, not what is commonly done. For example, would it be beneficial for the customer if we also offered them a problem management target? What about a change management target? What other targets might benefit your customers?4. Have The Targets Been Agreed With All The Relevant Stakeholders, Including Those That Will Have To Deliver The Services?

It is not a good idea to agree some targets with the customer(s) and then later ask the staff responsible if they can actually deliver the service. This will inevitably lead to missed targets, unhappy customers and demoralised IT staff.

Another common problem is that the SLAs are negotiated and agreed with customers whose main concern may only be the price of the service. They may not have consulted their own users as to what the service should be like. The customer might never actually use the service but may be happy that it is the right price, whilst simultaneously the users may be very unhappy with a service the doesn’t meet their needs.5. How Will The Targets Be Measured And Reported On?

For example, if the target time to fix an incident is every incident individually measured against the target, or is it an average? Let us look both cases with an imaginary target of 2 hours to fix an incident.

Let us consider a set of incidents in a week where four incidents took 0.5 of an hour and one incident took 2.4 hours. In the case where each and every incident was measured and reported on against the target individually, we report to the customer that one incident had exceeded the target.

In the case where the target is an average measured over the week, it will depend which average is used. The most commonly used is the mean, which in this case would be (0.5 + 0.5 + 0.5 + 0.5 + 2.4) / 5 = 0.88 and so we would report to the customer that the target had been hit.

If an average is used as the target, the time period over which it is measured is very important. The longer the time period the easier it is for the service provider to hit the target (because lots of short outages over time lower the average), if the time period is very short it may become impossible to hit the target.

How will we measure and report on other targets such as availability, problem management, change management? For example, is the time to do a change measured from the first submission of the RFC to the completion of the change review or from time of the authorisation of the change to the release of the change into the live environment – the latter time will usually be much less than the former.6. Should There Be The Possibility Of "Stopping The Clock" On A Target In Certain Circumstances?

For example, if there is a time to fix target but the service provider cannot fix a particular incident without some action by the customer then it is usually agreed that the SLA clock can be stopped until that action is completed. Note that the time might stop on more than one clock, for example on both the incident target and the availability target.

It may also be appropriate to stop the clock if the issue has to be escalated to a supplier.

As always, the decisions on the rules governing these matters are best taken in consultation with your customers at the time of SLA reviews, not during an outage!7. How Often Will We Report Service Performance To The Customer And In What Format?

It is best practice to report to the customer information that is meaningful to them, in a time scale that suits them and in a format that suits them. One of the implications of reporting meaningful information is that the targets for the service have to be something the customer can relate to – for example it is probably pointless to report the number of packets on the network. The customer would typically prefer something directly related to their outcomes, such as the number of successfully completed transactions. Of course it will depend on the customers’ needs.

Practical issues can complicate the above advice. For example a train company with tens of thousands of customers will not physically be able to send individually tailored reports on service performance pro-actively to each customer – but nor is there a need to. A balance of suitable reporting against the cost of measuring the data and producing the reports is what most customers will be satisfied with.7. Do We Have A Defined Complaints Procedure?

It should be possible for a customer to raise an official complaint about a service. In the event of a complaint being declared the complaints procedure should have defined certain outputs, for example a written response to the complaint. Whilst the complaint (and the response to it) are obviously very important to the customer, it perhaps even more important to the service provider. On top of the importance of resolving the complaint, each complaint also represents a learning opportunity for the service provider.

For the same reason it is wise to have a way of capturing compliments about the service – they too are learning opportunities.9. Are The Responsibilities Of All Parties Clearly Defined?

A good SLA (like a good OLA and a good Underpinning Contract) does not put obligations on one of the parties only. In the case of SLAs we should consider what obligations should be on the customers and users of the service.

For example, experience has shown that an SLA should specify that users should call the helpdesk/service desk when they first realise there is an issue with a service, not waiting until they are really annoyed with it! Similarly there should be an obligation on the users to follow reasonable requests from the helpdesk in order to resolve an incident, e.g. to power cycle a piece of equipment that cannot be accessed remotely by the helpdesk.

RACI is an excellent tool to clearly define who will do what. Many organisations attach RACI matrices to their SLAs10. Charging, Penalties and Bonuses

Charging isn’t mandatory, unless you are a commercial organisation and have to charge for your services, in which case details of any charging formulas, charging periods and policies, penalties and bonuses, together with invoicing procedures etc must be included in the SLA or in a ‘confidential’ appendix. The may also apply for ‘Notional charging’ where the SLA is with an internal customer and real money does not actually change hands.

When SLAs are being discussed, many people say words to the effect of “where do the penalties go in the SLA?” - Interestingly they almost never ask “where do the bonuses go?”. A good SLA (or OLA or UC) should encourage service improvements, bonuses can be one method of doing this.

While it may be very useful to have bonuses and penalties in the SLA, a ‘risk and reward’ option in a commercial SLA may seem a good idea at the time but can be divisive and inadvertently change supplier behaviour, not always for the better.

Consider whether the customer want the target to be hit, or the services to be delivered? There are countless examples of service providers being put under so much pressure from various stakeholders to hit targets that they manipulate situations to hit the targets while simultaneously delivering poor service. The pressure could be in the form of severe penalties (or overly attractive bonuses) but the pressure can take many forms.

Avoid this situation by ensuring penalties and bonuses are only used for exceptional circumstances. In the case of bonuses they should be for exceptionally good service, not for every-day service. Similarly when considering applying penalties, would the customer rather receive the penalty payment, or have the service provider spend the money on improving the service?

In short, beware of “hitting the target, but missing the point”.11. Have We Aligned Our OLAs And UCs Appropriately With Our SLAs?

Many targets in SLAs need to have supporting targets in OLAs and UCs. Note that the supporting targets usually have to be much stricter than the target they are supporting.

For example, if an SLA has an incident management target of 4 hours for incidents of a certain priority, then the associated target in the OLAs and UCs will usually need to be around 1 hour. This is to allow for situations where the helpdesk/service desk has spent some time trying to resolve the incident before realising that it needs to be escalated. Obviously the 2^nd line team or supplier that receives the escalation cannot have a 4 hour target starting from when they receive the escalation.12. Do We Have A Clear Method of Reviewing The Service And Also The SLAs? What About OLAs And UCs?

The ITIL® Service Design publication tells us in the Supplier Management chapter that we should have two types of reviews with suppliers. The first is for how well the service is currently being delivered, the second is to review the agreement that governs the service. We should offer our customers the same types of review.

There should be regular reviews with customers covering how well (or not), the service is currently being delivered. Typically these reviews should be preceded by the circulation of reports providing information on how well targets were met. There can be problems getting customers to attend these reviews if they feel that the service is good – in which case there should be a mechanism whereby the customers agree that non-attendance of the review gives explicit agreement that the service is good. This is not so that the service provider has avoided any future blame, but so that there is an agreement of the service being marked as good at a certain time – which takes the heat out of any later discussions about perceived poor service performance.

The second type of review allows the customer to request an alteration of the service, the SLA, or both. We should explicitly ask the customers at least once a year if they wish to make any such alteration. Note that receiving and recording a changed requirement is not the same as agreeing to deliver it!

The above advice needs to be applied as appropriate in your context – for example a train company will not be able to meet with each and every one of its customers.

In a case where a review leads to changes to a service and/or its SLA, also consider the impact of that on OLAs and UCs. Similarly if a UC changes due to external factors, do we have in place a mechanism whereby supplier management process will notify SLM of this?

So What Now?

Hopefully, this blog and our previous offering 'Getting Started With Service Level Management' has helped you to define what you should have in place to ensure effective and efficient Service Level Management.

If you wish to go further then please take a look at our formal training courses covering Service Level Management.

• ITIL® Service Offerings and Agreements

Or if you or any of your team want to start at the beginning, please take a look at our ITIL® 4 Foundation training here.

For Professionals looking for a BCS Specialist Certificate in Service Level Management, check our site for availability.

And before you go you might also like to read this post answering the question: What Is Change Management?