United Business Media EE Times


Search

HOMEMARKET INTELLIGENCE UNITFORUMSDESIGNNEW PRODUCTSCAREERSBLOGSCONTACTEVENTSSIGN UP!RSSMost Popular contentTrusted Sources

 


How to build tech support
Print this article Email this article Reprints RSS Digital Edition

EE Times


George RostkyIt was a waste of time and money, Charlie knew, but customers were demanding technical support. They were just spoiled. Charlie knew his products didn't break down; they were free of bugs; and any decent engineer should readily understand how to use them. So there was no need for customer support. But it was necessary, so Charlie reluctantly decided to create a support function.

Remembering some management-success stories from business school, Charlie decided to assign two people, Fred and Jack, to the project. He would later determine who was more effective, then have that person train and guide new people who might be needed in tech support. But how to decide? He couldn't listen to every phone call.

Then he remembered a lesson from his engineering days: You don't really understand something, an old professor insisted, unless you can quantify it. You can't be sure of anything unless you can measure it. It's not real if you can't give it numbers.

That goes for job effectiveness, too, Charlie realized. You should be able to measure that, just as you can measure voltage or current or kilobytes per second.

But how to measure. You can't go out and buy a job-effectiveness meter. Then he saw the solution, an obvious one. Easy, too. He would determine the number of phone calls Fred and Jack each handled in a day. To make sure the two men didn't sit around shooting the breeze, Charlie let them know he expected a good day's work; he'd count the calls they handled.

Fred won the contest easily. If a customer called with a problem, Fred first suggested that the problem was not with his company's product. Couldn't the problem lie with something else in the system? If the customer insisted that he had checked everything else, Fred provided a quick answer. If the customer called back with the same problem, Fred provided another quick answer. Fred was loaded with quick answers.

Jack spent more time with customers. He realized that customers weren't stupid; the obvious solution had probably occurred to the customer, too. And he didn't want to brush off customers by telling them to read the manual. Most callers had already tried the obvious and most had studied the manual. Jack wanted to understand the problem more fully before offering a solution. He didn't get many repeat calls, but he left a lot of satisfied customers.

Unfortunately, Charlie was measuring phone contacts, not customer satisfaction. He fired Jack and gave Fred a raise.





The views and opinions expressed in this column are strictly those of the author and should not be taken as an editorial position of EE Times or any of its other editors, publications or Web sites.


  Free Subscription to EE Times
First Name Last Name
Company Name Title
Email address
  Click here for your Free Subscription to EETimes Europe
 
CAREER CENTER
Looking for a new job?
SEARCH JOBS
SPONSOR

RECENT JOB POSTINGS
CAREER NEWS
SRC Expands R&D Centers
The Semiconductor Research Corp has added a new center to its university R&D efforts.

For more great jobs, career related news, features and services, please visit EETimes' Career Center.


All White Papers »   

 
Education and
Learning


Learn Now:












Home | About | Editorial Calendar | Feedback | Subscriptions | Newsletter | Media Kit | Contact | Reprints|  RSS|   Digital|  Mobile
Network Websites
International
Network Features




All materials on this site Copyright © 2009 TechInsights, a Division of United Business Media LLC All rights reserved.
Privacy Statement | Terms of Service | About