Why do I need an SLA?

By Robert Hall, Support Analyst, Marval Software
 

Well, let’s start with what a Service Level Agreement (SLA) is. Put simply, it is a definition of reasonableness – what the concerned groups consider is practical in a business relationship.

An SLA is an agreement between two or more parties, where one is the customer and the others are service providers. It may be a legally binding, formal or an informal contract (for example, internal department relationships). The agreement may involve separate organizations, or different teams within one organization. It defines what IS and what IS NOT.

SLAs come packed with a moral obligation, though. For Service Desks, SLAs are not just business contracts; they are a promise the organization has made to its customers, that their request will be properly managed within a specific timeframe. SLAs are the basis where excellent service is planned, realised and delivered; and the organization’s customer-centric culture is reinforced.

So, considering that, how can we use an SLA in an ITSM software platform, such as Marval MSM?

We need to define the hours of cover during which the SLA will apply, and the Service(s) and Customer(s) the SLA is applicable to. Hours of cover are effectively the opening hours of the business. The hours need to match the actual availability of the service providers, since they are not going to agree to be available 24x7 if they are only offering 9x5.

The SLA can have exceptions added to cater for, such as business critical services, equipment or dealing with high priority requests. You would do this to reflect the shorter times that apply here, because you want to be sure the service provider performs to the agreed standards – or at least you can report on the time the SLA is valid for.

Marval MSM has a default SLA configured with hours of cover, response and fix clocks, which can be used for all requests, customers and services, unless specified otherwise. It’s called Default Global SLA and is used when no other matching service level agreement has been found. This SLA can be modified to fit the standard hours of cover.

It is possible to add new SLAs with tighter or looser hours, as well as fix and response times. Use these where appropriate. But be careful, see below.

It should be possible to monitor the progress of Incidents which invoke an SLA – you need to be able to enforce the SLA – or they become worthless. Marval MSM can create alerts which send an email at pre-determined elapsed time points, for example at 50%, 75% and 90% of the allowable time.

Finally, recognise that all this is in addition to the efficient Service Desk processes and staff that are looking after the Incidents. It must be remembered that outages happen, services become unavailable and, if you spend all your time counting minutes and hours, the SLAs can become worthless too; there is a job to be done, the ITSM Processes are in place to allow that to continue, where possibly uninterrupted. Look closely at the Service Portfolio, revise if necessary, and make continual service improvements. If it is hardware that is the weak point then build in redundancy, if it is application-based then review the software being used. Use your ITSM tool wisely.

SLAs are a promise to the business’ customers, that prompt and great service will be delivered. organizations can keep this promise by using their best assets: great process, great technology, and great people who will realise the customer-centric culture and ensure that customers are being served within pre-defined, high standards.