Team LiB
Previous Section Next Section

For Very Hard Bugs, Let Developers Participate in the Tech Support Phone Calls

Lack of resources often forces small software companies to use their development staff to answer technical support inquiries. But larger companies always have a dedicated staff for tech support. And rightly so! Interacting with customers is a full-time job best handled by trained support personnel, not developers. Many tech support calls involve simple questions from users who just didn't read the product documentation. Developers generally aren't known for their people skills when answering such requests. In most cases, having developers answer tech support calls wastes time that could be better spent coding.

Many companies enforce that policy so completely that developers never speak directly to customers. But that's going too far, especially for truly nasty bugs. When you've already spent 2 or 3 days on a bug without results, then you need to jar the system to make yourself think along new lines. These cases are rare, but when they do happen, it's extremely helpful to have the developer participate in the call with the tech support representative. In these rare cases, let the developer hear the customer's words directly, and ask the customer questions without a filter.

Each Involved Person Filters Out More Information

Did you ever play the children's game Telephone? The first child whispers a message to the next child, who whispers what he heard to the next child, and so on until the last child announces the message she heard—which is usually quite different from the original. Receiving bug reports secondhand is the same way. The customer unconsciously fails to mention details he doesn't consider important, which creates one filter. Then the tech support person unconsciously creates a second filter when she leaves out more details in her summary to the developer.

Most of the time, this doesn't matter. With competent tech support personnel, the communication disconnect is usually small. On most bugs, the price of the communication disconnect is well worth the returns from division of labor. But if you've already blown days on a bug with no results to show for it, why not grab every advantage you can?

Tip 

A good developer needs to have an excellent working relationship with his or her quality assurance teammates—but only slightly less important is a good working relationship with the tech support department.

For those truly hard bugs, sit with the tech support representative, and together call the customer. The added benefit is that customers love feeling special. They love to hear, "We don't usually do this, but since you're a great customer we've asked developer so-and-so to investigate your issue personally. Could you please answer a few of his questions?" The customer will feel reassured that your company is taking his issue seriously—he's probably feeling annoyed that the bug has already taken so long to fix, but at least now he's finally talking directly to the person who can actually fix the problem.

What Developers Should Say to the Customer

The developer can then say, "Just to make sure I really understand the problem, could you please describe the bug you're seeing?" Usually, the customer will be willing to summarize the issue from the very beginning, and if you get lucky, maybe he'll mention some crucial detail that he forgot to mention before. Even if you don't get lucky, the new perspective may trigger new lines of thought for you to investigate. At the very least, you'll have bought additional time to solve the bug by reassuring the customer that the issue is development's top priority, so he shouldn't do anything crazy like demand a refund for the buggy software.

But developers must be careful not to give their e-mail addresses or phone numbers to customers. Given a developer's address, many customers will flood that developer with an avalanche of product enhancement requests and minor bug reports. Then you're in a no-win situation. If you don't respond to the e-mail, customers feel you're not responsive to their needs. But if you do respond, then your valuable time will be taken away from coding. Furthermore, customers may try to guilt-trip you into agreeing to new features without the authorization of product management, which will wreck the product schedules. With a competent tech support department, developer interaction with customers should be needed only rarely, so there's no need to give the customer such an easy way to contact the developers.

If the customer asks for your phone number, politely say that you're often away from your desk and then give him the tech support phone number and mention the best way for him to resolve his issues is to go through there. Be polite, but firm on this point. Since your tech support personnel are trained to talk to customers, they will be able to filter out all the normal customer problems and will only involve developers on the truly difficult issues.


Team LiB
Previous Section Next Section