Submitting a Better Support Request

 

Oh no!  Something is Broken!

It's never fun when something goes wrong with a piece of software or hardware we depend on.  Often this situation necessitates some form of support engagement with the vendor.  Vendor support varies greatly in quality, and I'm lucky to be writing this from the perspective of a member of the technical team at SQL Sentry, a company that has an excellent support team.  That being said, my experiences as a support customer of various companies has run the gamut from great to terrible. While the quality of the support team you are working with may vary, I would like to offer some suggestions for making the process better from the customer side.

The Goal:

I think we can all agree that the primary objective of any support contact is to resolve the issue at hand as quickly as possible.  Time spent on the support engagement is time not spent on business or personal projects.  We could all stand to have a bit more time right?

So I just fire off an email or call right away, right?

I think this is often when things go wrong, right at the beginning.  I know my mindset used to be that I wanted to get someone started on my problem as quickly as possible.  I've since learned that a little time spent on preparation can save lots of time not just for the support technician on the other end of the call, but also for me!

Why it pays to take a little time:

Sometimes you find the answer yourself.

If you accept the premise that saving time is the ultimate goal, the best support engagement is the one that never takes place.  There are many self-service support resources available: documentation, forums, knowledge base articles, FAQs, and community resources like Twitter.  Chances are pretty good that someone else has had this problem before.  Even if you don't find the answer, you might run across other useful bits of information about the software.

I didn't find the answer that way...what now?

The time spent doing a quick search for an answer at least allows a few potential causes of the issue to be eliminated.  Make sure to pass along a quick note of what you've already investigated to the support technician.

The next step is to decide on what support channel to use.  Often you are presented with three options: email, phone, and forums.  Forums are great if you have a quick question that's not really pressing.  Email is usually the best way to go.  I say this because email provides you the best opportunity to provide the support team with the information they need to help you resolve the issue quickly.  We will talk about building the best possible email in a moment.

What about phone? 

My suggestion is to leave the phone for follow up.  I don't start with a phone call unless the issue is causing major chaos to a business-critical system, and needs to be resolved right this second.  I say this for two reasons:  First, a phone call doesn't just tie the support tech down, it ties you down as well.  You aren't going to be able to get anything else done until the call ends.  Second, as you develop a relationship with the support teams at your vendors, they pay attention to this.  I want the support team to know that if I am calling to initiate a support engagement, it's because it is an issue that cannot wait.  I also make sure that I'm ready to dedicate a significant amount of time (say an hour or so) to working on the issue.

Crafting a better support email:

The first email to the support team can be the most important from a standpoint of saving time.  The more complete and informative this message is, the better.  I'm creating these lists simply as examples, but they are based on my experiences and input from the SQL Sentry support team.

Please do:

• Include as much detail in the initial email to support as possible: full screenshots, errors, and alert messages.  If you need to scrub out a bit of sensitive data that's fine, but don't crop out 90% of the screen.
• Try to be as detailed and accurate as possible in describing what you were doing in the tool when the error occurred.  This is especially important if you are reporting an exception.
• Read the responses you get from the tech thoroughly, and respond with all of the requested information in the format the tech specified (if any).  This really helps eliminate the need for lengthy email exchanges, and it saves everybody time.
• Provide the full version number of the OS, SQL Server, and SQL Sentry (or other application if you aren't contacting us), as well as a good contact phone number for you in case a support call or online meeting is necessary.

Room for improvement:

• Errors without any context:



This is just one of many possible examples, but if all the tech gets is this, they really don't know anything other than that an installation failed.  This could have been due to a permissions issue, lack of disk space, or any number of other causes.

• Replying to an old incident email to start a new one.  This seems minor but sending in a fresh email really helps the support team out.  It means they know it's a new incident right away, they don't have to dig through old notes and emails to get to the current one, and the (hopefully) accurate subject line can help ensure it gets routed to the right person the first time.
• Sending the support request directly to the tech that helped you on a past incident.  This may result in a longer wait time, since you are now depending on one person rather than the whole team to respond.  It also bypasses automated ticketing systems, creating manual work that has to be done by the support team and making the incident harder to track.

If you follow the "please do" recommendations above, there is not too much need to worry about the "room for improvement" stuff, as you will already be putting things on the path to a speedy resolution.