Is Support a Cost Center or a Product? (If you do SaaS or Open Source, It’s a Product!)
Posted by Bob Warfield on August 29, 2007
I always find the RedMonk blog interesting, and this time it has to do with his post on Making Money in Open Source on Support. Coté says some things that got me frothing at the keyboard again.
Developers Need Support, But It Is Seldom Offered With Enough Bandwidth
First, on the likelihood you can make money selling support to ISV’s:
“In general, I’ve found that ISV programmers (people who write applications [packaged or SaaS delivered] to sell to other companies, not “corporate developers” who write in-house applications) are less prone to use support for software, closed or open source.”
“This is the kind of mentality I encounter among programmers quite a lot: it’s insulting to them to suggest that they need help.”
Let me explain about the ISV perspective, because that’s the world I’ve lived in all my career. This has amazingly little to do with machisimo, being too cheap, or being insulted. Rather it has everything to do with bandwidth. We’ve all used Tech Support. Who do you know that loves it? Sitting for hours on an 800 line being tortured by music and that painful interruption that’s worse telling you how important the call is to them. So why don’t they answer then? How would you like to be waiting on some Tech Support guy to tell you all the standard stuff (take 2 reinstalls and call me in the morning) while some high dollar Enterprise customer is chewing your CEO’s ear off about why your mission critical software doesn’t work? You know its going to take 3 escalations to more senior folk before they even understand what you’re trying to tell them and meanwhile your CEO is ready to fly your entire team to Nowhere, Iowa to work at the customer’s site just to placate them. Been there, done that.
The insult is not that I need the help, it’s that you think you’re helping by doing that to me!
If you want to make money selling support, treat it as a product, not a cost center. Don’t send me to Bangalore. Don’t put a guy on the phone with my architect that can’t carry my Alpha Geek’s jock strap. Get somebody real that can go toe to toe. But is that really a viable model? Can you afford to hire Alpha Geeks to deliver support? Probably not, because they will only do it if they have that rare combination of Alpha Geekdom and craving human contact so much they’ll take it under the duress of Tech Support.
SaaS companies come off better in this respect because its easier for them to put their Alpha Geeks onto the problem. The Alpha Geeks watch the problem as it unfolds and directly access the data center to fix it. They don’t have to struggle to remote control the customer through an On-premise fix. Service for SaaS vendors is a product, not a cost center, but it’s also a product that is cheaper for SaaS companies to deliver because the service can be delivered in many cases without them leaving their desk and sometimes without the customer even knowing. The latter is a problem too if you want the customer to value the service, but we’ll save it for later.
Despite all that, Enterprise ISV’s still spend time on the phone to companies like Oracle and Microsoft trying to get help, and they keep their maintenance paid up because you never know.
Coté offers a good list of types of support provided: bugs, scaling, configuring, upgrades, finger pointing (or proving who’s “right”: the software or the user), re-setting expectations (the software actually won’t scramble an egg inside it’s shell like the sales guy said), and your million dollar nightmare (customizing and supporting out-of-date deployments).
He goes on to suggest some other types peculiar to open source: Updates, Platform Certification (“Stacks”), Product Improvements and New Features. Yup, been there and delivered those. There are two that deserve more discussion: being an advocate to the community, and professional services customization gigs.
On being an advocate, this seems so far removed from the realm of what Tech Support does, that I wouldn’t even include it here. I’ve seen this work best when Marketing or Sales handled it as part of customer relationship management. Yes, Tech should be able to do that, but I’ve rarely seen the skillset and mentalities located there to be succesful.
On professional services to customize, yes, this is a very real opportunity to sell more product. It isn’t really a support issue though. Yes, many open source consumers will just modify the code themselves, but I would hesitate to speculate that this happens the majority of times. See my thoughts on Professional Services end runs though, as it is something you must guard against.
I want to cover a few types I’ve run across that are also biggies for support but aren’t mentioned:
Education. A tremendous amount of Technical Support calls boil down to the customer needing to ask a question. The question may be so complex or confusing that it gets escalated all the way to the Chief Architect, but its still a valid role. Answering questions is important, and I would think even more so for Open Source where the questions may have to do with how the code operates.
Professional Services End Runs: This has been the source of more bad feelings all around than any other phenomenon I’ve seen. Here is the scenario. The customer buys the product, but for a variety of reasons they do not have the money to get it properly installed:
– They picked a bad VAR (low cost bidder, anyone?) who spent the budget without delivering.
– They never could get enough budget internally for a proper engagement, and choose to finesse it this way because they’re cheap. Don’t laugh, I’ve had customers ‘fess up that this is exactly what’s happening and persuade CEO’s to deal with it in the interest of future business.
– The absolute worst: Your own professional services people failed. It may not even be their fault, but now the Customer has Righteous Indignation on their side and you will get that software installed or else!
– Almost as Bad: Your organization measures performance and pays on those measurements in such a way that one organization throws another under the bus to make their bonus. Professional Services throws Tech under the bus. Or its implicit, and Tech hires cheap people who can’t deliver and everything is escalated to Engineering. Yuck!
Companies that make Services a Product instead of a Cost Center are much better set up to think about these problems and deliver a better experience to their customers.
I didn’t see much rumination about Oracle’s attempt to steal Red Hat’s business. One of the problems of basing your model around selling support for an open source product is differentiation. Perhaps you can achieve better focus, but someone else can take a credible shot at stealing your business. At the very least this will exert downward pressure on your pricing.