Showing results for 
Search instead for 
Did you mean: 

Building a Positive and Encouraging Help Desk Culture

Level 10

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? :-)

Level 10

I've used several different help desk systems and as long as they have a good search feature, they will be successful. There's no reason to re-invent the wheel.

Level 12

#3 is a great point. No one likes to have processes or procedures forced upon them. If you make it clear that the adoption of a new system is going to be an evolution, not just a fire drill, you'll likely get more support for the change.

We're slowly rolling out ServiceNow at my current workplace. S L O W L Y. Most pushback is in the form of, "we tried that years ago, it didn't work, so it probably won't work this time, either." It's tough to fight through such institutionalized pessimism, but if you introduce functionality gradually, and deliver on the promise to improve processes, it can be done. At least, that's what I'm currently telling myself.

Level 17

I had one particular time when there was a debate on choosing ticketing system A vs B when helping to set up an IT helpdesk team, and get them into measurable metrics.  My biggest argument boiled down to what the system was initially designed for.  Having worked in call centers and helpdesks before, I had experience where a ticketing system was shoved into a software that was more setup for accounting and sales, than for tech and I wanted to make sure this didn't happen again otherwise techs end up resenting the fact that they have to use the system to begin with.  We ended up deciding on a system that was more tuned in to IT people that we could then data mine to get the information needed for the finance and sales groups much easier than had we tried to force a different system onto the team.

Level 9

Simplicity as well as buy-in through participation have been big for us. Documenting processes as well as vetting out any questions/issues with a team of testers gradually got them interested and on-board. As it is new technology, bringing in professional services helped as well giving them more confidence in the tool's capabilities and implementation.

Level 11

I worked for a small company called HeathCo. We didn't have a helpdesk application for ticket collection and we mainly resolved issues by email or someone walking up to your desk to report a issue. The problem with this approach was that some emails got lost in junk filters and there was no way to track going issues. We decided to use a program called spiceworks and it worked out pretty well. This program was not on the level of Remedy or Track-it but it was free and that made it easy for management to approve.

Level 15

Gotta love those professional services!

But seriously, in my experience, items 2 and 3 are more key than anything else. Without proper buy-in, you can spend the better part of a year working your tail off for a product that is really not utilized at all, or is blatantly hated by staff and/or management.

I would say that one other key is to let management and users have some input on design as well (harking on item 3 here). Management tends to be the primary recipient of your reporting, and users are your primary recipient of the product front-end. Allowing them to have input, within reason and technical ability of the software, can really change the attitude(s) towards the change at an institutional level.

Level 18

#2 bu-in and participation need to happen at lower levels as well...getting their input and participation in the build-out.

Then they start to have a vested interest in the end product.

Level 16

I usually tend to find that most of the "features" or resources needed are the ones that cost $0.03 more than the moneybags are willing to pay for... and therefore money is wasted on a sub-par system that can ALMOST do some of the things that would be beneficial... I reckon I will never understand corporate budgets... why we can spend 8000% more than we need to on a paper clip, but can't manage to approve the extra $0.37 for a proper system... lol

Level 9

I have only been through one re branding of our helpdesk system but the following seemed to help us narrow down our choices.

  1. Ability to quickly make tickets when busy
  2. customizable dashboards for agents/supervisors/managers
  3. easy reporting
  4. modular functionality
Level 10

That's good to hear. We actually tried a large number of products internally first, submitting tickets on behalf of users (behind the scenes), to make sure we were all comfortable with the process. I made it clear that it was a journey we would all be taking together, and so the team was rather excited to influence how the selection process went.

Level 10

Nice! There's nothing worse than trying to shove a square peg into a round hole. Definitely a good idea to pick the right tool for the job.

Level 10

Agreed. We also had issues where email threads would splinter off into smaller discussions, or folks would "reply all" each time and the staff would have an inbox bloated with chatter. Email is a poor substitute for a proper help desk.

Level 12

We transitioned from an outdated Remedy system to Supportworks. 

The additional Web Client interface is very useful.

Level 21

I completely agree with all of these items.  It is also helpful to quickly identify those members of the team that are more reluctant or resist change, if those people are not managed appropriately they have the potential to poison the rest of the team and even cause the entire project to fail.  Managing those folks doesn't necessarily need to be a negative thing, it can often mean just talking to them one-on-one about their concerns and how you plan to address them.

