"Have you tried turning it off and on again ?"
Solves 99% of said problems… :)

1. Telling someone they need to be polite implies that their conduct is inappropriate, which is likely to infuriate someone who feels they have a reason to be upset. They're probably not mad at you personally, but this approach definitely has potential to change that.

In corporate IT, your caller contacted you because they need to get something done. Your job is to do what you cam to assist, and that means both of you have the same goal. Empathize: ask questions about how the problem affects them. This can help you prioritize your work and often yields useful technical detail. Maintain an attitude that you and your caller are are in this problem together and you will find that most calls that start out emotionally charged become much more productive.

5. Usually, this step will only apply if you've hit a dead end and need to escalate, so don't go overboard here. As you gain experience, you will acquire an instinct for what kinds of details are potentially relevant, but generally speaking it is not a good use of your time or your caller's to track down every version. A quick export from the user's MSINFO32.EXE is often sufficient to analyze any system-specific details that your or your escalation point's research might need to track down.

8. Again, you don't want to waste too much time on this. You probably don't have time to exhaustively test the system for potential problems. If you've broken something, it's usually evident by now, and your caller will probably be quite happy to get back to work and take on responsibility for letting you know if the problem crops up again.

9. Seriously. Do this.

1. Telling someone they need to be polite implies that their conduct is inappropriate, which is likely to infuriate someone who feels they have a reason to be upset. They’re probably not mad at you personally, but this approach definitely has potential to change that.

In corporate IT, your caller contacted you because they need to get something done. Your job is to do what you cam to assist, and that means both of you have the same goal. Empathize: ask questions about how the problem affects them. This can help you prioritize your work and often yields useful technical detail. Maintain an attitude that you and your caller are are in this problem together and you will find that most calls that start out emotionally charged become much more productive.

5. Usually, this step will only apply if you’ve hit a dead end and need to escalate, so don’t go overboard here. As you gain experience, you will acquire an instinct for what kinds of details are potentially relevant, but generally speaking it is not a good use of your time or your caller’s to track down every version. A quick export from the user’s MSINFO32.EXE is often sufficient to analyze any system-specific details that your or your escalation point’s research might need to track down.

8. Again, you don’t want to waste too much time on this. You probably don’t have time to exhaustively test the system for potential problems. If you’ve broken something, it’s usually evident by now, and your caller will probably be quite happy to get back to work and take on responsibility for letting you know if the problem crops up again.

9. Seriously. Do this.

I used to work tech support for a retail point-of-sale system. One of my favorite calls was when a customer called to say that their OCR-A scanner had stopped working (this was quite a long time ago). After verifying that the scanner was plugged in, I had them turn the scanner off and on. Well, when they turned it off, I could hear it make its startup noise. I confirmed that they *thought* they had only turned the scanner off, not back on, but told them to try scanning an ISBN … and magically (to them) … it worked!

That just drove home that you really have to pay attention when taking support calls – and not to believe everything that the customer tells you. Not that the customer intentionally lies, but sometimes you have to interpret what they MEAN, not just what they SAY.

I used to work tech support for a retail point-of-sale system. One of my favorite calls was when a customer called to say that their OCR-A scanner had stopped working (this was quite a long time ago). After verifying that the scanner was plugged in, I had them turn the scanner off and on. Well, when they turned it off, I could hear it make its startup noise. I confirmed that they *thought* they had only turned the scanner off, not back on, but told them to try scanning an ISBN … and magically (to them) … it worked!

That just drove home that you really have to pay attention when taking support calls – and not to believe everything that the customer tells you. Not that the customer intentionally lies, but sometimes you have to interpret what they MEAN, not just what they SAY.

We are not customer service representatives. We are Information Technology Professionals, with experience in the field to enhance our classroom training. We are hired because we are skilled in our field, and keep our jobs because we are good at them.

We are not customer service representatives. We are Information Technology Professionals, with experience in the field to enhance our classroom training. We are hired because we are skilled in our field, and keep our jobs because we are good at them.

Eventid.net also saved my life a couple of times but I didn't know about the scroll down cheat on Experts-Exchange! Thanks for that.