Is Cloud Support 'Racing to the Bottom?'
In the course of over 100 articles, I've been politely and quietly working to inform everyone about cloud and CRM best practices. After having wasted hours on a typically crummy support line of a cloud vendor, I can be quiet no more, I need a moment to rant.
Thu, December 01, 2011
CIO — 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: