Request Fulfillment and the Stop Button

Depending on the way you manage the teams which support your services and the systems you have available to track and report on that performance you may have varying ways in which you review the time spent on providing service support.

There are basically two unescapable truths when evaluating team performance.
          1.     Your team wants to provide good service and
          2.     They want to look good doing it. (Not in fashion but in performance)

When requests come into the service desk there may be an efficient tracking stopwatch around the support team resolving the request themselves. Request comes in, is worked on and closed. However what happens when you start to have more than one group or several groups and the ability to measure components of work gets complicated?

For example:
For a particular request to be completed the request needs to have some tasks completed by the service desk and then the request is sent off to an application support team for completion. The IT support team operates Monday to Friday 9 to 5

Let’s suppose that this request came in towards the end of the business day (4pm) and let’s assume that the first part takes 1 hour. The service desk completes their piece and the request is sent off to the next team. Of course everyone is going home for the day so the request is in the application support queue.  The first thing the next morning the application team promptly completes the rest for the request within the first hour. Once this is completed the application support team resolves the request.

Theres a few ways to look at this:
·         That the request physically took two hours
·         From a customer perspective the request took from 4pm until 10am the next morning – 18 hours
·         That potentially from a reporting perspective the only team which gets credit for this request is the application support team and they either get the 2 hours timing or 18 hours.

The challenge with this is to identify areas for improvement within your queue management. It may look as though the service desk whips through tickets as they are only working on and resolving their own tickets. There may be no consideration (depending on your ticketing system) to review the multi group components. On top of that there are teams who are frustrated wishing for a “stop button” to only show what work that are accountable for.

I understand that there are many companies who are leveraging systems which account for this. However there are still others who are not. Taking a good look at how you manage your delivery of service through queue management will allow you to target areas within the escalation which may need to be fine-tuned.

At the end of the day it is the customer experience which we are looking to address. So whatever internal workarounds we need to employ to make sure we can target the queue and escalation process for improvements, we should strongly consider them.

I realize that this post is the tip of the iceberg and that I didn’t touch on SLA’s or first call resolution and a few other items but I look forward to diving into those in the next few posts. There are many areas, not just IT, who leverage services in this way. Feel free to connect with me and let me know what has worked well and where you are having some challenges.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

Labels: , , , , ,