There’s a phenomenon that economists describe as a “race to the bottom,” where vendors compete by undercutting in price, which leads to a
reduction in quality and service. In businesses like airlines, trains, telecoms — with huge fixed costs — these downward spirals of service can last for
decades because, fundamentally, the customers don’t have that much choice. Any vendor foolish enough to offer great service will see their costs
go up…and their sales go down. Despite complaints about lousy service, the customer won’t tolerate big price increases.
Unfortunately, the customer support function of many (most?) software and cloud vendors is very vulnerable to this effect. If a customer
support group is a cost center, the imperative is to reduce costs. If support is a meager profit center, the endless pursuit is to keep margins up by
lowering costs. Sending the support team off to a place where wages are low is one solution in play, as is putting in all kinds of mechanisms to
keep the support questions away from your high-cost engineers.
This makes perfect sense when it comes to consumer tech support. The customer isn’t willing to pay much (if anything) for support, so you’ve
got to keep the calls below $10 each. Which means they’ve got to be short, even when staffed by the lowest cost people. If you’re lucky, 60
percent or more of your calls will be 12-minute cases of RTFM or PEBCAK (Google it…). This is the level of support that is often relegated to “the
community” — which may indeed do a better job of providing relevant information than the vendor does. It’s not called a race to the bottom for
nothing: you’ll find it in software and cloud vendors alike.
That low-cost, low-value, approach makes no sense at all, however, when it comes to developer or partner support. This is support for your
commercial ecosystem, where the callers are knowledgeable, savvy, and busy. They may know more about your system than you do, and they
probably have been puzzling over your manuals and code samples for hours. Because they’re proud people who don’t want to admit defeat. Most
importantly, the reason they’re even working with your system is to make your company and your customers more successful.
As with everything in business, measurements and incentives directly affect outcomes. If you use the same metrics for developer/partner
support team that you do for end-user support, you’ll only get substandard outcomes like these:
• The person answering the support line knows less than the caller. So the person with the problem has to waste even more of her time
educating the person with access to the resources that could actually make the problem go away.
• The person answering the support line treats the caller as yet another person who didn’t read the manual. It takes them a long time to
understand that the manual was wrong about some specific detail of the API.
• The person answering the support line has incentives to not escalate the problem quickly. So they’ll bump around, banging their head into
walls…re-discovering what the caller already knows.
• When the support person is not very knowledgeable, they’ll keep trying to show that the caller has been doing something wrong. Even
when the developer is working in a language that the support person doesn’t really know. This is doing nothing productive, and only succeeds in
wasting more of the caller’s time.
• The support person will want to close the case early, even when the problem isn’t fixed. So the person with the problem has to re-open
the case, wasting more wall-clock time and impacting the partner’s schedule.
All this goes double when the support person is from a culture that has trouble saying “I don’t know” or “we made a mistake.” Unfortunately, a
lot of low-cost labor supplies seem to be in those cultures.
The Solution is Clear
Vendors, please realize that the most costly partner support in the world costs you less than nothing, because the successful developer in a
partner or integrator will increase your sales. Make the incentives for your partner support team different, and have it report into the engineering
organization. And finally, just abolish level-1 support for your partners. Seriously, relegate level-1 to your developer boards, and have all calls jump
straight to level-2. Stop messing around: your engineering team may actually learn something from outside developers.
Partners and Integrators, boycott vendors that offer crummy developer support. The only way anything will get better is if you vote with your
David Taber is the author of the new Prentice Hall book, “Salesforce.com Secrets of
Success” and is the CEO of SalesLogistix, a certified Salesforce.com consultancy
focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and
David has over 25 years experience in high tech, including 10 years at the VP level or above.
Follow everything from CIO.com on Twitter @CIOonline.