Discussion on:
View:
Show:
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.
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.
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.
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.
- 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.
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.
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.
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))
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))
So you can call the customer and schedule your appearance, if necessary.
My pet peeve is being told it needs to be done "RIGHT NOW! We'll be waiting for you." and showing up to find the office closed or the contact gone for the day.
My pet peeve is being told it needs to be done "RIGHT NOW! We'll be waiting for you." and showing up to find the office closed or the contact gone for the day.
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.
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.
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...
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
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
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.
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.
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.
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.
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
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
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.
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!
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.
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.
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.
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.
We're suffering not because of the system in use, but because the information provided to us in that system is incomplete or incorrect.
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.
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?
At a minimum, a decent software package should interface with active directory or LDAP services.
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.
If the help desk techs aren't getting all the required information, provide them a script or checklist.
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.
I know... doesn't happen in a PERFECT world... but that's not the world I live in.
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
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
My response will be quite different if the equipment is under warranty and I am not the warranty tech.
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.
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.
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.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
