Sign up Now | Forums Home
Tech support: phone vs. e-mail
Post #1
01-19-2002, 02:18 PM
hadley
Site Founder
How do most of your software support calls start, and
who pays for the call? |
Most call us, and they pay long-distance charges |
14 |
22.95% |
Most call us on our toll-free line |
22 |
36.07% |
Most come in via e-mail |
19 |
31.15% |
Most come in via our Web site |
6 |
9.84% |
Voters: 61 |
Post #2
01-21-2002, 09:06 AM
TracyWetjen
Newsletter/Forums Member
hadley- interesting poll you posted. i'd also be interested in knowing from
the respondants if they have established Service Level Agreements (SLAs) that
dictate the method of contact their customers use to contact the support center
(ie- credit card charge per call, free support has only email as an option,
Gold Level has phone access, Platinum has 24x7 phone/pager, etc.). And if they
do have established SLAs, are they priced yearly as a percentage of the total
cost of the software purchase?
__________________
Tracy Wetjen
Technical Support Solutions (TSS)
www.techsupportsolutions.com
941-927-8596
Post #3
01-22-2002, 10:13 AM
Charles Mills
Principal Moderator
The Software sub-industry with which I am most familiar is mainframe and similar commercial, large ($20,000 and up license) systems. Here is a pretty typical scenario.
- Although called maintenance, the annual fee is actually a license renewal: you can't use the software unless you pay it.
- It is typically a percentage of the initial license fee, from about 12% to 20%.
- Support is included. 800 number, e-mail or web are all free (gift with purchase!)
- The vendor pledges a response (not necessarily a solution!) within a number of hours based on the customers' statement of the severity of the problem:
- Stops production -- two hours.
- Affects a business process -- four hours.
- Informational -- eight hours
Hope this gives some food for thought.
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Post #4
12-21-2002, 08:49 PM
Dave45000
Newsletter/Forums Member
I am a customer of one company that offers different levels of support. I used to pay for premium support as a matter of course. The problem is that once you become an expert with a particular product, the technical support person is not going to be able to provide meaningful support. Over the years, the competence of the support reps has fallen even as the cost of the support package goes up.
I'm starting to see this SLA thing as something akin to a warranty. The service provider sells you one, so they can get more revenue. But, if anything ever happens where I have to them for rework or support, I won't do it. To me, their inability to do the right thing the first time, demonstrates an inability to do any better in the future. Then, it's time to look around for another vendor.
I, now, no longer buy any support.
In addition, I know that I need a person not an email. Usually, if the support rep can calm me down, I'll solve it myself. I don't submit emails to get support. If they don't offer me a person, then they are not offering support.
There is something really wrong with this focus on costs that drive software vendors to substitute email for people. The software industry is said to be the most capital efficent industry on the planet. So why do we increasingly allocate costs to the customer? It's unnecessary. It's harmful. Gartner's numbers indicate that over the past twenty years costs have gone up from twice the acquistion cost of the underlying software to six times the acquistion cost. The TCO has barely improved the situation. The TCO ignores negative use costs--the cost driven up when a user stops doing work, tries to solve a computer problem, and ends up waiting for an email all day. Best productive use of software has fallen from 9% to 6%. Allocating more costs to the customer just reduces these numbers even more.
If you control a proprietary, but open standard and are a market dominator, then by all means ignore your customers. But, if you do not have market power, as in complementor companies, ignoring customers isn't possible, and making yourself more cost efficent is an exit strategy as you are making yourself more costly for your customers.
David Locke
Post #5
01-28-2003, 10:12 AM
hmotulsky
Site Member (inactive)
We provide support only by email. If someone calls, we ask them to email. If they insist on a call back, we do without haste. Email support gets priorty.
But we really do provide good support by email. Usually within an hour or two. Often with links to how-to articles or FAQs with screen shots.
Harvey Motulsky
GraphPad Software
Post #6
01-28-2003, 10:33 AM
MichaelHayes
Site Member (current)
Paying for Customer Support [QUOTE] Originally posted by Dave45000
The problem is that once you become an expert with a particular product,
the technical support person is not going to be able to provide
meaningful support.
I agree completely. I and most of my staff have gotten to the point with
most of our software tools that perhaps 90% of our questions aren't properly
answered by the so-called "tech-support" departments.
>I, now, no longer buy any support. We purchase support on only one product, our financial accounting package which comes with timely payroll and tax upgrades that we need.
>There is something really wrong with this focus on costs that >drive software vendors to substitute email for people.
Agreed.
>If you control a proprietary, but open standard and are a >market dominator, then by all means ignore your customers. >But, if you do not have market power, as in complementor >companies, ignoring customers isn't possible, and making >yourself more cost efficent is an exit strategy as you are making >yourself more costly for your customers.
As Pres. & CEO of a software company serving the education market, I can confidently say that our reputation is based on our customer support. We provide 800# support primarily because many of our customers cannot make toll calls from their offices within schools. If that limitation wasn't there, we'd have to look at our "toll-free" support more closely.
Customer support costs are tangible and painful for a business owner. We pay for telephone lines, long distance, support staff, office equipment and office space to hold them. We pay for this every day, even when there are few calls.
We've considered pay-per-call or pay-per-incident scenarios, but none of them make sense in our market. Instead we have each of our customers sign a mandatory maintenance agreement (note that they MUST sign it) before we ship them their software. Then we follow that up with excellent telephone support, in combination with email for those who like to use it. We bill them for about 20% of their license fee every year, and they can cancel the maintenance contract simply by not paying.
Have we lost customers over the years? Of course we have. But I can't recall losing a single customer as the result of poor customer support.
So in general I agree with your post. Companies have an obligation to provide
support of equivalent, or superior value to the cost that the customer is paying
for that support. We require our customers to pay a 20% annual premium, and
then we provide them with support that is 100% better than they expect.
Charging for support is not evil, and providing spotty support is not evil
if you have not misled your customers (I'm thinking here about discount game
companies that sell computer games for $5 and the like). But asking your
customers to pay for a level of support that you can't deliver is unwise, unethical,
and cancerous for a company in the long term. Furthermore, with the glut
of
talented people looking for jobs in today's economy, it is also very unnecessary.
Michael Hayes
Post #7
01-28-2003, 01:15 PM
DaveBrown
Moderator
I work with a lot of companies to improve their customer support (that's what I do for a living). So, I can say with certainty that most companies are trying to move their customers toward email support. The reason? It is easier to provide acceptable response times. When people call for support, they expect to be answered within a minute or two...certainly they don't expect to be on hold for 5 or ten minutes and 15-30 minute hold times are not tolerated. Yet, the service level expectation for email is much more lenient. If you respond in 15 or 30 minutes (and not just an automated acknowledgement), you probably impress the heck out of the customer.
However, there's a trade-off. Providing technical support via email is often less efficient than a phone conversation. Troubleshooting via email can result in a long, drawn-out 'ping-pong' of emails. Many companies are pushing their customers toward email, but will respond with a phone call if that is the more efficient way of resolving the issue.
By the way, I always recommend that you offer telephone support...you just
might make the other options more visible and even more attractive.
__________________
Dave Brown
President
Support Center University
303-494-4932
dave.brown@SupportCenterU.com
Post #8
01-29-2003, 06:22 AM
MichaelHayes
Site Member (current)
I agree completely, David. As we review our customer support
procedures and costs, the following are consistently the conclusions:
- Some customers absolutely need telephone response, either due to the
complexity of the problem, or the need for immediate help.
- Too many customers
THINK they need telephone response, when the answer
they need (often a simple one or two-step instruction) is available
via online help, our web site, or in the User's guide.
- Email is a great
way to organize incoming customer support requests, and route them to the
people most likely to provide the most helpful response.
So what does a company known for customer support do? We try to strike a
balance between staying on the phone with customers, and gently pushing
them to use the online help, or website-based help. We have a couple of well-defined "crunch times" during the year, when our tech support call rate triples or quadruples. It is also at these times that our most complex and lengthy calls become more frequent. So it's a double whammy.
This year we'll be concentrating on adding more detailed content to our
web site, with graphics and step-by-step instructions, in the hope that
we'll be able to guide customers to those references, rather than spending
30-60
minutes on the phone with them. Our goal is to be able to reduce the
number of customers who had to leave a message (we don't keep people on
hold), while
maintaining or improving the rate of problems we solve with the first
contact.
The reality is that some people simply need to have another human help
them through the rough spots. The trick is to help them, but not at the
expense of everyone else.
Michael
Post #9
01-29-2003, 09:26 AM
braddes
Site Member (current)
Head count metrics
This is a great discussion, thanks everyone. Does anyone have a comment on head count to customer count as a ratio for customer support. Obviously this will relate to the complexity and quality of your software. In our case the complexity is relatively low (top of the bottom 30%) but stability is not yet where it should be (6 months away)
Post #10
01-29-2003, 09:53 AM
jintner
Newsletter/Forums Member
We never looked at head count as a function of customer count in technical support. We measured average # of problems a rep could solve in a given week by product or product line. Then we mapped that against our problem counts, considering acceptable backlog and spikes associated with new releases. From that, we could extrapolate our needs.
Post #11
01-30-2003, 06:28 AM
MichaelHayes
Site Member (current)
For a small company (only 10 people) we've done some fairly extensive analysis on our customer support activity. We've logged phone calls for the last 10 years, and for the last 5 years we've tracked calls per month, calls per customer site, average calls per site per month, etc. Because of this we can accurately project call volume throughout the year based on the number of customer sites we have. It's not rocket science, just diligent record keeping.
We also have looked closely at the number of customer support reps vs. customer count. Our software, although complex, is easy to use (sort of like Microsoft Word where most users access perhaps 10% of the whole product). In addition, our customers use our software in peaks in valleys throughout the year, peaking in May and August (end and beginning of the school year), and often using it infrequently in between. Because of these two factors, we only employ 1 customer support person per 800 customer sites. Once our customer count starts to put us past that ratio, we start looking to add someone else.
That said, if the whole year was like May and August, we'd probably have to double or triple that ratio to be effective.
I guess my suggestion is to be wary of another company's customer support staff vs. customer count ratio. A lot will depend on complexity of the product, average time per call, level of service required and many other factors that could be completely different from company to company.
Michael Hayes
Post #12
01-30-2003, 09:13 AM
braddes
Site Member (current)
Great info thanks
Post #13
05-27-2003, 11:10 AM
mikael
Newsletter/Forums Member
Ratio of agents to customers
Over time, you should be able to develop some good data about your product such that you can forecast, with some degree of accuracy, the number of calls-per-copy you are likely to get. You should also be able to look at the type of call and the competency level of the caller. As the user acquires and begins using the product, at what point do the calls start? What expertise do you need on your end of the phone line to handle those calls?
Every technologically complex product carries a support burden. Every user must invest some time in learning to use the product in order to reap the benefits of that product. For the manufacturer, the question is: Where will you address your product's support burden? If you address it early in the product life cycle, you will spend less money and be more effective, but the downside is that you're spending early dollars when you probably don't have any sales income to offset the investment expense. If you wait until after the product has shipped, you have the benefit of some income but are in a much less advantageous position from which to work. You will end up spending far more the longer you wait.
There Ain't No Such Thing As Free Support -- not now, not ever. Both user and manufacturer are going to pay for support in one form or another; the only question is: how and how much?
--mikael
----------
mb&a, inc.
www.mblaisdell.com
mikael@mblaisdell.com
Post #14
05-27-2003, 11:32 AM
Dave45000
Newsletter/Forums Member
On the notion that tech support calls can be eliminated by putting the content in the documentation, I would say that Microsoft does the opposite. They remove content from the manuals, and specifically instruct the customer, in the manual, to call technical support to find out more. This happens when technical support is provided free with the cost of the product, and Microsoft is focused on building a relationship with the caller.
Whether you realize it or not, where you put content represents a content distributional strategy. Typically, content is allocated 80% of the most frequently performed tasks are covered in the manual, 20% of the most frequently performed tasks are covered in training classes, and %100 of those tasks are covered by technical support. This 100% allocation happens, because some users are aliterate (not misspelled) and prefer speaking to someone rather than reading in a manual. So even if you push content back into the manual, some customers are still going to call.
When a customer calls technical support, you have an opportunity to deepen your relationship with that customer. The money to pay for that relationship will come from your increasing return. But, you have to capture the increasing return. A surprising number of companies do not capture it.
David Locke
Post #15
05-28-2003, 04:25 AM
Charles Mills
Principal Moderator
Does anyone have the experience that customers actually read documentation (other than perhaps one user in fifty who takes the manual home and reads it from cover to cover)?
Does documentation matter? You have to have it to sell products (other than at the lowest end) but does anyone actually read it? Does it matter what you put in there?
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Post #16
05-28-2003, 04:43 AM
Charles Mills
Principal Moderator
Documentation is dead
I'm going to go out on a limb here. "Documentation is dead." -- Charles Mills, May, 2003.
Read my article on the SIIA conference. (Currently featured; search the site archives for "SIIA" if you're reading this after June 2.)
You car has 100 microprocessors. Did you read the documentation for the software? eBay and Amazon are effectively software companies, but there's no user documentation for their software.
Salesforce.com is currently the poster child for success in software. Does anyone know if they have a user manual?
The future (at least the near-term future) is clearly hosting and browser clients. If you aren't going to deliver software to the user's desk, why deliver a manual?
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Post #17
05-28-2003, 09:24 AM
mikael
Newsletter/Forums Member
There's more to documentation than the manual
Printed user manuals are certainly going away, but I wouldn't count documentation down for the count just yet.
You mentioned SalesForce -- I tried to use their product myself in my consulting practice. No, they don't have very much in the way of documentation, that's why I called several times during the set-up process. Had they had sufficient documentation available, those calls would not have been necessary.
The point remains that there is an investment in learning that any user of a complex product must make in order to be able to use it. That fact necessarily results in a support burden for the manufacturer.
There are several ways to address that issue. One of the best is to design the product so that it is as intuitive as possible and therefore reduces the learning time required of the user. Addressing the support burden at the design stage is the route that companies such as Intuit took with their flagship products -- which have the lowest calls-per-copy rate in their class.
I remember another client that bragged to me that his product would need neither manual nor support group. I laughed, and sent his secretary down the hall to install the product, telling her to call the CEO's extension as if it were the support line. At about the fifth call, el presidente "got it" -- extensive testing is a good thing to do when attempting to design the support burden out of the product.
How you address that support burden is up to you -- but address it you will. Usability Design, Documentation, Training, Professional Services, the Customer Contact Center, the Support Web Site -- all of these are about the same thing - assisting the user to become productive with the product.
__________________
--mikael
Mikael Blaisdell
mb&a, inc.
www.mblaisdell.com
mikael@mblaisdell.com
Post #18
05-28-2003, 09:58 AM
Dave45000
Newsletter/Forums Member
The need for documentation is market specific:
Technical Enthusiasts/Geeks need reference material.
Early Market need user manuals.
Late Market need ueser manuals.
Laggards and Phobics do not need any documentation.
The UI is market specific. And, it is the UI that drives documentation needs:
Technical Enthusiasts/Geeks need feature bloat.
Early Market doesn't like feature bloat.
Late Market demands that feature bloat go away, so you sublimate as many tasks as you can.
Laggards and Phobics demand embeddedness, which is the extreme end of the sublimation scale.
On the burden that learning creates, it is not just a burden for the manufacture. It is a burden on the customer. Some of the cost of training ends up in the TCO, but only invoiceable training. And, training and reading and calling techical support that isn't invoiceable is not in the TCO. Neither is the salary contribution of the users sitting in the classroom. These are all off-the-books costs. They are invisible. They constitute what Gartner (1988/89)called negative use costs when they formulated the TCO. These costs were omitted specifically, because no mechanism existed to qunatify them. These are the costs that CFOs intutitively feels when they claim they are not getting the productivity, for which they paid. It is a contributing factor to the current recession.
Gartner's recent productivity figures show that network enabled applications cost six times the acquisition cost and deliver no more than 18% (total positive use costs)/ 6 (infrastructural multiple), or 3% for a perfect implementation. So ROI claims above 3% are sales hokum. These are average numbers. Now, add WiFi, et. al., which was omitted and the infrastructural multiple goes up. Increased security costs will drive the multiple up as well and ROI down.
The only way to fix negative use costs is to fix the UI. Fixing negative use costs will increase productivity above that 18%.
The numbers are Gartners numbers not mine.
The day is coming when you will be able to generate a user manual from code and make user manual content conform to the user's existing knowledge.
Yes, executives at ISVs always make the claim that nobody reads the manuals, but that is a generalization. It is an assumption that costs them in the end. The last time a VP of Dev said that to me, he was investing all his effort in a pre-sales training program that incorporated some other assumptions the were making and scaring the hell out of the customers. The fact that the conversion rate was zero should have signalled a need to rethink the content of the training program. Ultimately, the students never bought the product. So some of the content assumptions were false and the content distributional strategy was wrong as well.
This company also wanted to be the center of the universe for ideas it didn't invent. It wanted to teach everything that needed to be learned. But, this is a wonderful opportunity for a content value chain. Leveraging existing content providers will reduce the ISVs documentation burden.
And, again, I wouldn't want my documentation to go away, because it is part of my pre- and post-sale enactment chain. There is an experiential component in the post-sale enactment chain that can potentially tie your customer to you. If you throw it away, how are you going to keep that customer.
Keep in mind also that the conversion to web services takes from being a product to being a service. Switching costs could be reduced by this conversion. Then, what? Consumer marketing, no thanks.
David Locke P.S. There is a trend out there right now of developing your demand chain. There is another trend driving the development of your service chain. ISVs may not be doing this yet. But, the trail has been cut.
Post #19
05-28-2003, 10:12 AM
Dave45000
Newsletter/Forums Member
Charles, the documentation for a web service is on the web page itself. Further, the interfaces are documented in reference manuals. That a user sees no documentation is the goal, but it depends on the user not needing any. The amount of documentation has not gone down on the administration side.
If an application can follow the exact thinking of its users, then no, you don't need a manual. But, think about how most programmers build applications. The user interface is last.
Programing is now being done by two different groups of people: the programmers, and the website developers. The website developers think interaction design. A few programmers create good interfaces, but most just throw stuff on a panel, even unrelated stuff, and don't bother relating stuff that needs to be realted. These programmers don't even use the one task, one panel rule, so context-sensitive help is a mess.
It will be about five years before web services are ubiquitous. After that, the Geek market will still hold to programs on the desktop. The return to the line interface is an example of this cultural divide. You can make more money on integration applications with web front-ends, but new constraint-busting concepts are going to to through the Geeks first and then the Early Adopters. They can go web at the Early Adopter, but the Early Adopter will continue to rely on the Geeks to reduce their technical risk in the buying decision. So don't expect the entire IT market to switch to web services.
The same thing goes on the issue of conversion from computers to computing. The Geeks will keep their machines and probably buy more of them. Everyone else will need a network appliance, which for the near term will still be a computer, or a handheld device. Another generation of phones might surprise us, but I don't see the telcos putting the application infrastructure in place.
David Locke
Post #20
07-14-2004, 06:44 PM
dubicki
Moderator
I'm surprised no one has mentioned self-service ... such as access to Knowledge Databases (a la Microsoft). We've had that for use, long before Microsoft adopted such practices.
The other option which I don't see mentioned, is the use of a bulletin board feature to essentially log all conversations/correspondence between the customer and support staff. This offers numerous conveniences, including a progression of the problem resolution. More effective than email IMO.
Post #21
07-14-2004, 06:52 PM
dubicki
Moderator
[QUOTE]
Originally Posted by Dave45000
The day is coming when you will be able to generate a user manual from code and make user manual content conform to the user's existing knowledge.
I once worked at a place, whereby the design/and high-level specs used by
development, could be easily tweaked and turned into user documentation.
Required quite a bit more upfront work and foresight by analysts and product managers, but essentially, this worked very well.
Post #22
02-10-2005, 03:37 PM
Charles Mills
Principal Moderator
Hey! Where's the stuff about chat???
If you're looking for the recent discussion of "chat" as a support tool I made it into its own thread here http://www.softwareceo.com/forums/showthread.php?t=1353 .
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Sign up Now | Forums
Home
|
