How SLAs in ITRP Differ from Other Systems

With most service-desk systems, SLAs are based on triggers. For example, with a simple SLA based on priority, if the priority is set to High, the response time is 1 hour. This works if you don't have many SLAs. It gets complicated if other factors have to be taken into account. Consider that the organisation is a managed service provider (MSP) and there are multiple customers. Now you have to filter that original SLA with the name of each company in order to have differing SLAs. That's one SLA per company.

An SLA is, essentially, an agreement between people. Even if not documented, an agreement most likely was negotiated. When you signed up for a service contract with an air-conditioning company, you probably discussed when a tech could be reasonably expected to arrive to fix an issue. This is the heart of the SLA.

SLAs in ITRP are a codification of these agreements. Instead of figuring out what triggers will reproduce the timings of an SLA, the SLA itself is defined. Here's an example:

An MSP has three customer organisations, Org 1, Org 2 and Org 3. It was decided that if an issue has to do with a server, the response time should be 1 hour and the resolution time 4 hours. The same agreement was made with all organisations except Org 3, which has a response time of 2 hours and resolution time of 6 hours. Org 3 is paying less for the service in exchange for longer response and resolution periods. This is a two-tiered service offering.

An example of a trigger-based SLA

In non-ITRP systems, you would define the first SLA as a trigger set of:

  • Customer is Org 1 or Org 2 AND
  • Work Order Type is Server AND 
  • Priority is High.

The second SLA would be:

  • Customer is Org 3 AND
  • Work Order Type is Server AND 
  • Priority is High.

To incorporate additional times based on different priorities, you would need to repeat the above with a different priority filter. This produces a large number of trigger-based SLAs.

 

Portion of an ITRP Service Offering, showing targets

In ITRP, you would create two service offerings, Server Repair (Standard) and Server Repair (Basic).

Service offerings are containers where the agreement is written out in full, the response and resolution times are set based on four possible impacts (e.g. Low - Service Degraded for One Userand other information, including what penalties are incurred for a breach, are stored.

SLAs are containers that connect the service offerings to customer organisations. This is where the service offering is related to specific customers, as these customers will have a set timeframe in which the SLA is valid. Each customer will be different.

Example of an SLA for a customer organisation

When a server issue from Org 1 comes in, ITRP establishes the appropriate service offering and if an SLA is associated with it. It finds that it does and applies the SLA.

ITRP's approach to SLAs gets to the heart of the agreements. The relationships between the customers and the SLAs are what drive the application of SLAs, not arbitrary triggers.

Note that this approach allows an organisation to create an SLA with other organisations that provide it service, as in the above air-conditioning maintenance example. When an internal staff member reports an issue with the air-conditioning, it can be entered in ITRP and the SLA will be applied. The performance of the service provider can be measured against this SLA.