I just received my first flame. Getting real hate mail is pretty exciting.

Plenty of readers have disagreed with me before. One or two have even called me a socialist, or Marxist, or something like that. Even the most passionate e-mails, though, have identified the subject and point of dispute.

Not this one. The first two words of the message were, “You are …” The remaining nouns and verbs don’t belong in a business publication. The message, if you’re curious, described my alleged double-jointedness and unsavory dining habits.

InfoWorld‘s readers are my customers, and I’ve often pointed out that customers are always right.

So I was wrong. Sue me. Change “always” to “usually”. (Not only am I not double-jointed, I haven’t been able to touch my toes without bending my knees since 1961, nor do I eat non-traditional foodstuffs.)

People who provide service to real, paying customers sometimes take calls from people who are a bit testy. That’s part of the job … up to a point. Beyond that point, the caller is abusive and the customer service representative has no obligation to listen.

(For those of you who act this way, some questions: do you think service reps set policy? Do you think they designed the feature you don’t like or the created the defect you’re trying to work around? No? Then why are you yelling and swearing at them? Companies pay these people to solve product-related problems, not to accept the anger and frustration you’ve PKZIPped and sent down the telephone line.)

Your staff members, dealing not with customers but with fellow employees, have no obligation to take abuse either. They do have an obligation to help solve problems, even when the person needing help is less than warm and friendly. Continuing our series on dealing with end-users, this week we talk about one-on-one interactions. Here are some tips that have worked for me in the past. I’m writing them for telephone conversations; they work just as well face-to-face:

Tip #1: Defuse frustration: You won’t have a productive conversation until you get past it. Empathize, and redirect attention away from the emotional context to the actual problem. One good technique: ask for microscopic detail. “I’m sorry you’re having a problem. Let’s see if we can get it fixed. Tell me exactly what you see on the screen.”

Tip #2: Focus on the problem, not the request: A caller may insist on a site visit, even when one isn’t necessary. Neither argue nor obey – redirect attention. Try this: “I’ll need to make sure I understand exactly what’s going on so I can dispatch the right person. Let’s start with what you’re looking at on the screen.”

Tip #3: Gather information first, and don’t argue: The caller really is experiencing difficulty. Find out exactly what the user was trying to accomplish, and exactly how … and the symptoms they’re experiencing now. Remote control software helps a bunch in this situation. If you don’t have it, have the caller walk you through the steps he or she took. At each step, ask the caller if his/her screen shows what yours is showing.

Tip #4: Resolve the problem: You should have a good handle on what the user was trying to accomplish and how. It’s taken awhile, but now you get to apply your technical, as opposed to your interpersonal, skills.

Tip #5: Leave the caller smarter than when he or she called: Once the problem has been fixed, explain what’s happened and what you did in some detail. It takes another minute or two, but if you help that user avoid the next problem, you’ve helped yourself in the long run.

This is a column on management issues, of course, so I get to palm off the little details, like how to actually troubleshoot. That’s where Brian Livingston and Brett Glass get involved. Good luck, pals.

“We ought to start a mentor program,” said one of the four Jim’s reporting to me several years ago.

“Great idea,” I replied. “One question: what’s a mentor program?”

A mentor program, Jim explained, recognizes the expert-in-the-next-cubicle, providing support, prestige (or at least respect), and a role in influencing how IS deals with LAN and desktop technology and support.

“I like it,” I told him. “You’re in charge.”

At this juncture all four Jim’s (and the rest of the room too, except for the other Bob who sat sketching the meeting notes) explained that this would prevent the proposal of any more good ideas. Suggesting doesn’t automatically mean volunteering.

Eventually we found two volunteers and started the program. We won a national award for it, too. And here’s the greatest part: I got some of the credit, when all I did was pop for lunch, books, and a few trinkets. Total budget variance: 0.0113%. Non-money.

Last week’s column started a series on the interaction between IS and the end-user community. As you may remember, the column discussed three insights that form the backdrop for these interactions: (1) Visibility = Dissatisfaction; (2) You need to provide stealth end-user support; and (3) IS isn’t the expert when it comes to personal computers.

Mentor programs build on all three of these insights at the operational level. By improving “next-cube” support, fewer problems reach any manager’s radar screen. If you’re really persuasive, get your mentors to buddy-up with new users, so neophytes have someone to say, “I don’t remember what they said about this,” to without feeling embarrassed.

Mentors require a small but real support effort on the part of IS, but reduce the total time expended by IS analysts supporting end-users greatly. Let’s look at how to organize a program like this.

1. Find a compatible and enthusiastic pair of individuals to head this up. Two is a great number of people for a program like this. Two people bounce ideas off each other where one just mutters. Two load-balance where one burns out or lets the program slide. Two keep each other’s enthusiasm going.

2. Qualifications: you need party planners and social directors, not techies. Business happens over lunch and participation is voluntary. Your mentors gotta wanna. That means planning lunches that are entertaining as well as useful. (Yeah I know: making work fun isn’t in fashion this year, but I’ve never had much fashion sense.)

3. Monthly Lunch Programs: have contests with prizes, (give the group a list of obscure features and see which one knows the most) drawings for door prizes, and guest speakers (every vendor in town will drool over the chance to talk to a group like this). Ask mentors to submit “Tip ‘o the Month” ideas for your company to include in its employee newsletter, and give a special prize each month to the mentor supplying the tip.

4. Giveaways: give every mentor aftermarket books on your applications – the ones for sophisticated users, not beginners. Also give them a plaque, clock, t-shirt, sweatshirt … something that both identifies them as a mentor and that they’ll like.

5. Influence: involve mentors in product decisions, configuration defaults, training-course content … everything that directly affects the end-user community. Give them access to a test server housing new software releases as soon as each new release appears on the market. Invite them to stress-test the new releases and give them prizes for major bugs.

This isn’t a strategic program – heck, it isn’t even tactical. It just helps everyone out with their day-to-day grind, at very low cost. You may not be a hero for putting together a mentor program. The mentors will be the heroes if anyone is, and that’s as it should be.

But you’ll have done your good deed for the day.