Constructing a Service Level Agreement
Service Level Agreements are used to govern the provision of a service between the provider and the recipient –
With the right structure Service Level Agreements provide an effective way to ensure that commitments between customer and supplier are kept. They can also provide an important contribution in business structure and human resource requirements – for example within an SLA it’s common for Key Performance Indicators to feature – these can be easily tied into staff appraisals and training needs analysis.
In a service industry (for example outsourced IT Helpdesks) it’s important, where there are multiple customers, to have a priority system established – this should sit as a framework above the SLAs and feed from their performance levels providing employees an effective method of prioritising workloads.
Service Level Agreements should remove any ambiguity from the service provision provided. It’s important to include a table of definitions to ensure that everyone understands the service and common acronyms and industry specific jargon.
Service Level Agreements can vary greatly depending on the complexity of the service provided and the environment or industry that the service is utilised in, while no SLA can attempt to cover everything these documents are important in providing governance. There are some universal components that can be used to build a service level agreement.
To begin with the SLA should define the service(s) being provided – they should articulately define the customer and the provider together with the date of the agreement and the time period which the agreement is valid within. If relevant the SLA should also define the hours of service eg. 9am – 5pm – Monday – Friday.
Where applicable the client should be defined by location and size for example – is the service provided to a business if so – at which locations and to how many personnel. While such attention to detail may seem overly time consuming – it’s important to get these straight from the beginning as the SLA may be valid for a significant period of time and business may change alter their structure during this.
Without doubt things will go wrong during the SLA operating period, bearing this in mind the SLA should clearly state the problem reporting/ escalation procedure – how are complaints to be transmitted /received and any financial penalties incurred.
It should also be clearly described the process for reviewing the SLA and making changes. This could be annually and changes may require the approval of all applicable parties.
It’s common that the SLA will define the payment schedule and prices – this may be flat rate or tied to performance or service consumed. The SLA will also define penalties that may be imposed (on either party) through either non-delivery or missed performance requirements.
Key Performance Indicators should be described (together with applicable targets) – the SLA should explain who will produce the KPI’s and how they will be distributed. It’s important to remember that KPI’s may be applicable to both the supplier and the customer.
Any customer responsibilities should also be defined – this could include things such as availability of staff, location, equipment etc.
Once produced the SLA should be reviewed and approved by all parties, the final SLA (which should contain a version history control sheet) should contain signatures of appropriate authorized representatives. The SLA should then be distributed and stored as appropriate. Business reviews should be undertaken at regular intervals and the SLA should be used to benchmark the performance.