Showing results for 
Search instead for 
Did you mean: 

Defining Service Level Agreements (SLA) for Successful Help Desk Operations

Level 10

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?

Level 12

Everyone feels like their ticket is high priority

Oh, so true...

We are currently trying to devise a workable time table but right now it's more "right away", "later" and "probably never".

Level 12

I really like the "Hardware now told us stories about themselves" bit. That's amazing. Did you end up pulling data from an inventory or other CMDB to track that hardware history?

The help desks I've worked with in the past have always set SLAs based on organizational stature. But that led to an ever-evolving hierarchy that required a lot of work to maintain. Initially, we had VIPs. But then a subset of the VIPs became SuperVIPs. And when they opened a priority 1 ticket, it had to be called a Priority 1 - Emergency ticket based solely on the user, not the condition. So in effect, a Director's inability to print to a local printer, and an Exchange server that just went belly-up, had the same exact SLA and priority in resolution. #crazytown

Level 12

Oh, I'm glad I've been able to dump the VIP mentality here. I've once had this discussion with a director (at a previous job).

- "Could you please message your team that their server rebuild will have to wait until I'm done fixing your printer ?"

- "What ? I can't tell them that !"

- "Well, neither can I"

- "Ok, come back when you're done with the server..."

I've set my limits when I arrived here, and they have been well received. The only thing that's still a VIP priority is communication. Desk phone, cell phone, email, if it's a director it gets fixed right away. They wait in line for everything else... like everyone else... mostly.

Level 15

I've generally found that tying your SLAs into what your vendors can do is step 1 (you can't fix things faster than you can fix things...)

But secondary to that, I've seen great success with removing the user from the SLA and tying in the cost to the business. Allowing management to understand how a single printer may cost $ in revenue, while a server costs more like $$$, makes a world of difference.

Level 10

Those are some realistic priorities

Level 10

As more tickets came in for hardware related issues, we could see a story develop around the hardware. Perhaps the computer is dying a slow death, and has needed 3 different parts replaced; let's just recycle the box and get another one to avoid bleeding repairs. Or one box kept overheating until we found out it was buried in a pile of blankets for an employee that got cold at her desk.

Level 13

One thing I've seen work well is rather than calling it "priority", to have an option where people have to match their issue to a description of the impact of the problem. Certain impact levels, such as those indicating enterprise-wide impact, are unavailable to the "common" user for assignment, and can only be assigned by IT.

Level 11

Ours is done by severity. Low-High. When it comes to a pc, server, printer or software issue our internal IT guys are right on it. However in the event one of our sites goes down our vendor who provides the fix could care less about their SLA. They know we are tied to them because of certain locations. I fail to mention there name just in-case I offend someone.

Level 11

Anything that affects credit cards or pay should be considered "high priority".

No audio on a temp's computer would be "low priority".

Level 15

Interesting.  In my experience, SLA's are the double-edged sword.  First, if you allow the user to set priority that always move towards high or emergency and second ensuring you have balanced IT staff to handle the variety of calls that hit the system.  The biggest hurdle I have encountered with SLA is the driving need to ensure some kind of communication back to the user.  Too often we get caught up in the triage and attempts to solve the situation that we forget to keep the customer in the loop.  For example, user calls and needs a replacement mouse.  Answer them, we will have someone swing by and take care of it. User says ok.  Four hours later they get there new mouse.  User is extremely irritated that they were unable to use the machine for 4 hours.  Real story was that after user hung up the phone, the entire printing system crashed and all hands on deck were required.  No one called to tell the user and since the user could not use their computer they did not get the message that the system was done.  A simple phone call would have helped calm the user down. 

So, when looking at SLA's I think the priority needs to be on defining communication levels and processes to keep the user informed.  They are more likely to be acceptable and favorable in their opinions of the IT department if they know what's going on rather than having to immediately solve their issues.  No user likes to wait and they want everything immediately.  But, reality states that this is not possible and we have to have an internal priority to solving problems.

I once had a client tell me his expectations.

     1)  Be on time.  If you tell me a time you be at my office be on time, if not call and let me know when you will arrive.

     2)  Don't lie to me.  If you don't know what the issue is or how to solve my problem, tell me the truth that "You don't know" but you will figure it out and be back as soon as possible to resolve the issue

     3)  Solve my problem and communicate with me

I took these to heart and always try to live by them.

About the Author
I'm a data center engineer who likes to virtualize things. You can find out more about me by visiting my blog.