One of the things we did was we took a couple steps to formalize how people access the IT help desk. Nothing fancy or new, just a simple policy. One of the keys to me though was asking users to set a priority for the ticket; High, Medium or Low. I defined these terms in the policy something like;
- High= interrupts business for multiple people, impacts finance, etc.
- Med= interrupts your ability to work, no work-around, etc.
- Low= everything else
I also asked for any associated deadlines, details, screenshots, etc.
But here is where things got interesting quick. And before I say anything else, I am not trying to say anything bad about our staff. This just seems to be human nature.
Requests came in, but the priority seemed to be driven by when they needed it done, not by the impact or importance. Because things get more important when you are faced with urgency. I need this by 1pm today, I am working on something for a Board Member that is going to be here in 30 minutes....
This is not a big deal when it is the occasional request, which is true for my org. They are typically good about leaving time and being purposeful. But this really got me thinking about the difference between urgency and priority.
The trick is that if you have too many urgencies, you can get to the priorities. This is where a help desk process can really help.
Track IT! If you are tracking all of your requests and work, you can look for these trends. You can see repeat requests each month at a deadline and anticipate them. Then make a change to your technology to address it. Automate the report.... Follow up with that department, ask them to request earlier... Simplify the tool to allow self help....
Expectations! Setting expectations in your help desk process will help drive the change needed. Tied to the priorities in our help desk process was a service level agreement. We plainly tell our users how quickly to expect support based on the priority of the ticket. The service level agreements will range from org to org based on available resources. And we told the why, to allow us to balance projects with big impact with the daily urgencies.
Definition! Taking time to write a policy, enforce it and define all terminology is not easy or fun. But is important. Simple definitions and ongoing conversations have a real, lasting impact on culture.
Address the problem, not the symptom. Not a new idea. Focusing on urgency will keep you focused on the symptoms.
We are also looking to formalize our tech project request, our tech project steps, data governance, business process documentation and so much more. We have to shift from urgency to priority to allow for impact.
My question is why aren't more topics like this at the forefront of our technology conferences, blog posts, webinars, etc? Basic technology support is still important.