Service Level Agreement (SLA)

 

A user who submits an incident or service request (SR) always hopes that it will be processed as quickly as possible. Conversely, the technical agent at the support center manages his or her time so as to address the highest possible number of incidents and SRs. But how does one know whether to process an SR before an incident of “normal” priority, for instance? Or why work to the resolution of an “urgent” incident before processing an SR where a workstation must be configured for a new employee before tomorrow morning? The Service Level Agreements (SLA) answers these questions. 

 

By means of SLAs, the Octopus application provides a simple solution for measuring the service level provided to clients by the technical support center.

 

SLAs represent the maximum delays by which to resolve incidents and process SRs. By activating the SLAs, the technical support center provides itself with an easy to use and efficient tool enabling to heighten agent responsibility with regard to users.

 

For example, if an incident of “High” priority must be resolved within a maximum delay of six (6) hours according to the SLA, the assignee commits him or herself to resolve the incident submitted by the user within that delay. On the other hand, the user knows exactly what to expect, considering that the issue will be taken care of within a maximum delay of six (6) hours.

 

One objective of the SLAs is to enable to evaluate and quantify the technical support center’s productivity in terms of the service provided to users. Among others, via the SLAs “Statistics” module, managers will be able to get precise information and specific measurements.

 

Here is an example of a graph displaying the number of incidents and outstanding issues for the year 2006.

 

 

A graph such as this one enables the manager to see that late incidents were not numerous in 2006, except for the month of September.  By means of data mining, by double-clicking on a column, one can see the information concerning all individual incidents within the selected month and monitor the reason for the number of SLA breaches.

 

The manager will thus be able to see if the technical support center is efficient. If there are problems such as frequently late issues or user complaints, maybe it is because the maximal delays are too short? Or could there be a lack of resources, of a human, material or financial nature? The SLAs enable to view diverse aspects of the service provided by the technical support center in order to answer these questions and thus make an informed decision.

 

Here is an example of a graph displaying the number of incidents and outstanding issues for the month of September.

 

 

 

Prerequisite for SLA activation

 

To activate the Service Level Agreements, the following steps must be followed:

 

  1. Determine the maximum delays according to incident priorities and SR types (click here for more information).

 

  1. Configure the warning functions regarding the SLAs, as well as the notification preferences for these measures (click here for more information).

 

  1. Complete the “Hours of operation” and “Holidays” section for your technical support center (click here for more information).

 

  1. Check the box to “Activate the Service Level Agreement” (click here for more information).

 

 

Given that each technical support center has different resources, the SLA standard must be customised. Each support center determines its own SLAs according to its own specific priorities, categories and subcategories. It is important to correctly specify the maximum delays; these may always be modified according to need, in order to respect the convened SLAs.

 

Location: Index

See also: SLA configuration