How to minimize customer service help desk time for programmers?

Question

Most software companies have different levels of support for the customer service help desk in order to protect programmers spending a lot of time explaining things to customers or trying to understand problems and bugs.

But there inevitably are situations where programmers have to interact one-to-one with customers. For example, if first-level support doesn't have all the information to ask the right questions or when there is a bug which only a programmer can track down.

Direct programmer-to-customer can be time-consuming. Also, customers could become accustomed talking to a single programmer who normally has more insight into the application and therefore could solve problem in a shorter time span.

So, what can be done in order to minimize the help desk time for programmers? What guidelines, concepts or tools should the whole team (helpdesk and development) adopt?

P.S.: A controversial point of view is: sometimes programmers have to hear the users' complaints or problems first-hand in order to really understand some difficulties or problems.

Answer 1

1. Set customer expectations: Have your support person explain that the developer will only be involved on this particular case, and must not be contacted directly about other issues.

2. Tell the developer to forward unrelated issues to support without responding.

3. Only involve the developer for important customers.

Answer 2

Have you tried looking at a product like BMC's Application Problem Resolution suite? It automates the problem capture on the end-user's machine and allows the developer to grab every detail he needs to solve a problem, without bothering to talk to the end user himself.

Disclaimer: I'm a BMC employee, and I use APR daily for my development job. But this site is a hobby for me - I am not trying to sell anything :).

Answer 3

I definitely am one of the group who says that programmers should do their share of customer support. And not only programmers, also decision makers, like the people who decide how the interface looks like, how API's look like, people who write the docs etc.

One thing you can do is to divide the support into tiers: you have first line, which is done by people who simply try to look up answers in manuals, KB etc. They bounce questions to a second tier, which is handled by the people who really work on the application. On top of that, you schedule support time for everyone so they'll do some support for the first tier.

If you randomize things, so every question comes in a simple queue per tier, and people look into the queue what's to answer, claim a question and handle it, you avoid having 1 person doing all questions of topic X etc.

The idea of having team personnel work on support avoids the pain for the customer to have to file a 'feature request' or worse, go through an uphill battle to get something changed, because the necessity for it is hard to explain to a person who only looks at the feature requests.

I wrote an open source helpdesk system a few years ago, it's called HnD (http://www.llblgen.com/hnd ) which places new topics per forum into a queue and users support personnel can look in their queue and see what's to answer, claim questions etc.

We use it ourselves for LLBLGen Pro support on a daily basis and I too do support for LLBLGen Pro (My estimate is about 1 hour a day). It has learned me valuable aspects of how customers use our product and how we can change things to make things better. Customers have also expressed that they find it great to be able to talk directly to the persons who make the product they're using, so they know the person they're talking to understands the product from a technical point of view.

Answer 4

We call our methodology "reserve duty", it's a round robin one month duty distributed between all the developers. Where every month we have a dedicated developer for the support calls. The advantages are:

1. Focus - No context switches for other developers, they can focus on their iteration content.
2. Knowledge sharing - the developer on duty gains knowledge in other aspects of the product that he wasn't familiar with.
3. Manageability - Easier for managers to plan their monthly resources as they don't suddenly have to allocate resource for solving an urgent issue.
4. Evenly distributed - developers can't complain that they are doing more support than others.

The flaw of this method is somewhat lower quality of support because the developer on duty isn't necessarily familiar with the issue he needs to solve so it may take him more time.

Answer 5

Getting Real has an interesting chapter about support. One article is named Feel the Pain. Just that title sort of answers your question. =)

Another thing with customer support is that it often becomes a channel for feature requests. Not always what you want. Getting Real has good advice on this too. And I think this site makes a very good decision in using something like Uservoice to let their users report bugs and suggest improvements. It makes the users more satisfied while at the same time freeing up time for the SO staff to improve their service. Who said you can't both eat the cake and have it?

Answer 6

I have made good experiences with a three tier support system using a support ticket software (in my case a proprietary system). This is a setup for medium companies but could be scaled up or down quite easily.

The first support tier takes all the customer calls via a single phone number. If they can help directly they do so, if not, they enter a support ticket. The tickets can be distributed to other persons or other teams. First tier members either keep the ticket they entered to solve the problem later, or they give it to the second tier.

The second tier consists of people with better training in the software they support and can answer harder questions. Most of them are specialized in different aspects of the software or a subject-specific domain. The second tier gets the "hard" tickets. If they need assistance of a developer, they forward the ticket to the third tier.

The third tier consists of one or more developers who are on support duty. They try to solve all the tickets that require development skills. Calls to the customer are either managed solely by the first or second tier (like getting log files from the customer), or by the first or second tier calling the customer with the developer at their side. If it can't be avoided that the developer has to call the customer directly, the "support developer phone" is used. This way, the developer does not show his own number, but the support number. This can be set up easily with most telephone systems. It is recommended to place the developer with the support team during his support duty to minimize communication overhead. It also minimizes the urge to do project work instead of solving all those support tickets.

Having a support duty developer frees all other developers from taking outside calls so they can focus on their work. Rotating the support duty every few weeks lets all developers get in touch with the real world which is always a good experience. I have seen three different approaches to this: Rotating every week lets the developer get back to his work fast, but his dedication to the task is low. It is easy to let a difficult ticket lie in the support system until the next developer start. Rotating every four or even six months lets you become an expert in solving tickets and you will probably know all bugs and usability problems by their first name. But support duty can be stressful so this is not recommended. Doing support duty for one or two months is a good timeframe because it is long enough to get you involved but short enough to see the light at the end of the tunnel.

The ticketing system makes it easy to maintain a history of the customers call and what the different tiers have already tried to do or what they have told the customers. It can also be used to prioritize tasks, schedule tickets, etc.

I can only recommended to establish remote connections with the customers using RDP, PCAnywhere, NTR or any other remoting software. Some customers may not want it due to security reasons, but most will accept it. This way you can check log files or the software by yourself without having to guide the customer through the darker alleys of your products. This saves both sides time. You know what you are doing and the customer does not have to crawl through log files for you.

Answer 7

I'm also of the belief that you should not keep developers from the customers. The closer you get the person writing the code to the people actually using it, the better the product will be.

Here's a good blog article about the same thing.