Skip navigation

Geek Speak

4 Posts authored by: chriswahl

8020-rule.jpgAs we wrap up the fourth installment of my Help Desk Adventure Series (I'm going to trademark that), I've described the journey from building out a help desk, defining SLAs, and incorporating workflow automation. Looking back, I think the one resource that was left out from this discussion was time. This resource is finite, difficult to find, and often buried in other daily tasks. Ever hear of the 80/20 rule? It's a slightly modified idea taken from the Pareto Principle: that we as IT professionals spend 80% of our time on trivial tasks, and 20% innovating (and providing some real impact). In some of my positions, it might as well be the 99/1 rule (or the 100/20 rule, in which I spent nights and weekends on the innovation part).

 

How did my team and I get the time to build out a new help desk system? I made a few "bold statements" to management to help get this off the ground and created some daily team exercises. Again - support from the upper echelons is critical!

 

  • The help desk, and related SLA and workflow creation, was considered an IT project with time allotments. We could budget team time towards the help desk and could give it priority in the queue.
  • The team would cover for one another when other issues arose. For example, I would spend time working issues on the call center floor so that a member of the team could focus on building a workflow. Broken concentration kills innovation.
  • I used the term "technical debt" quite often: this means that if we put off a help desk now, we pay for it with more work later. We wanted to pay off our operational debt quickly and efficiently.
  • A morning "red zone" meeting would be held at the start of the day. We'd review the backlog of work to complete and determine what we wanted to get done that day. It was also a great time to figure out how we could best help each other with various daily tasks, and communicate progress.

 

Knowing that it's very difficult to carve out time for any new work, I'm curious if you have any other tips to add to my list? How have you managed to free up time for your help desk creation, updates, workflows, or just general tasks that make your help desk better?

flow_charts.pngNow that the IT team has established a help desk and have SLAs defined for various requests and workflows, it was time to get proactive. Perhaps using the data stored in the help desk could further build a sort of analytics engine for making better decisions? This idea came from one of the IT team members, as he saw certain trends that none of us really could.

 

For example:

  • Which activities are the most frequent, or the most time consuming, and is there a correlation?
  • Could we find ways to proactively automate a number of frequently occurring requests, such as password resets?
  • Was there a way to extrapolate our hardware replacement rates to build a reasonably accurate forecast for next quarter (or next year) budget numbers?

 

It turned out that a number of workflows could be created to solve / remediate requests, with our help desk system acting as the front end interface. Password requests ended up being the most common, and so we assigned non-IT supervisor staff the ability to issue time sensitive password resets for their pods (their teams) once per day. The resets were still audited to ensure no funny business took place, but alleviated a fair bit of pain as a call staff member would forget his or her password right as they were about to begin their shift. Interestingly enough, we found out that many employees were getting by this by sharing a password or requiring a supervisor override the login for our VoIP system. As such, our delegation of password resets closed this loop and gave us further visibility into the problem.

 

What sort of workflows have you built, or wish you could build, around the help desk system in place? How would you use workflows to offload some of the "manual, heavy lifting" off you or your team?

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?

mail.jpgI've held a number of different positions at companies of varying size, but one instance clearly stands out in my mind. Several years ago, I had the distinct pleasure of managing a very sharp IT team for a mid sized call center. This was the first time I had ever officially managed a team, being traditionally a very hands-on tech guy.

 

When I began my adventures in this role, the company had rapidly grew from a small-sized operation into an environment with hundreds of staff members handling calls in each shift. It also meant that the current status quo for reporting and tracking issues (sending emails to a distribution list) would have to go; it simply didn't scale and had no way of providing the rich sets of metadata that one expects when handling problem resolution like a help desk ticket can provide.

 

I was challenged with fighting a system that was very simple for the end users but mostly worthless for IT. Broaching the subject of a ticketing system was met with tales of woe and that it "wouldn't work" based on past attempts. I felt, however, that introducing a help desk ticketing system simply required a few core principles to be successful:

 

  1. A simple process with as much abstraction away from "technical jargon" as possible.
  2. Buy-in and participation from the top echelons of the company; if the top brass were on board, their subordinates would follow suit.
  3. An empowered IT staff that could influence the look, feel, selection, and direction of the help desk system without fear of retribution or being iced out as wrong or "stupid."
  4. And, probably most important of all, faster resolution times on issues that went through the help desk through various synergies from related metadata (tracking hardware, software, and historical trends).

These were my four ideas, and I'll share how things went in my next blog post.

 

What about your ideas? Do you have a story to share that explains how you got your team on-board a new help desk system, and if so - how did you do it? :-)

Filter Blog

By date: By tag: