IT Policies

What info should help desk call tickets contain?

Jeff Dray's gripe with help desk call logging systems is that you often get a lot of unnecessary information with them, but the vital stuff is left out. What would you make the required fields if you were to design a job ticket?

My constant gripe with help desk call logging systems is that you get a lot of unnecessary information with them but the vital stuff is often left out. I’ve been thinking about what I would make required fields if I were to design a job ticket myself.

----------------------------------------------------------------------------

There are bits of information that you really need when you review a call ticket, bits of info that must be in the call -- some that are helpful and some that, frankly, nobody knows why they are recorded.

Things that must be included in the log:

  • Caller’s name and phone number. It might seem obvious, but you would not credit the number of tickets that have come my way with no contact info on them. It doesn’t leave me much room to maneuver; the only thing that I can do is wait for them to complain that I haven’t arrived so that I can respond. I also like to have the name of the person I am to see, rather than the person who signs the checks. In the past we had a problem with the logging system where the name of the previous person to log a call appeared by default in the logging screen. A moment of laziness led to some highly embarrassing moments when I arrived at a job and asked for the person whose funeral the staff had just returned from. I never want to feel that awkward again.
  • Caller’s location or address. I don’t need to know the address of the department that pays the bill, the person who signed the original order, or the company’s head office. I need to know where the equipment is that I have to look at. Again, it sounds obvious, but this has happened so often it hurts.
  • The equipment affected. If the customer has several of our products, it is important to send an engineer who is qualified on that particular equipment.
  • A full but concise description of the fault. I would prefer the call taker to let go and write more here rather than anywhere in the log. Writing “Not working” or “Making a funny noise” isn’t much help to me.
  • The company name that I am looking for. The name of the parent company is not helpful. I need to know the name that they are trading under, so that I know which door to knock on. It surprises me how many companies trade under another name to the one they use for paying bills and how hard it is to get our help desk to understand the importance to a field engineer.

Things that are useful in the log

  • An idea of the age of the equipment. If a problem is occurring with a new machine it could be anything; old, worn-out machines have fairly predictable problems. Also, there is nothing to be gained by lavishing hours of care on a machine that is two days from the end of its lease, a quick fix will do in these circumstances.
  • The usage it was being put to. If an address printer is jamming with C5 envelopes, it is not helpful to test it with DLs. It takes a lot of experience to learn the right questions to ask, but asking them can save a lot of time.
  • Has this happened before?
  • And more importantly, how did I fix it last time?

Things that are there only to confuse me:

  • The customer’s account number.
  • A twenty-five digit reference number that relates to a back office system that I have no access to.
  • The name, address, and phone number of the person who placed the order five years ago.
28 comments
plaidaddictt
plaidaddictt

I know this will come across as a bit of a Doh!, but... It really does depend on how well the user communicates the issue. And how well the technician listens to what the user is trying to say.

jrgwels
jrgwels

In my company, the Help Desk has a script of what to ask and all too often the tickets need to be sent back to the help desk because they work on quota more then quality. How can I possibly send out a technician to work on a computer for Joe in New York? I have to return it listing everything that is needed, last name, address, floor, building, column and seat number. The worst offender is someone that has been working for the help desk the longest and will submit a ticket with a New York area code, address in Seattle, WASH but city of West Palm Beach and a state of OH. I don't know how many times I've sent it back stating, EXACTLY where is the device located.

NickNielsen
NickNielsen

My response will be quite different if the equipment is under warranty and I am not the warranty tech.

barrycs
barrycs

Hi Jeff, I would think that a catalog of services and a configuration management database would help you out, if it hasn't already been mentioned. Barry

GSG
GSG

You'd think that would be obvious, but I get notified with info like this: "someone called and said isn't working right." OK, so who called? Am I supposed to start at the top of the phone list and go through all 1000 people to try to find the right one?

hanker.for.a.hunk.of.cheese
hanker.for.a.hunk.of.cheese

I've read and everyone has suggested the fields I would collect. A couple of things: A Front end display for the tech and a front end search engine for the tech. Everyone has touched on this by what information they suggested, but I would just like to add that the FED should show how long the ticket has been active and to be able to search all resolved issues for past incidents for newer employees. Also, you might as well start building a reporting system because it's inevitable that management will want ongoing reports for their pretty meetings.

lammwa
lammwa

You people are a few years behind or in very small IT organizations. Incident Management System, Customer Database, etc. These are all part of a modern IT environment. This information you mention is a "given" for these environments...sorry you are still suffering.

blarman
blarman

I work with a lot of not-so-technically-savvy people, so I have to keep things very simple and drag the answers out of them. Things I collect: Who is affected. What they are trying to do. What they _expect_ the system to do. What _actually_ happens. On my end, I also collect who calls, when, when the problem was resolved, and the resolution.

sidekick
sidekick

This was hinted at, but I think it is important to be able to search previous tickets for the client to see if this happened before and how it was fixed, or if something was done during a previous visit to contribute to the problem. I have had many times where another tech called me to ask me what I did a month ago, and I end up looking at my ticket to tell him, which he could have done himself in the same amount of time it took to call me.

zentross
zentross

That is a question that I have been wrestling with myself for the past four years or so. I have come to the conclusion that it is determined solely on the industry and level of service to be provided. In all cases, proper contact information is critical. The correct title of the person, phone number, e-mail, and (possibly) IM are the bare minimum. It sounds to me that your specialty is supporting a hardware vendor and, having done so myself in four previous lives, I have to agree whole completely with your assessment. I now work in education where the rules of support vary slightly. We need to know the building, department, system type, operating system, version, problem description (still have trouble getting good ones from student workers), and the best time to contact professors when they are the customers in need. If it were a software warehouse, I would expect that they would need to know the operating system and version that their software was running on, which of their software packages and its version, in addition to a statement of the observed behavior. Just my $0.02

drakekrummrey
drakekrummrey

If in an environment where Remote Support is possible... I always like to require the host name of the infected device... so basic network diags can be done ahead of time.

davidt
davidt

Besides the obvious basic information (well-defined above), when working at Dell years ago we used a 3-part system: Problem, Discussion, Solution. The Problem was pretty much what the caller said it was (accurate or not). The Discussion was the meat of the ticket, describing the troubleshooting process. The Solution area was just that.

bfpower
bfpower

I think of this as level II tickets, since that's my role. If I had to design a ticket, I would include (not in a particular order): - name - location (for multi-site companies) - contact information - preferred method of contact - impact level (single user/multi user/department-wide) - severity level (annoyance/slowdown/outage) - urgency level - resource affected - problem description - attachments (for screenshots) - troubleshooting performed (journal style with time stamps) Anyone like to add something? I know this doesn't cover everything for everyone.

wfps1946
wfps1946

When giving the location, not only the company/building/correct address/ but also a cubicle or office number and / or floor number would be very helpful when wandering around in the mouse maze trying to locate someone.

zentross
zentross

At a minimum, a decent software package should interface with active directory or LDAP services.

NickNielsen
NickNielsen

The problem being discussed in the original post is not what system to use, but how to make sure the call center puts the correct information into the system. We're suffering not because of the system in use, but because the information provided to us in that system is incomplete or incorrect.

suewhitehead
suewhitehead

I support the same 200 users all the time, but I support just about everything in the system. So I can't remember every problem or solution. But I keep good records so I can look up what I did before. It saves so much time!

NickNielsen
NickNielsen

Impact, severity, and urgency together? Why have all three? That's just more data to process. Somewhere in your contract or policies, there should be a chart that allows the call center to assign a call severity based on the type of equipment and the impact of the outage. In my experience, the equipment and the impact determine the call severity and, by extension, the urgency of your response. In my current job, I support grocery stores and work with four severity levels: 1 - Major outage, no sales capability or sales capability severely impaired. This is a critical equipment or system failure: server, router, fuel center, store network, point-of-sale system, or other critical store system. 2 - Outage, sales capability impaired. A critical store system is not operating at full capability. Some examples: the network has a bad switch, a pharmacy printer is down, a store department (e.g. produce or deli) has no functioning service scale, or more than a certain percentage of cash registers are down, etc. 3 - Minor outage, has some impact on sales capability. Some piece of non-critical equipment has failed: cash register, service scale, store PC, general use printer, scanner, mouse, keyboard, etc. 4 - Annoyance, affects store operations but does not interfere with sales capability. OR, in short, 1 - Store down 2 - Store losing money 3 - Store not making enough money 4 - Store making money, but employees pissed off In my previous jobs, the severity of calls played out much like this: 1 - server or network down. (Impacts entire building, floor, or department) 2 - Server or network impaired, printer down. (Reduces capability of building, floor, or department, department cannot print) 3 - Printer impaired, user down. (Some users cannot print or user cannot utilize PC) 4 - User impaired (Yes, I know, they all are, but you also know that's not what I meant! :) ) edit: clarify

