The service level agreement (SLA) is a brilliantly simple tool that should enable you to always meet your user’s expectation and to prioritize every task based on the agreement with the client. The concept of service level agreements (SLAs) has received a lot of attention over the last decade. In part this was fuelled by the need to monitor the performance of IT service providers in outsourcing deals. When spending thousands, millions or billions of dollars to someone else to manage your IT, there must be some measure of performance. But now it has become very relevant even for your internal IT team. Metrics used in devising SLAs can range from the detail of individual issue resolution times to the overall performance and availability of an IT function such as email. The help desk is important to SLAs in two respects –
- a) as a source of information on IT performance and issue resolution, and
- b) how any issue or problem is dealt with as effectively as possible to minimise the impact on service and on the service parameter being monitored.
A well-placed SLA allows for the help desk to be run at optimum efficiency and to provide the highest level of support for users. Tickets are responded to in a timely manner and breaches of SLA are considered a rarity.
The service you provide always starts with the creation of a ticket. This is the first action that can be quantified with details of date and time. From then on, the we can start timing how long it takes fo other events to occur. A few of the areas that are commonly tracked are:
- Time to first response and acknowledgement of a ticket
- The time it takes until it is assigned to a technician
- The time until the ticket is fully resolved
Each of the above represent a definitive stage In the life cycle of a ticket. Most service desks will at least monitor a first response and resolution time to determine the level of service they provide.
An effective SLA structure will keep tickets and the work required to complete those tickets moving through the service desk with a velocity that reduces the chance that tickets get stalled and, even worse, forgotten.
Benefits of a system with strong SLA features
An essential part of SLA features is a simple if-then statement. For example, if a ticket is logged by a certain client or user and it hasn’t been responded to within a certain timescale or the SLA time is running out then a notification to all the relevant people will be sent to prompt an action be taken against that ticket.
Another powerful feature of most SLA aware systems is the ability to setup different SLA criteria for different customers as shown in the example above. This allows the MSP to customize the delivery experience for different customers with unique requirements as well as offer different pricing for higher levels of service attention.
Don’t be afraid to extend SLA
Extending your SLA may feel like cheating; however, I will go on to explain how you and your customers will benefit.
Having breached SLAs creates pressure on help desk agents and managers alike. Agents feel like they have an endless queue of requests and managers are unable to bring the help desk under control. By extending an SLA, from say a 2-hour response to a 4-hour response, this pressure immediately lifts and performance increases. You will now be able to correctly prioritize and not be overwhelmed by a sea of breached requests.
Prioritize by Criticality
Not every function in IT has the same criticality, and criticality for any function may vary within each month or quarter. Sometimes if SLA’s a running out it comes down to tending to the business-critical issues first. For example; loss of connection for a sales team in the middle of important negotiations can be detrimental to the success of that sale whereas a minor issue with connection for a non-business critical department can be put on hold for a small bit longer. It is important to have people working in your help desk that can recognise the importance of prioritizing and not being afraid to allow SLA’s to be breached for the greater good of the organisation. If this is the case it should be documented why this breach has happened for records.