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 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 dollars.
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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.