On the previous blog we went through a brief introduction in creating SLAs and looked through some areas to taken into consideration when drafting and signing off SLAs. I will now go through some of the key challenges that you will be faced with during this stage.
Current resources and capabilities – during the negotiation of SLAs, a large dependency will be on the OLAs and underpinning contracts (UCs) that can be agreed within the internal support teams. Getting support teams in particular to put pen to paper can be very difficult, especially if added responsibility is being accepted by the team.
OLAs and UCs – we may have temptation to agree an SLA before the relevant OLAs / UCs is agreed, but this should be resisted. We do not want to be seen as ‘over promising and under delivering’ when signing off SLAs.
Language – you may have seen in many publications related to SLM that SLAs have to be written in business language. Do we remove all technical terms? Do we recruit for a non-technical service level manager to perform the role to ensure its written in business language? Well, these are definitely not the answer.
Firstly, a service level manager with some form of technical understanding will add value to an organization as they will be able to read and digest the relevant OLAs / UCs before committing to service levels with the customer.
Secondly, it’s not about removing technical terms or concepts within the SLA but it’s about being unambiguous and avoiding the SLA being interpreted differently with the different stakeholders.
For example, you commit to a 2 hour response to a customer incident relating to a printer and a 16 hour resolution to all printer incidents. Leaving this as it is, it can lead to misinterpretation. What does a 2 hour response mean? Is that acknowledgement the call is logged or being dealt with by an IT support team. Also what does a 16 hour resolution mean? Does this start from when the incident is logged or from the time a response is given back to the customer?
To avoid all this confusion, maybe something like this would help.
• 2 hour response will be given to all printer incidents. Therefore within 2 hours of the call being logged on the service desk tool, you will receive a response from the service desk or another technical support team to confirm the incident is being looked into and an ETA of when the call will be resolved.
• We will resolve all printer incidents within 16 hours from when the incident is logged on the service desk tool.
SLAs should drive IT, but SLAs are not the vision
Agreeing SLAs can have a negative impact on the workforce as support teams may see this as the ultimate target to achieve. The SLAs should be achieved but it should create a culture of bad practice. For e.g. I’ve achieved the SLA, so the customer cannot be dissatisfied. Or the service is working brilliant as I’ve achieved the SLA.
The SLAs will need to be regularly reviewed and aligned to an overall business objective/vision. If this is not the case then why are we committing to service targets that have no impact on the business?
On the next blog, we will look into the key interfaces associated with the management of SLAs.