"Software support" is an oxymoron for on-premises enterprise software. By the time the business customer installs the on-premise software, gets it connected and running with the database/application server/operation system/monitoring system/etc., creates and opeartes parallel development/test/regression environments, customizes the software to fit their business, determines how to operate the software (monitoring, backups, performance tuning, etc.) and figures out how to use it to benefit their business, the customer knows a lot more about the software in a "real-world" context than the software vendor who created it!
Plus, the on-premise software vendor has no idea how the software is configured, what customizations and system integrations have been performed, the data in the system, etc. This makes it very difficult for the on-premise software vendor to "support" the software they originally shipped on a CD.
Case in point: Yesterday, we ran into an issue with BEA Weblogic, where it created an invalid WSDL for a web service we were writing. I called up BEA, and got the age-old first question: "What version on you on?" Then "What service pack? Any patches? What operating system? What OS version? Which database...?"
BEA needed to replicate the issue in their environment (an error in the customer's environment isn't very helpful to an on-premise software vendor), so we had to write a generic test that demonstrated the error, and email it to them. They promised to try to replicate the issue and get back to us...
I'm not picking on BEA in particular here, just pointing out how difficult it is for an on-premise software vendor to support a hundreds of software versions and dozens of platforms that their software runs on (each platform component with many more versions), in customer environments where the vendor has no idea what's happening.
If/when we get a response, I guarantee it will be one of the following answers:
- You need to upgrade to our latest version
- It's not our software, it's the operating system/database/driver/etc.
- It's due to a customization, or your code
- Sorry, we can't replicate the issue
- A fix is scheduled for the next service pack/version
The common element of all these answer is, of course, they don't fix the problem! So the only path for enterprise software customers is if a bug is found, work around it, because the odds of the vendor providing a fix expediently is about zero.
SaaS is, of course, completely different - the SaaS vendor is responsible for making the entire stack work together, the SaaS vendor knows the configuration/data/usage pattern already, and when a fix is created it is deployed to every customer, automatically.
An SaaS support anecdote: We're an SaaS vendor with close to a half-million users, and I called a user yesterday who had several long response times, to find out her intention with her use case. She didn't report an issue, in fact she had found a workaround already, but I noticed it because it showed up in our monitoring of user issues. It looks like the issue was the result of a fairly rare combination of user roles, so I wrote up a ticket and the fix will be in the next patch.
Can you imagine Oracle or Ariba calling a user to investigate a performance issue that the user hadn't reported?
A mature SaaS solution has monitoring built in that tracks and notifies the vendor of any errors the user receives, reports that fail, long-running response times, etc. And the SaaS vendor proactively finds and fixes issues because they know that user satisfaction, adoption and usage are the primary drivers of their revenue and profitability.
This is a big beneficial element of the SaaS customer ownership experience, one that most buyers don't realize they will get when they evaluate a SaaS solution.
Comments