Service Desk Improvement: Part 3

This post is the third of the three. You can find the other posts at:

• Service Desk Improvement: Part 1
• Service Desk Improvement: Part 2

Background

The client is the IT support organization for a very large outsourcing company. They run many different service desks, and support teams. Some of the service desks deliver internal support; others are used by external customers. Some are dedicated to single customers; others are shared by many customers. Some provide a very basic service that simply logs incidents and dispatches to level 1 support; others provide more expertise with a high first-time-fix rate.

This organization is subject to the same pressures as every other support organization I have worked with recently. They need to cut costs, but this mustn’t lead to a reduction in service. In fact, they need to improve service levels AND customer satisfaction while cutting costs – an apparently impossible goal.

In the third of my three posts, I’m going to discuss the importance of proactively communicating with users before they chase you to find out what is happening with their call. I’m also going to point out some of the ways in which the ITIL Practitioner Guiding Principles helped to inform my thinking as I worked with the client.

Chase call capture and metrics

The client told me that they needed to find a standard way of capturing information about chase calls, because these led to distorted call statistics. Further discussion clarified why this was a significant issue. When a customer called one of their service desks to enquire about the status of an existing incident or service request, the desk generally logged this phone call as a new incident, and then closed the incident as soon as they had given the user an update. Since there were known to be a lot of chase calls, the service desk metrics generated accurate but highly misleading data. It didn’t reflect how well the service was performing in relation to solving customer issues; the metrics didn’t even provide information about the number of chase calls that were received.

Of course, I did, as requested, talk to the customer about better ways to capture information about chase calls. As I explained to my client, methods for tracking chase calls depend on the tool used by the service desk. There are some tools that log customer contacts separately to incidents, but still link each customer contact to the relevant incident. This facilitates very simple reporting. Other tools don’t have this capability; in which case, you need to do something different to capture the data. Some organizations manage this by logging a new incident for each phone call, but then closing the incident with a status that indicates that it was a chase call. While this is not completely satisfactory, it does allow the reporting to distinguish between chase calls and real incidents.

However, I could not simply respond to the client’s focus on a narrow issue – how to capture data about chase calls – and leave it at that, because improvements in collecting data about chase calls would be of limited value. Instead I had to help the client focus on value, by drawing attention to the underlying issue. This involved talking to the client about why chase calls are in themselves problematic, and what can be done about them.

Whenever there are chase calls, tracking them isn’t the major issue. The major issue is why they are happening in the first place. Chase calls cause significant cost and quality issues. If users are calling to ask for an update on the status of their incident or service request what this tells us is that the service desk has not been communicating with them effectively. A chase call means that both the user and the service desk are putting time and effort into doing something that should not have needed doing. This is a waste of precious resources that could have been put to better use, and results in costs that are higher than they need to be. Chase calls may also indicate that users are getting updates that don’t match their expectations which will have a negative effect on levels of user satisfaction.

It is vital to communicate with users pre-emptively. Do it BEFORE anyone feels the need to make a chase call, do it effectively, and do it transparently. Here are some strategies that have worked for other organizations:

• Send an email whenever any incident or service request is logged – You should tell the user when they can expect an update, and then make sure you send the update as promised. Some organizations just include information about the SLA commitment, for example they may say that this incident has been logged at Priority 3 and therefore the service desk will respond within three days. Some great service providers also include information about the typical response time, while noting that this may not be achieved for this particular call. For example:
  
  “Your incident has been logged at Priority 3. Over the past three months we have resolved 95% of Priority 3 incidents within two days, but our commitment is that we will resolve them within three days. We will send you a further update within 24 hours.”
  
  (Design for experience; Be transparent)
• Provide automated email status updates at regular intervals – The frequency of your updates should reflect the urgency and priority of the call. Even an update that simply says no progress has been made and another update will follow in 24 hours is better than not communicating. (Design for experience; Keep it simple; Be transparent)
• Send a status update every time there is a change to the call – This means your IT staff must provide high quality updates that can be emailed to the customer without embarrassment! (Design for experience; Be transparent)
• Provide users with a way to check the status of their outstanding calls via a web portal – It is also a very good idea to provide a link to the correct URL in an automated email when the call is logged. This is a great example of how you can offer a customer multiple communication channels, as discussed in Part 2 of this series. Even if the customer has chosen to log the incident by phone they may prefer to check for updates using a web-portal. (Design for experience; Keep it simple; Collaborate)

Conclusion

You will have noticed that, as well as answering the question my customer asked, I also addressed the real underlying issue. This is because I applied the guiding principles Focus on value, Work holistically and Collaborate to the consulting service I was delivering to my client. I thought about Start where you are, which is why I started by providing a specific answer to the question that I had been asked, but I then went beyond that to help my client see the need to Focus on value and Be transparent when they deal with their users.

If you’re planning an IT Service Management (ITSM) improvement initiative, then make sure you’ve read the ITIL Practitioner guiding principles, use them to help you think through your options, and see if they can help you improve your decision making. Please let me know how you get on.

See our ITIL Practitioner certification and ITIL Practitioner Nine Guiding Principles sections for more information

Read the other posts in this series

Service Desk Improvement - Part 1

Service Desk Improvement - Part 2.

Read Stuart Rance's other AXELOS Blog Posts

How does 'Focus on Value' relate to the rest of ITIL Practitioner Guidance?

ITIL® Practitioner - Focus on Value