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


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
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