I write software and over my IT career I’ve been on both sides of software support: needing support for an issue and providing support to customers for a software product. Getting support for potentially complex problems with complex software that you’ve heavily configured can be a challenge. Here are some ways to make the process easier for people on both sides of the support system.
Most support starts off with the customer describing some issue they’re having in text and sending it off to the support organization. This might be an email alias like firstname.lastname@example.org or a web form in a support portal. The point is it usually starts off with text, which is a really rough way to describe a detailed problem.
Where do you start? Here’s the standard initial points you need to address first:
- What did you do? Give the minimum number of steps to reproduce what you’re going to mention in 3.
- What did you expect to happen?
- What happened?
This covers the basics, helps you focus the issue on exactly what’s wrong, and allows the support person to start to focus on “our software doesn’t do that” or “yeah, that’s not right”. If the software has a GUI, screenshots can provide a lot of information easily.
After the basics, you may want to add some more detail about the issue. If you’ve seen advice that you should hire developers who have excellent writing skills, writing bug reports for support is one of the reasons. Whether you’re filing a bug report for another developer on your team or sending off a support request, you need good writing skills to accurately and concisely describe a complex issue.
If you want to avoid a guaranteed back-and-forth at the beginning, you should also provide as much of your environment information as possible up front. This includes the version of the software you’re running, including any updates or patches. Provide the system it’s running on, whether it’s RedHat Enterprise Linux 6 or Mac OS X 10.7.5 Lion.
Then include any other relevant diagnostic information. If the software has a configuration page, send along a copy or screenshot. If it has logs that you’re aware of, send along a relevant section gathered as you demonstrated the error. You may not see anything useful there, but even the absence of messages can be helpful for the support person.
Provide background on any history if there is one. You may have had similar issues in the past and support gave you a patch or update. Support may have provided steps to fix something similar previously, but the fix isn’t working this time. Provide support ticket numbers if you have them just in case the new support person couldn’t find them.
You don’t want to overwhelm the support person, but lastly you can include what you’ve tried so far. You may still get the standard “try this” response, but if you get a human on the first try, you might get bumped up to an engineer if you’ve already hit all of the obvious first steps (clear your cache, reboot, apply the latest system updates, etc.).
You’re probably working really hard to fix the issue on your own, which is why I suggest telling support everything you’ve tried. But once you send off the support request, it’s time to stop trying things randomly on your own. The support person is going to try to reproduce your issue and it can become very difficult if you become a moving target. In the best case, you’ll fix your issue but you won’t quite know why, which means it could happen again. In the worse case, you’ll cause another issue and then you’re really in a bind because you can’t easily answer 1, 2, and 3 from above because you were “just trying things.”
Assuming you have a decent support company and your boss has paid for a reasonable SLA, you should get a response in a reasonable amount of time. Unless it’s a really common issue, they are likely to send some instructions that will either give them some additional information or potentially solve the problem.
Do what they ask.
One of the more puzzling things I’ve encountered is the frequency with which support customers ask for help, then do everything but what you suggest. The support person is trying to piece together your problem from only a few clues and when they ask for something, they probably have an idea what’s wrong. They may be trying to rule out a known bug or confirm a particular setting or detail. When you do what they ask, you help them move along their train of thought. When you try a bunch of other things, they essentially need to reset and start again with how your system is set up now.
The Whole Story
You’re sitting there waiting for a response, your boss is bugging you every 15 minutes for an update, and I’m saying don’t try things. It’s understandable if you get a little antsy, especially if you get an idea after dwelling on the problem for a few hours or days. If you do make changes, keep track of exactly what you’ve done and let the support person know on the next exchange. Yeah, maybe you did something you shouldn’t have. Keeping it a secret just compounds the mistake.
Likewise, if you’ve been gathering information from other people on the issue, send along new information as you learn it. This is especially important if you track something down and find out you got incorrect information previously. Support may be holding off on sending you a fix because it doesn’t make sense given that part of the puzzle.
If you’re lucky, you’ll get a good support person and they’ll get you a fix. It might be a patch or update, a configuration change, or a reboot. Whatever the case, when the issue is resolved and you’re back up and running, reply back so the support person can close the ticket. Some support organizations are evaluated based on closing tickets. Knowing you’re all set helps them keep their ticket system cleaned up. Some systems auto-close after a period of inactivity, but the ticket history won’t reflect whether you got things fixed, especially if the last response included several things for you to try.
We all rely on software and it can be panic-inducing when it becomes uncooperative. Having good support available is one safety measure. Knowing how to work with them effectively is another.