DB2

Best practices for successful support cases

In my day job, I work with latest technology and cloud services. In addition, I work with customers / users and help them succeed. And in my private life, I also use technical equipment. In all three of these scenarios, mostly in the first two, I often create support cases. And I like to get the issues resolved, not just support cases closed. Over the years, I came up with these best practices for successful support cases.

Teamwork for success

There are different sides (and hence roles) to a support case. Usually, it is the user opening a case and someone visibly reacting to it. Both may have management interested in the outcome in general and how long it takes. Both sides may also have different teams providing assistance in the background, contributing necessary data and information, and influencing towards their own agenda. Development teams, customer success team, sales teams, procurement teams, and more.

All involved need to work together or, at least, should not put obstacles into the way towards case resolution.

Bring time, patience and politeness

Depending on the support organization you work with (not against), be prepared to bring some time. Each corporation, sometimes even each product or service, has its own process. It's a game to play. Learn the rules, understand the players, and plot your route to victory...

But what is victory? Often, the user-facing support teams are paid to close ("resolve") support cases. You and I as customers want a certain problem to be addressed. Usually, I am aiming for a longterm fix, not something in the category of "have you tried turning it off and on again". The latter often requires to insist on a permanent fix, which in turn requires the support organization and their backend team to acknowledge an issue.

With that, what are my best practices?

  • Make sure that the text you enter into the support system may be understood by your parents and your kids. It should be concise and clear, not leaving room for questions.
  • Don't assume anything, be clear and provide enough details. If requested, add more information. It's a give and take.
  • RTFM, especially the troubleshooting and FAQ section. If you know your way around, it increases your reputation for the current and future cases.
  • Think of support as the delivery guys for your core message to the advanced support and development teams. Wrap the core message nicely and make sure that the delivery instructions are seen ("could you pass this on to...?").
  • Sometimes, a support organization insists on their rules and policies. Over the years I learned that it is great to have my own policies. So I insist on my policies and explain why something should be done in my way.
  • Always be polite and friendly. We are all humans. Even the bots are trained to be.
  • Patience and persistence pay off. High priority support cases usually are for putting temporary stop-gap solutions in and returning to business. Business means to address the core issue behind. That takes time.

Fixes versus strategic improvement

Support cases typically are used for fixes to existing features and functionality. To enhance a product or service or to even change its direction, there are other processes. They are called feature requests, product feedback, beta programs, advisory boards or similar. And they require other strategies and best practices...

Originally published on Data Henrik.

Leave a Reply

Your email address will not be published.