I N C I D E N T A L S

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?

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 for all to reference. 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.


Figure 1: LiveTime Request Assignment

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 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.

Tips and Tricks: All about SLAs and SLM

SLA Restoration and Resolution

The Restoration and Resolution time of a Request is measured from the time the Request is created to the moment it moves into a workflow state that is marked as a Restoration or Resolution state, respectively. States with these flags prevent Request escalation as the SLA targets are met, and the comparison data (SLA time vs Actual time) is displayed within LiveTime's Service Level Reports.

Workflow Contract Time

When a SLA is assigned to a Workflow, the Resolution Time of the SLA is used as the Contract Time. If OLA's and Underpinning contracts are allocated to Workflow states, the SLA Contract Time is validated against the sum Resolution times of the OLAs and UCs assigned to longest path of the Workflow. This validation method is used to prevent the breach of the SLA target resolution time.

SLA resolution time >= Sum (workflow states (OLA or UC resolution times)

Blackout Periods

A Blackout Period of an SLA is the agreed period of time that the Customer has no service expectations. This can also be the preferred time for Item upgrades and maintenance, which will not affect service availability. In blackout periods, the SLA timers and actions are not executed. Blackout periods are configured within the Service > SLA tab.



Within Change Management, the blackout periods of the SLA assigned to an Item specify the best time for service staff to take that Item off-line, if an outage is necessary. To schedule the Outage of an Item, refer to the Change Blackout times within the Outage tab of the Item (Item > Details > Outages).

Contract Monitor

Adherence to service contracts targets for an OLA or Underpinning Contract, can be monitored within a Request under the Contract Monitor of the Impact tab. This information allows Users to view the expected milestones (i.e., response, restoration and resolution times) and complete a checkbox when the milestone is met.



LiveTime automatically calculates the actual time accrued against a milestone. This value is displayed within the Contract Monitor screen and used for the Contract reports.

Next Release....

What to expect in version 5.0 (Part 3)

LiveTime version 5.0 is in the last stages of development and testing, and in this release the LiveTime R&D team have successfully re-engineered the entire customer portal.

Download Fact Sheet...

Along with the extension of its web services integration capabilities, this version includes:

Custom Emails

Users can use a combination of HTML and LiveTime system variables to customize outgoing email messages. LiveTime system variables are simply inserted into the body of system generated emails and parsed in real time. The following system emails can be customized: Emails sent to Users when a Request is created or updated. Emails sent to the Users when a Request Group is created. Emails sent to Customers summarizing Invoice information. Emails sent to Customers regarding the details of their service maintenance contract.

Context Sensitive Help

LiveTime's HTML-based User Guide is now accessible from within any LiveTime screen. To access, users simply click on the "?" help button to bring up context sensitive help on the relevant topic.

Event Calendar

The new monthly event calendar allows Users to view the due dates of their Requests. Users can drill-down to the weekly calendar and inspect the full details of their Requests.

Internationalization

LiveTime v5 has been designed to allow for the adaptation of languages and regions without engineering changes. As an internationalized program, LiveTime has the following capabilities: With the addition of localized data, the same executable can run worldwide. Textual elements, such as status messages and the GUI component labels, are not hardcoded in the program. Instead they are stored outside the source code and retrieved dynamically. Support for new languages does not require recompilation. Culturally-dependent data, such as dates and currencies, appear in formats that conform to the end user's region and language. LiveTime can be localized quickly. Localization is the process of customizing the software for a specific region or language by adding locale-specific components and translating text. The LiveTime internationalized framework is very intuitive and flexible, which allows Users to easily localize the application for a particular language and character-encoding scheme.

Group Templates

LiveTime v5 provides the functionality for Users to manage a sequence of related tasks using Group Templates. Tasks can either be scheduled to commence immediately, or sequenced to occur in a particular order. When defining a task within the Group, the User specifies that the tasks be created as an Incident, Problem or RFC.

LiveTime Partner Update

LiveTime Software partners with Irish software solutions provider SERVAplex for ITIL service management delivery.

SERVAplex specializes in providing high-end software solutions for small to large enterprise customers. They offer the IT sector reliable, proven and best of breed  products and provide the expertise to implement and support the high-end solutions required to ensure IT infrastructure reliability.



SERVAplex maintain close relationships with its software and hardware partners, which enables them to provide an enhanced value service to all its customers. The SERVAplex sales and technical staff attend regular partner training courses to update and maintain the skills and knowledge required for our complete product range.

More about SLAs and SLM

Creating Service Levels that Work

It is one thing to know about how LiveTime manages Service Level Agreements (SLAs), but quite another to establish relevant agreements for your organization. This section presents some helpful tips on how to generate SLAs that are mutually beneficial to both the Service Desk and its Customers.

The initial discussion traces the evolution of IT departments into service organizations. It's important to understand how IT evolved into its service orientation of today, and how SLAs became a natural progression of this advancement. The second part of this section presents helpful tips on how to develop effective SLAs. The final portion explains the important steps to follow when negotiating SLAs.
Read more...