Vihreä Ruusu - Expectation Management

Vihreä Ruusu

Service Governance	Service Level	Processes and Practices
Mode of Operation	Vendor Relations	Availability

Suomeksi

Matti Grönroos CV

Matti Grönroos

Expectation Management

The ITIL framework defines a number of processes, practices and other entities, but it has left out one of the most important topics: Expectation Management.

Expectation Management is not about implementing everything expected. Instead, it is about making the end-users and Service Recipients know what to expect from the service, and when. Failures on Expectation Management are very common root causes for unnecessary conflicts.

A user might raise his adrenaline level and blood pressure by raging that the Service Desk does not serve him at 5:30 p.m. Instead, he or she would probably take a calmer approach if he or she had been told that the Service Desk is open between 8 am and 5 pm.

It is good practice to listen to the customer, and this is often done by sending a survey. One service element would perhaps get a good score of 3.72 of 5.00, but another one is well below targets: 2.89. Statistical of surveys credibility is often put to the test because the sampling rarely meets the good practices of statistics. This opens an easy way to plead: When something seems to be on the wrong side, statistical bias is an excellent means of defense.

Verbal comments often tell us more. However, when reading them, often the major feeling is disbelief: Are these comments about the service in question at all? This is often an indication of failure of Expectation Management. The users are expecting something from the service that is not even thought to be delivered.

Frequently seen messages of dissatisfaction are, for example

The Service Desk is not open when there is a need. Thus, the service provider is bad. (It has not been agreed that the service desk would be open outside office hours.)
I tried to use the system, but it was down. Thus, the service provider is bad. (The normal maintenance break was ongoing, and the user was not aware on it.)
I had a problem, but the only one helping me spoke English only, not my language. Thus, the service provider is bad. (That's right, your employer wanted the support to be provided from a country with a favorable cost level.)
My laptop is unable to print to the nearest printer, and help will not be available until the day after tomorrow. Thus, the service provider is bad. (The incidents of individual users often get the lowest priority in the SLA. The day after tomorrow may even be overquality, because the SLA allows a resolution time of four days.)

However, complaints should not be treated in the traditional way that the users are a bit stupid. Complaints are the cheapest way to conduct market research for the participants, and they quite often reflect the real needs of the user population.

There must always be a limit to services scope, service times, service levels and such attributes, and drawing a limit is usually a trade-off between costs and value produced. It is very important to make information of the content of the service contracts and their limitations available to the users. In this way, expectations are better matched to what has been agreed upon. The statistical significance of the surveys will improve, and the dissatisfaction caused by false expectations will be reduced.

In addition to the service hours, the Incident Management priorities are a common pain point. The SLA might be very complex. Still, the key principles shall be presented briefly, and in understandable language.

Example

Very Critical: NOW
Critical: in four hours
Medium: in 16 hours during service hours
Low in 16 hours during service hours

In addition to this, criteria of one or two sentences are needed to explain the urgency categories. Such a story shall make the users understand that even a major issue of a single user will not get the top priority in a big organization.

Most outsourcing contracts have a statement that it is the customer's responsibility to inform their organization about the content of the contract. For some strange reason, this almost always is not done. Especially when the Service Recipient (e.g. the IS/IT function) and the end-users are not the same people, the unnecessary critics might face both the vendor and the Service Recipient. That is why handling this matter properly is the interest of both contracting parties.