Home / Creating Successful Support Engagements

Creating Successful Support Engagements

It’s 4:00 AM, local time. You’ve been awoken by the angry sound of your iPhone’s SMS notification to tell you that the website you manage is totally offline. You’ve got a worldwide business and being operational 24/7 is critical. You call your support hotline (in Europe) which at this time has a long queue. You’re sweating, waiting. The rep finally comes on the phone and proclaims, “Hi there, Mr. Snuffleupagus, how can we help you?”

Something you may not realize about engaging with a support team member is this: Every piece of information you provide is a possible path for them to follow. So, as important as the issue you’re having is, it’s equally important to properly communicate that issue. It’s not intuitive. We know that. So here’s some guidelines to follow when communicating with someone trying to assist you:

When Snuffy calls, support listens.

Be Aware of the Software
Intuitively you have to be willing to notice the things about the software you work with so that when things go wrong, you’ll have context and awareness of the problem. That means keeping some form of capture at hand (for personal note-taking) and having frequent sessions of exchange over the development of any site. Agile does this nicely with the Scrum framework.

If you know that there were 2 new modules yesterday, 5 configuration changes, and one rogue SVN commit from that guy who wanted the last piece of pizza on Friday - it’s easier to track down the source of any problem.

There’s nary an occasion where something didn’t change in the environment by human or automated means. So set up some form of monitoring on sites, even if it simply emails you when cron runs. Knowing when things change on an ongoing basis can eliminate a lot of time looking at the wrong doorway.

Be Complete and in Control
Don’t be afraid to write the novella you’ve always dreamed of if you have the luxury of using a ticketed or email-capable system to engage. Tell them everything. Even things that may or may not be related. Divide it up in a digestible format (like this set of guidelines) and provide the information needed to make the point. This isn’t a forum where people often appreciate a terse and pointed question. You’re paying for the service, either through your consumer purchase or explicitly, and you need to get www.bertspigeonsupplies.com[/codefilter_code] back online before the uni-browed wonder wakes up, has a fit, and gives Ernie a blanket party.

If it’s a phone session, speak clearly and slowly. Remember that the person on the other end of the line didn’t spend 4 hours staring at the same problem and context is king. The less frantic you are about the issue, the more success you’ll have in communicating it.

Be Precise and Informative
Instead of rewriting history in this post, I’ll borrow my favorite bit from the paper by Moen/Raymond entitled, How to Ask Questions the Right Way, which says:

  • Describe the symptoms of your problem or bug carefully and clearly.
  • Describe the environment in which it occurs (machine, OS, application, whatever).
  • Provide your vendor's distribution and release level (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
  • Describe the research you did to try and understand the problem before you asked the question.
  • Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
  • Describe any possibly relevant recent changes in your computer or software configuration.
  • If at all possible, provide a way to reproduce the problem in a controlled environment.

Be Engaged
Make sure that once you lean on someone for support and they engage with you, that you can see the engagement through to the end in a timely fashion. Popping a question in and coming back 3 days later to follow-up on the representative’s reply is neither efficient nor effective in solving problems. Sure it’s good to step away from an issue when you feel too close, in order to fully understand it, but taking long unannounced breaks from a tricky issue will ultimately serve to strip a lot of the momentum from solving your case.

Depending on the size of the organization, you may find the ticket closed when you return to it - forcing you to engage with a new person entirely who may or may not have any experiences to draw on from your site’s problem.

These are just a few simple guidelines to assist you in getting the most from your interactions with any support organization. Do you have ideas to share? Leave us a comment below with your experiences.