Nothing is Urgent

June 14, 2011

Back in 2004 (about 23 internet years ago) I started working on a cool priority management project. We were trying to build a hybrid application that was part helpdesk, part bug tracking, and part priority management. We basically built an internal ZenDesk on steroids.

We were using a HelpDesk tool at the time and we baked-in a lot of those standard helpdesk features that you see everywhere. One of those features in particular was the ability for a user to enter a ticket with a priority (low, medium, high, urgent, If you don’t fix this now the world will end).

I observed almost immediately that just about everyone would choose the earth-shattering, world-ending priority if given the option, making the priority system completely useless.

Today I switched the SideBox support site from ZenDesk to Tender Support and I was reminded of the pain of giving users the ability to prioritize things with this KB article from Tender: Why don’t you have priorities?.

Priorities seem great, but…

When you are first starting out with support, having priorities seems great because it is easy to build a work-flow around a few support requests. The engineers will work on the priority one stuff now, and will get to the other stuff later. What quickly happens is that there is always new stuff coming in and thus always new priority one’s. So what happens to the lower priority stuff? Well, those get knocked out if there is time. But there is never time. The users realize this and so they make everything an urgent priority because if it’s not urgent, then it won’t get done. When everything is urgent, then nothing is urgent. You cannot prioritize a list where everything on that list has to be done first.

Don’t let users prioritize

This KB article sums this up best: >We have found that giving users the option of noting their priority results in them selecting the most urgent one, most of the time. This field really only serves as a place for people to vent their >frustration, and complicates the new entry form until you have eight mandatory fields and even-more-pissed-off users.

We took the ability to prioritize away from the users. This caused a big stink at first but after the users figured who moved their cheese, everything was ok. What this really did was forced IT to analyze each request and determine where it should go. Sometimes you don’t know. Sometimes you’ll get a request about a broken light, only to discover that the light was not plugged in O-o. No matter what, someone has to manage the incoming stream. I think this responsibility should rotate around IT so that every feels the pain equally but if one person handles it, that’s fine.

This opens-up more conversation and collaboration. If a user sends in a request and the person responsible for filtering new requests doesn’t know how to handle the request, he or she gets to ask around, talk to users, etc. You know, network a little… This can lead to great knowledge sharing for everyone; users included.

Educate

I am a user so I can speak to this with confidence. When you have a problem, nothing else matters. >I don’t give a shit if the system is down. That’s not my problem. My problem, which I sent to you, needs to be fixed, yesterday.

The fact is that to a user, everything is important. If it wasn’t then they would not waste the time to tell you about it. They don’t care about other problems. Why should they?

Back to the KB article: >In our experience, not providing this field means that your users will put “URGENT” in all their titles until you educate them that all requests are, in fact, a priority, since that’s what we’re doing – supporting their requests

I don’t think this can be avoided with traditional HelpDesk systems and the culture that goes with it. What needs to happen is education. Educate users that everything is a priority and deliver on that. Don’t be afraid to be honest with users. Transparency rules even if the user could care less. If you want to deliver four nines to your clients, then let everyone know that IT drops EVERYTHING for system hiccups and nothing else matters until those hiccups are solved. A user might not like that but it is better then giving them the feeling that their problem is being looked at now because they marked it as urgent when the fact is that it’s moved to some back-log and wont be looked at for a week, or a month, or longer…

Just remember that no matter how many emails, or blog posts, or KB articles that you write, users will eventually forget how the system works. Education must be constant and ever changing. Clever users, like myself, will put filters on your annoying emails about how to use the support system, so change them up from time-to-time.