There's a phenomenon that economists describe as a "race to the bottom," where vendors compete by undercutting in price, which leads to a \n\nreduction in quality and service. In businesses like airlines, trains, telecoms -- with huge fixed costs -- these downward spirals of service can last for \n\ndecades because, fundamentally, the customers don't have that much choice. Any vendor foolish enough to offer great service will see their costs \n\ngo 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 \n\nsupport 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 \n\nlowering 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 \n\nkeep 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 \n\ngot 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 \n\npercent 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 \n\ncommunity" -- 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 \n\nnothing: 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 \n\ncommercial ecosystem, where the callers are knowledgeable, savvy, and busy. They may know more about your system than you do, and they \n\nprobably have been puzzling over your manuals and code samples for hours. Because they're proud people who don't want to admit defeat. Most \n\nimportantly, 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 \n\nsupport team that you do for end-user support, you'll only get substandard outcomes like these:\u2022 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 \n\neducating the person with access to the resources that could actually make the problem go away.\u2022 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 \n\nunderstand that the manual was wrong about some specific detail of the API.\u2022 The person answering the support line has incentives to not escalate the problem quickly. So they'll bump around, banging their head into \n\nwalls...re-discovering what the caller already knows. \u2022 When the support person is not very knowledgeable, they'll keep trying to show that the caller has been doing something wrong. Even \n\nwhen the developer is working in a language that the support person doesn't really know. This is doing nothing productive, and only succeeds in \n\nwasting more of the caller's time.\u2022 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 \n\nthe 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 \n\nlot of low-cost labor supplies seem to be in those cultures.The Solution is ClearVendors, please realize that the most costly partner support in the world costs you less than nothing, because the successful developer in a \n\npartner or integrator will increase your sales. Make the incentives for your partner support team different, and have it report into the engineering \n\norganization. And finally, just abolish level-1 support for your partners. Seriously, relegate level-1 to your developer boards, and have all calls jump \n\nstraight 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 \n\ndollars.David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of \n\nSuccess" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy \n\nfocused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and \n\nDavid 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.