How to support web-based software

While I do have a three letter job title at Populi, we’re a small team and I spend a ton of time supporting our users. Here are a few things we’ve learned about web-based software support. Some of these are pretty basic. Others not so much.

  1. Prioritize. When you’re the first one into the office and you’re staring at a dozen support tickets, its important to know which ones to answer first. Take care of critical issues right away (anything to do with account access), then knock out anything that can be answered quickly (no sense making someone wait 60 minutes when you can answer their question in 30 seconds). Finish the rest off from oldest to newest.
  2. Set expectations. Then go beyond them. Make sure people know when you are available to respond to support requests. If you don’t respond to requests on the weekend, make sure your customers know that. Then, when you do respond, they’ll be really impressed.
  3. Take advantage of email communication. Most people just want to pick up the phone when they have a problem. Show them the value of support tickets by providing clear step by step instructions that they can refer back to whenever they want, and never pass up an opportunity to link to other resources in your help desk. This also relates to…
  4. Respond quickly. You’ll never convince your users that email is better than phone if it takes you 24 hours to respond to requests. People would rather be on hold on the phone for 30 minutes, rather than wait 24 hours for an email response. But, if you can respond to email requests in under an hour, its the best of both worlds. Your users get a quick response, and they don’t have to waste time on hold. 
  5. Apologize. Always do your due diligence to give the right answer, but when you don’t, apologize. If you’re quick to admit that you gave a wrong or incomplete answer, your users will be really forgiving. If you side-step and cast off blame, they won’t.
  6. Don’t be defensive. Angry support requests are inevitable, but a soft answer turns away wrath. When users write you in an outrage, a cheerful, eager response (“Sorry for the trouble! Here’s what you can do to fix it.”) is best. A lot of people aren’t even that mad, they’ve just been trained by corporate America that the loudest complaints get dealt with first. Be known for good responses regardless of the tone of the request.
  7. Document, document, document. If you want to minimize time on the phone, or time responding to the same questions over and over, you need outstanding documentation. Tackle explanations of your product by section and compile answers to frequently asked questions. Videos are great for helping users visualize common workflows.
  8. Train users to write good support requests. Let them know if they want a good response, they need to provide lots of details about the problem. This will save you time digging for details, or save them from having to explain further 30 minutes later.
  9. Don’t get bogged down by feature requests. Don’t try to respond to every request with, “Yes, we’ll do that” or, “No, we won’t.” You’ll end up juggling more requests than support issues and lose focus on the critical stuff. But don’t ignore them either, or answer each one with, “Thanks for the idea.” People will get the drift and lose passion for your product. Figure out a way to collect ideas. Forums are great as they let users interact with each other as well. If you know you’ll never do something, tell them. If you like the idea, tell them you’ll consider it for a future release (you could even mark it “planned”). Whatever you do, don’t make guarantees or start giving out timelines.
  10. Use Macros and text-expanders. Use them, but use them carefully. Canned responses can help you quickly deal with questions you get a lot, but always change the language up a bit. No one likes the feel of an automated response.
  11. Get change requests in writing. If you agree to make bulk changes for your users, ask them to submit the request in writing first. You don’t want any confusion about what is being requested, and you may want something to refer back to if issues arise later.