Managing Customer Expectations

Promoting confidence within your service and support operation

Customers! Customers! Customers! What more can be said, but they are often the bane of every service and support operation. In a non-ITIL automated environment, customers are ‘never happy’, ‘always criticizing’ and annoyed that their system functions at a less than optimum level. They complain that the support is slow and waiting periods are insufferable. In fact, as service operators, the task of meeting expectartions seems totally impossible.

In non-ITIL automated environments the capacity for support staff to foster any form of job satisfaction becomes virtually impossible. On the other side, customer confidence and loyalty is jeopardized if there are no clear parameters outlined in relation to the support operation. Without such information how do customers know if the service is better than expected?

Service Level Agreements

In order to promote confidence within the service and support operation and its end-user customer base, service expectations need to be clearly defined and recorded. Service Level Agreements (SLAs) allow contracts to be drawn up between the Service Desk and Customers. Within these documents all manner of expectations can be mapped including response, restoration and resolution time plus black-out periods for specific items or services.

LiveTime Help Desk users are able to define SLAs for their customers, while LiveTime Service Desk users have full-scale ITIL Service Level Management (SLM) capabilities. This means, not only can external agreements be defined with customers in the form of SLAs, but internal service staff contracts can be negotiated in the form of Operational Level Agreements (OLAs). SLM can also extend the contractual obligations to cover support issues that are outsourced by the Service Desk and are governed by Underpinning Contracts (UCs).

The Business Logic of SLA selection

The SLA business logic within both LiveTime applications is the same. That is the service agreement with customer is either assigned to their Configuration Item (CI) that is being supported, the customer themselves or the organizational unit (company or department) they belong to. When the customer logs a service request, the application checks for the Item an SLA, if an SLA has not been assigned to the Item, it will check the Customer and failing that, it will check the Org Unit. This means the support operation has flexibility when managing its service, as it can be done at a granular level for some customers and at a broad-stroke level for others.

Based on the SLA selected and the type of request (in the case of the Service Desk product the request may be an Incident, Problem or RFC), a relevant workflow is selected. The workflow assigned to the request defines the SLA obligations by including timed states and states that are classified as meeting the restoration and resolution time of the SLA. In case of the Service Desk product, it also allows each stage of the workflow to be governed by either an OLA or UC, as displayed in Figure 1.

By assigning SLAs to service requests, support staff knows what is expected of them and if they do not meet the contracted agreements they can understand that their customers have reason to complain. Conversely, if complaints are unwarranted, reports can be generated to inform customers that SLA obligations have been fulfilled. The ability to include this functionality into the service process ensure service and support staff know when they have performed well beyond customer expectations or if the service provided give their customers cause for complaint, which builds user confidence for both customers and the support team.