The smart user's guide to getting better tech support

I don't simply write about IT -- I also manage them in my other role as editorial CTO for InfoWorld's parent company. We have several custom operational systems for producing, coordinating, and publishing our content, and I help manage the functionality and priorities, working with our development organization. Thus, I spend a lot of time fielding, analyzing, and triaging support calls from staff and other users.

In that work, I've seen several patterns of support calls and tickets that are guaranteed to make it harder to actually solve those issues. Although many in IT like to joke about stupid users, the issue is not stupidity. It's usually some combination of frustration, myopia, and lack of systems understanding. The users who can step back and present a fuller context for the issue are the ones whose problems usually get addressed faster and more completely -- they made it easier for me and the developers to get to a solution.

Here are the four things they do to get that better result that you should do too.

1. Take a deep breath -- you want the other person to want to help you

Handling support calls and emails often requires a thick skin and diplomatic skills on the part of the support desk and this trying to resolve the issue. Users are often angry, frustrated, and/or panicked.

Negative emotions only get in the way of solving the issue. As a user, you need to take a deep breath and focus on getting your problem solved, not blaming people, shaming people, or unloading your frustrations on people. It's not working, so let's work to fix it.

Believe me, if there's a pattern of poor work, the bug reports over time will reveal that, and any competent IT organization will deal with the reality whether in its processes or its personnel.

Being angry, pushy, or unreasonable with the person trying to help you not only focuses the legitimate frustration on the wrong person, it doesn't actually help you get the issue solved -- which is what you really want.

Emotionalism can also make you incoherent or cause you to miss the details that would help get your problem resolved. Whatever you may be feeling, put that aside when working to get the issue addressed.

Yes, communicate the urgency of the issue, to help us prioritize. But you can do that without yelling, threatening, or painting doomsday scenarios in an effort to get a response more to your liking. Be strong when needed, but don't confuse strong with mean, sarcastic, unreasonable, or loud.

And remember: Being negative in your dealings with others can quickly paint you as a complainer no one wants to work with. That can hinder your issues from being addressed, because everyone starts avoiding them. Be someone who they want to help or at least someone they don't want to avoid.

2. Make an informal inquiry -- you may get help faster

There's a tendency in organizations to have everything go through a formal ticketing system. That's great for resource, issue, and resolution tracking and for pattern analysis to look for deeper issues that may be surfacing in multiple guises.

But often, especially, for operational issues, the issue is already known and may even have a workaround. Or it's a training issue, perhaps around a feature that was changed but not well communicated (or that the user didn't pay attention to). Each ticket goes through several hands, so routing everything through tickets can be very inefficient.

I've informed most of the staff they should ping me when something doesn't seem right or isn't working as expected. (On the other hand, a bug or clear failure -- such as when things crash, do not save, or return error messages -- should be filed as tickets ASAP.)

More than half the time, the issue is either known or a question of training/education that I or a colleague can handle quickly, and not consume the time of our product managers and developers. This way, I also get to see the users' operational patterns, which helps me figure out process and enabling-technology improvements to propose to the development team -- my core responsibility on the tech front.

When it is a bug or an issue I can't figure out or don't recognize, I've usually drawn out the details from the user that will help focus the project managers and developers on the most likely cause for use in the ticket that I file or ask the user to file.

3. Provide the details -- they matter more than you think

It's extremely common for users to provide no context on the environment the issue occurred in, resulting in reports like "This isn't working in my browser."

What browser? What operating system? What location? (After all, network issues could be the cause, not the browser.) Do you have ad blocking enabled? Have you tried another browser (so we can see if it's a cache issue or a browser-specific bug)? What were you doing? Does it happen again in the same circumstances? In other circumstances? Links to what you were doing, screenshots, and/or copy of the files you were working with will help immensely see if this issue is local or broad.

Often, when I remind people that such details help us narrow down possibilities so that we can get to a working theory and thus solution faster, I hear back, "But that's your job."

Yes it is. But as the user, you know your environment and operational context, and if the issue is not one that affects all scenarios, I may not find it because I may not do things the way you did or use the same configuration as you.

Then the ticket gets tagged "Cannot Reproduce" and essentially ignored, or it goes in the pile of tickets that will take a lot of discover -- a pile that developers seem to avoid going back to because there's always something newer to deal with.

The details add another critical component: They give the project manager and developer a finer picture that helps them come out with the best solution. Often, the issue isn't as narrow as the user's specific case. I've seen all too often developers fix a specific issue but not be aware of underlying implications that end up surfacing later, and make us all wonder "I thought we fixed that -- what happened?" No, we fixed a symptom, not the cause -- but we didn't know that.

We can't always see those underlying lurking issues even when we have the details. But we almost never can see them if we don't have the details. The finer points matter not only for discovery but also for solution engineering.

4. Don't tell us how to fix the problem

It's very useful to provide context through details. It can sometimes be useful to provide theories as to causes, as long as you have sufficient knowledge to propose reasonable theories -- you don't want to inadvertently lead the tech team on a wild goose chase that ends up delaying the fix.

You should also refrain from telling the tech team how to solve the issue. Often, there's more to the story than the user sees, and the right solution may not be so obvious. Often, users propose solutions that aren't scalable to the bigger context -- meaning other users in the system. In fact, I find that most user-proposed solutions would cause more problems than they solve.

Rather than say how to fix the problem, explain the desired result. Not only might that provide a clue as to the underlying issue, it gives the developers context to consider for the solution that they come up with.

It's really common in the issues I deal with for that extra context to help developers see a better approach than their initial solution brings. Why? Because, like you, they tend to focus on the specific issue at hand and look to solve it. If the issue is part of a larger workflow or process, it can't hurt to say, "This is doing that but should be doing this, as part of doing this larger thing. Please make sure that the larger thing isn't affected by the solution."

More about eleven