tumblr_lxysu8rO3k1rnwfzro1_50031.pngIn an earlier post, I discussed the path to successfully implementing a help desk system for a mid sized organization that was new to the idea. Luckily, the hard work of my team and positive reinforcement received from management helped sell the idea further. In fact, I selected a handful of power users - you know, the folks that are "friends of IT" that are out there trying to get their work done - to test the help desk system. I also let it leak that they were using some very cool new system that gave them additional access to IT resources. Those not using the system were curious about this new system and actively sought us out to put in those "cool new tickets" instead of the old email system. It was a type of reverse psychology exercise. :-)

 

Now that users were actively engaged and entering data into the system via tickets, we had some more tough decisions to make around Service Level Agreements or SLAs. The top brass wanted to see results, after all, and those are easiest to swallow if wrapped in some simple numbers. It is hard, however, to define SLAs when all of your data is new and there is not much historical information to work with.

 

A few things we learned along the way:

 

  1. Allowing user-defined ticket priorities to influence which SLAs we could be held against was a mistake. Everyone feels like their ticket is high priority and requires the highest SLA. In the end, our internal IT team ended up learning how to prioritize tickets that entered the queue. The user defined priority was left in to make people feel better. :-)
  2. We ended up mimicking some SLAs from our vendors; if our server vendor offered a 4 hour replacement window, we would match that value (or go slightly above it, to allow for break/fix time after the replacement arrived).
  3. Having historical metadata wrapped around ticket objects - such as knowing how many times a specific phone had stopped working - gave us increased confidence to make actionable decisions. This helped go far beyond our "standard" 4 hour SLA because we could quickly pitch old hardware into a replacement queue, discard queue, or "fix it" queue. Hardware now told us stories about themselves.
  4. Being able to show our SLAs in hard numbers provided valuable protection against fallible human memory. It also pointed out our weak spots that needed improvement, training, or additional skill sets.

 

With that said, I'm curious how you offer Service Level Agreements to your help desk users. Is it a general tiered system (high, medium, low) or something more granular? How did you pick your SLA time tables?