user support
user support

I don't think any call tracking system will be perfect. The information in the ticket will depend on the organization or self training level of the person taking the call, email, fax or walk up situation and entering what is pertinant without altering the meaning too much. Here is an extract of an article that I keep by my desk that I got from TechRepublic a while ago. It may still be available in their archives. Gather call information more effectively with the 5Ws and an H by Janice Ward/TechRepublic One technique I find particularly effective is outlined by Randal S. Pearson is his book Effective Information Gathering Techniques. Pearson?s technique is the ?The 5Ws and an H,? and it consists of: 1. Who: Person/Department 2. What: What is wrong? 3. When: When did it happen? 4. Where: Location 5. Why: Why did it happen? 6. How: How did it happen? The 5Ws and an H technique builds upon questioning skills learned in grade school. Its simplicity helps ensure the right questions are asked and the right information is recorded. The 5Ws and an H technique provides several benefits: ? It?s simple and easy to learn. ? It develops questioning skills that avoid yes or no answers. ? Its use as a model for call logging ensures complete information. ? It keeps users from forgetting key pieces of information.

romieship
romieship

Everyone included so much good information that I think just about everything was covered well. Just a couple of notes that may be my personal preference; 1. Determine if there is a temporary workaround for the immediate time if the trouble can't be resolved on the phone call or if this is a complete work stoppage in addition to the position of the person affected. Even though we may try to treat all callers equally, I admit, if it the company president or someone from that office, I place the incident much higher on the priority list than if the custodial staff can't get to their e-mail. I also like to have some information on any recent modification or changes that may have been made either by the IT department or the user to the system. Thats about it though.

bfpower
bfpower

I don't have this problem as much, since I cover the same 100 users consistently. But I see how this would be a major thing for someone who covers multiple locations, or who has hundreds of users.

Jessie
Jessie

When people are responsible for updating their own contact information, the GAL gets very outdated. At the very least, there needs to be a space for a contact number to be manually entered. I know... doesn't happen in a PERFECT world... but that's not the world I live in.

NickNielsen
NickNielsen

Your suggestion will only work in a large business with in-house support. Small and medium businesses often find a staff technician too expensive and contract to an external service provider for support. If the help desk techs aren't getting all the required information, provide them a script or checklist.

bfpower
bfpower

Severity of the problem lets you know whether the system is still usable or not (any noncritical system that is usable can wait until the critical or nonfunctional ones are fixed). Impact tells you how many users are affected. 50 users all losing 5 minutes is more important in some ways than 1 user losing an hour. And urgency tells you how critical the system itself is to the business. For instance, we have a large number of resources here, and a broken fax machine sitting next to a perfectly good one is less urgent of a concern than a laptop that is going out the door to another state the next morning, or than a mission-critical application server that is down. The help desk does use a matrix to figure these things out. However, the figures are still included on the level II ticket, and can be useful to me if an unfamiliar system were to come up. Between the three of them, I get the fullest picture of the situation. I do agree that the way you described it works well. The most important thing is clear communication between the client and the tech. In my case, I'm a corporate tech, so I am always dealing with the same 100 users. Not bad in some ways.

inouyde
inouyde

I always try to get as much detail as possible, especially if there's a chance I'll have to hand off the problem or escalate it. Can't stand voicemail from end users who say, "I'm having a problem... can you call me back?" Feh...

Phantom2487
Phantom2487

Almost everything has been covered here except one simple question. When would you like me to fix this problem. I hate it when I show up and the customer is in a meeting... (I do comp support in a single building and 99%+ of the problems only occur when the customer is driving the comp (So i need them there))

bfpower
bfpower

Our help desk is offsite and doesn't ask for timing information anyhow. Usually, I check with the user to make sure they are available - most issues can be fixed via phone anyhow. I find the same thing - a user sends me an email (not even trying to go through the help desk) and then leaves on break. Go figure.

NickNielsen
NickNielsen

So you can call the customer and schedule your appearance, if necessary. My pet peeve is being told it needs to be done "[b]RIGHT NOW![/b] We'll be waiting for you." and showing up to find the office closed or the contact gone for the day. X-( X-( X-(

Editor's Picks