Last post started with a link to a humorous blog about some of the, ahem, “interesting” questions that some support teams get asked by their customers.

I can say, luckily, that our customers are likely far above the average. I respect what they do, the projects they pull off, and the questions they ask. I’ve even learned some great lessons from them and that’s the subject for this post.

First of all I think of a television show I saw a few years ago. The show was detailing the inner operations of a US nuclear submarine. My brother in law served as a nuclear engineer on one of these boats for several years. Both the show and my conversations with my brother in law convinced me that what makes a nuclear submarine “safe” to operate isn’t technology as much as it is process. There is no master computer that can make all of the risk of operating a combination nuclear reactor, weapons platform, dormitory, and submersible vehicle disappear. It is inherently risky. What makes the risk palatable, manageable, and acceptable to otherwise sane sailors is the process and the training and discipline of those who execute the process.

The boat is safer because the sailors and what they do make it safer.

Could technical support be better if we, both users and providers of technical support, made it better by the processes we follow? I’ve seen cases where I think that to be true.

At MontaVista we offer technical support to our customers for the embedded Linux distribution and a wide array of Open Source software that constitutes our product. I’m not on the support team but I’ve been on the sidelines enough to have made some observations. Most of these are guided by a key customer I’ve worked with for almost 4 years. They are top notch engineers and seem to excel at getting high quality support out of all of their vendors. They’ve shown my how their processes help get the best out of vendor support:

1. Help teach your vendor support team about your expectations, the kind of projects that you are engaged on, and the needs that your team will have in the upcoming months. Have these details ready before they are needed.
2. Be personal, friendly, and professional. Real people are on both ends of the email chain.
3. Both sides should be vigilant about follow-ups and meeting expectations.
4. Introduce technology providers who are delivering to the same customer product. You never know when they will have to work together to tackle a technical issue.
5. The customer’s expectations matter the most but it is important that the vendor support team is being asked for something they can reasonably be expected to deliver on. Work in advance to make sure both sides understand what that is. Find better support channels to the vendor if the ones you have aren’t right for the customer’s expectations.

If markets truly are conversations than it is likely essential to make sure that the conversation of technical support transcends emails and trouble tickets. Find ways to go beyond just the support email.

So in the comments I’d love to know if you would ever consider participating in…

• private blogging between customer and tech support to keep up-to-date on what’s new in your projects?
• a shared private wiki so customers and tech support folks could cooperate closely?
• social worknets to glue partners together with their mutual customer?

ShareThis

This entry was posted on Friday, May 2nd, 2008 at 4:51 pm and is filed under support.