Why more Service Desk tickets might be a good thing

The Service Desk is often the interface between IT and Users. It’s a one-stop-shop for all IT requests and incidents. It logs, audits and categorizes tickets and is often used as a performance indicator for overall IT performance. So why would you want to increase the ticket numbers? Let’s look at the traditional way the Service Desk is used and how we can use it to our advantage.

The Service Desk is often the interface between IT and Users. It’s a one-stop-shop for all IT requests and incidents. It logs, audits and categorizes tickets and is often used as a performance indicator for overall IT performance. So why would you want to increase the ticket numbers? Let’s look at the traditional way the Service Desk is used and how we can use it to our advantage.

I Want!

Users want things, from a new mouse to software applications they need for a new project. If we take something as simple as a software request, we can track a generic process of what should happen to give them what they need. I say should, as this assumes the service desk both knows and follows the process for approvals, licensing, procurement, and delivery mechanisms for every piece of software the IT department delivers.

In reality, there are around 15 steps in a simple software delivery process. To understand why it’s actually this complex, we need to look at the reasons behind the process. As well as ensuring a scalable and repeatable process, a large part of the reason for using a Service Desk is to create an audit trail to show clearly why things happened and who authorized them.

The statistical information is used to improve the efficiency of IT delivery, or more often, as a Key Performance Indicator (KPI) for IT services. It’s the latter reason that often has the focus, we can measure the workload on IT and the efficiency of delivery, often as a sum of tickets and a measure of time to close and these lead to phrases such as “do more with less” or “improve first-line close of tickets”. The mistake here is that software delivery is not just an IT service. In some ways the IT department is the smallest part of the delivery chain which also includes business managers, procurement officers and end users. Just looking at the statistics in isolation can give a false view of what’s actually going on. It’s also a view based on how well the service desk staff follow process, categorizing the requests, and how they felt when logging the 100th software request for ‘Adobe PDF Reader’ that day. The data is only useful if it’s correct and properly categorized.

Increasing the number of tickets

If we increase the number of tickets we can be shown as doing more with less. If we can reduce the time to close each call we are increasing the efficiency of the department. If we can do it correctly every time, we improve customer satisfaction. And if we categorize and follow the process, we can report our KPIs back to the business. In essence, it’s in IT’s interests to increase the volume of tickets, we just don’t want the work that comes with it. So how do we increase both the volume of tickets and quality of data points without increasing additional burden on the Service Desk team? One word: Automation. The software request process is a great place to start when looking at the benefits of automation in the Software Asset Management (SAM) arena.

The real value of a Software Store

By introducing a Software Store, we can effectively remove many of the software-related requests from the Service Desk ticketing system, but without actually removing them, if you follow. While the ‘tickets’ still exist, the workflow is automated by the Software Store and thus, as far as the Service Desk is concerned, they are just data points that require little or no manual action.

If 10% of your current Service Desk tickets fall into this category, then we could immediately show an improvement:

In summary the question is not ‘should I implement a software store’, but ‘how long can we continue without one?’

IT is moving to become a provider of services and as companies move to Cloud we have to ask how long a department can survive without adapting a service approach.