Level 11

Nice articular

Level 9

It would be nice if there was a feature that would get users to submit tickets instead of sending direct emails about issues. That's always the roughest part about implementing a helpdesk system.

Level 13

It's critical to know both your endgame as well as your plan (including timeline) for getting there. In our environment, the system we have was rolled out with promises of additional features (such as knowledge base) being turned up "later". Needless to say, "later" never came.

Level 14

I have build a help desk from the ground up that turned into a NOC.  Having all the user contact information and keeping tickets updated with current status is also key.  Also having details in the the ticket to be used for reoccuring issues.  There should also be a process to define exactly what group (or who) to assign the ticket to.  There should also be an escalation or de-escalation process.  Flags also need to be set with time limits, so none fall through the cracks.  Automate as much as possible.  You don't want a system that adds time by making the ticket process take too much time.  A priority system needs to be defined and there should be a way to "rush" critical tickets.

Level 12

We are in the processing of moving to a new platform (Web Help Desk).  Key for our team is mobility.  No one in the support team is really at their desk for any length of time.  So we have to have a solution that sends the information to the mobile device issued (tablet, phone).  This means additional setup for network, wireless etc.  Having an app on the device is nice too.

Level 11

We have had several ticketing systems. None to my liking but I since I don't have to enter as many as the help-desk personnel I can live with it. The goal was to be able to get further in depth on tickets and track the status and who has it. I'm not sure if anyone remembers or had a mainframe program called HDSK.That was the system we used back in the late 90's early 2000's. It was fast and speedy and didn't have to enter much. Now we have a very complicated system that I sometimes have to ask the help-desk group how to enter something in.

Level 11

You must have the upper management on board to make this successful. great post I completely agree.

Level 12

Still doing the "behind the scene" thing of filling the tickets ourselves but once the migration to our new AD structure is done (new domain across all sites) then we'll integrate LDAP authentication and let people enter their own ticket. It's been accepted and well received by management, so the path seems clear...

Now where's my box of ITIL books ?

Level 17

I have seen a couple of sides;

   As in the past, the old Ring the phone or email was the way to go. Shops small enough for this will keep folks coming by your office or peeking in your door with phrases like, 'You busy?' and 'Is there something going on?'

Places large enough for a Service Desk solution (note the ITIL jargon) do need a collaborative effort across the board. Management willing to find a proper and liked solution. Being willing to setup a sandbox and play or customize and find issues before going live with the solution will go a long way for your new application to be received. It will also help the buy-in and training aspects. The buy in must include a couple of key folks from other departments, and allow the user feedback to further customize to the users likeness. Gently tell them where their idea's will not take place, but keep their involvement close; as this will keep them as 'users' of this new system. Empower through training, empower through the finding process (allow your IT folks to view solutions and provide the feedback prior to choosing) .. now your IT folks are invested in the solution from the start. And don't forget that among all this technical stuff and implementation and horizon change for your end users that your end users are people also.

The ability for a service desk analyst to be empathetic and truly be understanding of your users and stick with them through the tough calls is derived from a mass of people and self management skills that even the most savvy of politicians have a hard time grasping some days. If the person answering the phone, or calling back when a ticket is input into the system is rude or even un apologetic about the user having an issue your ticket and/or call #'s will simply drop off. Word get's around fast that the 'Help Desk' is of No Help; and that's a rumor that is hard to combat regardless of the truth.

Level 8

I have to say this is one of the most true-to-life blogs and comment sections I've ever read on here. It's creepy how accurate and relative this article is. I'm fighting an identical war with identical though processes. So far, it's at least moving in the right direction. The Brass decided to allow us to trial Spiceworks since it obviously wouldn't cost us anything up front, so any improvement in resolution time would be an instant profit recognition. So far, so good.

Level 14

Couldn't agree more with this posting.  For us, the current environment want to lay blame on the software, which admittedly is bad, but the real issue is any lack of process or procedure.  ITIL is thrown around as a buzzword but that's about it.  Glad to see you have it under control.

Level 15

This is a worthwhile discussion as it seems no matter how good your help desk team members or how many problems they resolve per day, perception is always "do I have to call the help desk"  Getting further down the road, have an effective search and ticketing system, an effective method of dispersing consistent problem resolution methods, effective methods of communication to the users, and a consistent interaction techniques between the end users and the help desk. 

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.