It’s perfectly clear I work in technical support, and although many of my blog posts on the topic are rants, this one will try to lend a more positive/proactive approach.

What follows are some best practices for technical support representatives, specifically for software development:

1. Don’t get emotional.
2. Keep them moving.
3. Go the extra step.

Don’t get emotional

Leave your emotion at the door. It doesn’t add any value to resolving the issue at hand. Support issues are best resolved with facts, and the ability to replicate the issue. Support issues are black-and-white. It’s either broken or not. It’s either the company’s responsibility (to the paying customer), or a misunderstanding on the part of the customer to how the software actually works.

People coming to support are often irritated, and rightfully so. The software is not working as they would expect, or there is a clearly visible bug that has interrupted their use of the software.

They will often bring emotion into their support tickets. As paying customers, they feel the right to vent their frustrations. It’s crucial for the support representative to avoid becoming emotional as well.

Don’t play down to their level. Remain calm and matter-of-fact. Explain clearly and don’t argue. If you’re wrong, and you overlooked something, admit it. Otherwise respond without opinions or emotion – keep it dry and to-the-point.

Keep them moving

You want to get users out of the support queue as quickly as possible. But don’t assume quick means haste. Don’t rush your attention to the matter, but rather find the most efficient solution (or work-around) for the user, if the main issue can’t be resolved easily.

The more you linger on a particular issue, the more backed-up the queue becomes. If the issue can’t be resolved quickly, make a note of it, and delegate it appropriately. Then tell the user that you are aware of the issue and will work to fix it.

Then get them out of the queue.

Even though your response may not have rectified the issue, you have made a note of it elsewhere (in whatever system or method is used to track issues that need attention), so for all intents and purposes, the support ticket is now in an “idle” state, meaning it can be removed from view.

If and when there is progress on the issue , you can always revisit the ticket thread and provide an update.

With software in particular, some issues can’t be quickly fixed by flipping a switch, or something like that. Most software bugs require investigation, planning, and prioritizing from an internal point-of-view.

Just because a user finds a bug, that doesn’t mean your focus should shift to that bug immediately. If you do this, you’ll be spinning your wheels endlessly, because every user believe their bug is the most important.

Don’t allow users to monopolize and/or interrupt your priority tasks and bug fixes. Don’t let them muscle you into working on something that is not relevant for the big picture of the company.

Go the extra step

Don’t be lazy – it just extends the life of support tickets. Rather, take the extra step to direct the person as best as possible – don’t assume they’ll know what you are talking about. Since you’re overly-technical, you may tend to use words or phrases that are lost on the user.

Dumb-down your responses as much as possible, but don’t patronize. Go the extra step and explain any gray areas that you know may confuse the user.

If you think the user will ask for a better explanataion, then explain it up-front in your initial response. Don’t wait for them to reply and ask – it just drags out the support ticket.