News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Good Tech Support Yields Better Software




June 15, 2004 — 
I was out of town last week, and was forced to get e-mail through a dial-up connection. My provider is SBC-the biggest DSL provider in California (this fact will be relevant in a moment).

SBC used to defeat spammer-friendly "open relays" by not allowing you to send e-mail unless your IP address was on its subnet (which was the case only when I was in my office). SBC has now switched over to password-based SMTP authentication, which makes me happy because I can send e-mail from anywhere.

I used to use (notice the past tense) Qualcomm's Eudora as an e-mail client. I've used Eudora for years and like it. Unfortunately, Eudora's config system is designed around the thought process of an individual who doesn't think like I do. I needed to set up the program so that I could pick up my e-mail from a spam-blocker service, which acts as a POP3 proxy, while continuing to be able to send e-mail via SBC's SMTP server.

To make matters even more interesting, the SBC e-mail address is in the sbcglobal.net domain, but SBC's SMTP server is in the yahoo.com domain. I had no problem making everything work from my office, where I was on an SBC subnet and never needed to use passwords, but it did not work properly from a hotel that used a different ISP.

After trying, without success, to make Eudora work from the hotel room, I e-mailed tech support three times over several days, but they did nothing but quote a Web-page FAQ to me. I called Eudora tech support, which is not a toll-free number, was put on hold for a half-hour, and was then cut off without ever being allowed to talk to a human.

At that point, I gave up. I'm now using Microsoft's Outlook, because it was trivial to set it up to work properly.

Why am I regaling you with my sad story? So I can talk about the importance of tech support in supporting the software engineering process. An organization that looks at tech support as a necessary evil is throwing away essential feedback that it needs to improve and refine (read "sell more copies of") their product.

Qualcomm is effectively saying that it would rather lose SBC DSL customers than understand, much less fix, a legitimate problem that at least one of those users has.

Maybe it's just a UI problem, maybe it's deeper, but the bottom line is that I couldn't get the product to work. Worse, details about the difficulties I was having will never make it to the engineers who need to address those difficulties because tech support placed barriers in the way.

If the problem had been escalated to a software developer (not a "support engineer"), that developer could make sure that the problem got fixed. As it is, my problem has disappeared down a black hole and will probably never be addressed. For the company's CEO, the reason why sales are diminishing will remain an eternal mystery.

Support organizations-if implemented properly-feed information back into the design and development process at three levels:

• Out and out bugs feed back into the implementation level. The engineering team needs to dig out the code and fix it. If this fix requires a significant refactor, they might push it back up to the design level.

• Problems of the "I know it does it, but it's too hard" or "I can't figure out how to do X" variety are design-level problems. The design team needs to rethink how they implemented a use case so that the program helps, rather than hinders, the users as they work through the required activities. If there was no use case, then there needs to be one, and the problem gets pushed back to the analysis level.

• Problems of the "I need to do this, but the program won't handle it" variety are analysis-level problems. The design team needs to develop a new use case and migrate it down through design to implementation.

Nobody will use your product if it doesn't solve real problems for real users (including those annoying rubes calling tech support). What better way to find out what to do than have your users tell you?

Tech support can provide you with exactly the information that you need to improve your design and implementation, but that information is of no use if you throw it away. If your tech support process doesn't capture the real problems that your users are trying to solve, and then feed back those problems into your development organization, you'll never have a chance of keeping up with the competition.

The people who call into tech support are subject-matter experts. If you treat them as an annoyance, they'll go elsewhere. Is that what you want?


Share this link: http://www.sdtimes.com/link/27946
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading