The perpetual cycle of tickets
What’s the next evolution from the enterprise-IT “ticket process”? In what way will service-desk evolve to better allocate and analyse incoming, current and complete work?
Having worked at a variety of MSPs, ranging from SMB to $globalmsp, I noticed that there are common and re-occuring issues and mistakes that organizations make around their ticketing systems.
(The below is anecdotal regurgitation from a operations MSP standpoint)
Here’s the current process of how work gets completed:
There’s a few issues with that:
- Current workload is based around ticket-count/tickets closed
- As a result, easy work is cherry-picked, hard work remains
- This means the unassigned queue ‘festers’
- Most skilled staff left with most complex work
- This means they’re not closing many tickets
- Inaccurate performance data, which leads to;
- Incorrect business decisions made around resourcing etc.
Current workload based around ticket-closed
The big issue with this is that no two tickets are the same. A password reset is not the same as having to perform a non-authoritative restore of users and group membership in active-directory.
There’s also the issue of ‘praising’ tickets closed. If you get quick reports or announcements sent out each week to your service-desk, for who closed how many tickets, that unintentionally or subconsciously sets the KPI to “tickets closed” full-stop. This leads to:
The easy work is cherry-picked, hard work remains
This means that all of those easy password reset tickets are immediately cherry picked out of the unassigned queue. I mean, it’s great that work is getting complete, but the complex or harder/longer work just sits in the unassigned. The fact that there’s usually no form of authority to tell engineers/service-desk staff to do the work, if no one is made accountable then no one will do it. “Someone else will do it” is what people think.
Most skilled staff left with most complex/time-consuming work
This is fair enough. You’re not going to get your level-1 engineers to troubleshoot a complex group-policy issue. Likewise, if you have to re-design your Citrix PVS images in terms of size, you will need your Citrix engineers to do so.
Unfortunately, as above, if the subconcious KPI is “tickets closed”, then your most skilled staff won’t ever meet that KPI.
This de-motivates staff.
Inaccurate performance data etc.
Because no two tickets are the same, it leads to innaccurate performance data for who’s doing how much work. This then leads to incorrect business decisions (is your service-desk under or over staffed?)
What can be done to solve the above issues? Have a think about your environment, and what applies from the above. What would you do to fix it? It turns out this is somewhat of a unique topic, I couldn’t find much on the internets about this type of thing.
Tune in to part 2 where we theory-craft some possible ideas (Which has been tried and tested in a MSP)