How to give good tech support

Every developer eventually has to do second or third tier technical support. It's usually well after you've delivered a product and some important customer has a show stopper. The front-line people have thrown their hands up and turfed it to you.

They key is to learn to respond to customers in a way which makes them feel that you are really are looking into their problem and trying to make the products better, not just reading form a script of slap-dash workarounds. It's not magic.

1. Reproduce the customer problem.
2. Tell them you have done that and are looking into it.
3. Figure out what is wrong.
4. Tell them you see what is wrong and say it will be a few days until you understand how to fix it.
5. Provide a quick patch. Explain that it is an interim solution because you have to work it into the baseline product.
6. Take as long as you need to provide the official fixed release, taking into account real product release cycles. At a minimum, this means:
   • Add their case into the regression test suite
   • Make sure the fix does not break anything else
   • Make sure any documentation changes get done
   • Decide if this should be a special release, or a regularly scheduled one
   • When you ship it, tag the components in your SCM repository

The essential bit is steps 4 and 5. That let's them know you have given them a priority response, but that configuration management and quality control issues keep their patch "special" until we can make a real release. That gets you off the hook for supporting their patched version forever. It also gives you a rationale for taking the time needed to deliver an official fix. Most people are comfortable if you explain that you want to deliver a quality solution rather than a fast one. The important thing is to give them sensible reasons for why you are doing things.

When the next stable release comes out you can tell them about the update and put the problem of evaluating and accepting it on their heads.

Non-Reproducibility

Non-reproducibility is a real pain. But I think most things are if you dig deep enough. I also think the customers stay happy if you keep giving them quick feedback, even if it is not good news.

Customer: yada, yada, SEGFAULT.

Support: We tried what you said, but can't reproduce it.  Can 
        you send a sample?

C: ....example.tar...

S: I got the example and unpacked it.  I will be able to
look at this this afternoon. 

-- The response is important. I just got points for being prompt, yet I bought myself the time I need to examine what they sent before responding again.

S: I got your example to build, but can't reproduce the problem
   I had had to change these things to fit our environment.
   Can you tell me more about your Oracle setup?
   Can you give me the exact schema definition for those tables
   you use?  Can you send me some sample data? ....