Originally published on March 7, 2007
Starting a software company from scratch, on-premises or SaaS, is no small task. The barriers to entry into the Enterprise software market are significant to say the least. To top it off, there are a number of things that can hinder adoption of your solution in large corporations, putting a stop to your venture before it ever starts.
Below is a list of five “issues” witnessed when selling SaaS solutions to Fortune 1000-sized companies. Assuming you have everything else in order, be prepared to address these objections…
Oh, you’re a “startup”.
Of all the issues that have come up, this is the one that you simply cannot avoid or steer around. I have always addressed it openly and to the point. “Yes, we are a startup”, I then tell them that this is something we have thought a lot about; how do we convince our client that we are the ones they should take a chance on? I always tell them that “I can’t go back in time five years and start then, I wish I could”.
As much as SaaS vendors like to talk about “low sunk cost” in selling SaaS solutions or the flexibility of on-demand pricing and being able to drop the service at any time, the reality is the company who says “yes” to you isn’t just making a monetary investment in you; they are investing their time and resources in your product. They are not looking to “just switch” if they aren’t happy. Regardless of licensing or contracts, they do not want to have to find another solution.
The biggest issues with a startup is that of sheer existence. Will the vendor be around beyond next week? This is a real concern to customers and, frankly, it is warranted. There is little that can be done to alleviate the chances of existing for a long time. The first is to show the customer the $20M in fresh VC money that was just deposited.
That should release some of the pressure, although in reality it probably shouldn’t. Barring that kind of funding to show off, the only solution that makes sense is to take out an insurance policy for your customer. Put your source code into escrow with the beneficiary listed as your customer. This way, if your company goes away, at least the customer can take the software and continue to support, and develop it, internally. The software escrow process is actually quite extensive, as it requires both source code and binaries, installation manuals, checklists, and the developers personal contact information.
After the existence hurdle comes reliability concerns. With everything running on “your network”, how can the customer be sure of 24/7 access to the system? The best bet is to partner with a reliable hosting company, preferably one that understands your business model and can provide more than just hosting space. There are companies out there called SaaS Enablers, such as OpSource, which combine everything from server hosting, on-site DBAs (who learn your schema and can offer performance improvement tips) to first level tech support for your application.
OpSource also offers 100% uptime guarantees and you can have your customer’s IT staff talk to someone there if they have questions about the data center itself. This is my preferred method for launching a startup SaaS business, but there are other ways. You could build your own data center, and if you have a great deal of VC funding, perhaps that is the way to go. But being able to show 100% uptime guarantee, and back it up with referenceable accounts, is the key to overcoming this objection.
Using a company like OpSource also addresses the scalability and support questions your clients will have. If you architect your product correctly, OpSource can monitor your application and scale it where needed on-demand. If you need more application server horsepower or more database storage, those resources can be allocated on-the-fly, ensuring your system maintains stability and integrity. (note… I am not a pitch man for OpSource; they just happen to be great people with a great service and they have been very helpful to me).
Those objections, existence, reliability, support, and scalability, are really the most difficult to address, the first one being the hardest. Never try to skirt the issue of being a startup; explain what you are doing to alleviate the potential problems and get through it. While I have seen those as objections, I have not seen them as show stoppers. The following I have seen as show stoppers.
In Part 1, the Myth of SaaS Ubiquity was addressed and dispelled. It is simply not the case, and the following objections to your SaaS offering will make you scratch your head and ask if you are still in 1994. The first stumbling block in getting your SaaS offering in the door is going to be the antiquated corporate policies in place. These will include Internet access blocking, locked down PCs (no activeX controls or Flash animations), disk space quotas (severely limited local disk space), and more.
The best bet as a SaaS vendor is to include someone from their IT department from the beginning. In fact, if you provide a line-of-business application rather than an Enterprise support product, you may be able to get the IT department to champion your product and do a SaaS pilot. If their IT personnel are exploring the blogosphere, perhaps they believe SaaS is ubiquitous and feel left out!
Outside of the legacy controls still present in many large companies, there are some other factors that are present in just about every company, big or small; an internal need to justify infrastructure expenditures. If the CIO six months ago signed off on $2M worth of new server hardware, the last thing they are going to be looking for is software that does not run on it! Whether recent or not, the internal investments must see a return, and SaaS does not fit the bill. Remember, if they can’t justify that expenditure, they might not get more money down the road, and that is simply not going to happen.
Finally, and perhaps the most difficult hurdle to overcome when pitching SaaS delivered software, is the job protection angle that the leader of the IT group might take. Why would the IT Manager want to give up control when that would mean less headcount, which leads to smaller budgets, which leads to smaller salary and smaller bonuses? If you are selling to the C-level, talking about reducing FTEs can be a great thing. If you are selling to line managers and Directors, this is the slippery slope theory in action. They do not want to give up control and will hold on for dear life and at all costs.
What those objections have to do with Vendor Sustainability in the SaaS space is elementary. Focus on the needs of your target market. If you are set on being a Pureplay SaaS vendor in a market that does not like Pureplay SaaS vendors, you will fail. At the same time, if you are in a market that does not need Pureplay SaaS vendors, you might not fail, but you will certainly spend more money than you have to; why take on any more of the support costs than you absolutely have to?
Part 3 will focus on a couple of ways to appease those Enterprise clients who aren’t keen on your SaaSy ways.