Creating a SaaS Trust Architecture is your top priority, because if your SaaS customers do not trust you then nothing else matters.

If you are trapped underwater the Rule of Threes says you can survive 3 minutes without air. Your top priority is clear and simple: find air to breathe, and quickly.
What should your top priority be when rebuilding your ISV to survive and profit from the shift to SaaS?
Reading press and analyst reports on SaaS you might think your top priority should be building a scalable back-end platform. Or, maybe your priority should be to select the right rich-client development tool.
These are certainly important issues, but they are not your top priority. Your top priority in rebuilding your ISV is to create your SaaS Trust Architecture. It really is as clear and simple as that.
The reasons are simple and pragmatic:
By shifting to SaaS you are asking your customers to make a massive change in the way your two companies interact with with each other. Your customer will be truly dependent on your ability to deliver what you promise. In a sense they are putting their life in your hands.
I am sure that they do. But this trust is for your current business relationship with your installable products. That is very different from what you should expect when offering your software as a service.
Your customers currently use your business application to run part of their business. They do not rely on your company on a day-to-day, hour-by-hour basis. With SaaS that all changes.
The stakes of the game become a lot higher with SaaS. You will be asking your customers to trust you with their data. And that is a big leap from the customer/ISV trust relationship you have at the moment.
The new relationship will require a completely new level of trust in you and your company.
Your SaaS Trust Architecture must be at the heart of everything you do, including:
Each technical and business decision impacts on trust. In each case you must take into account how your customer’s trust in you will change—positive or negative—as a result of each decision. And this is not just relevant to the decisions before the sale is made. You are moving to a recurring revenue model so you will need to keep proving yourself each and every day.
Just be looking at some typical service level agreements by companies offering SaaS solutions you get an immediate idea of how much trust to put in that company. In many cases the trust level is zero.
This is something that I will be looking at on a regular basis with reviews of selected service level agreements. By seeing how other people are getting this critical aspect of the SaaS business totally wrong you can avoid making their mistakes.
The number of interfaces between you and your customers increases with SaaS. This makes it everybody’s job to be aware of the “trust impact” that they can have on your customers.
You currently operate at arms-length from your customers and their running applications. With SaaS you are directly involved. Every move you make—every moment of every day—impacts your customer’s level of trust in you and your service.
One ill-considered email from your support team in reply to a customer’s question about system availability can destroy your investment in building and maintaining trust. Each and every member of your team must therefore fully understand the impact of what they do and say (or do not do, and do not say) will have on your customer’s perception of how trustworthy you are.
Remember: trust takes a long time to build, but no time at all to lose.
A big challenge that you will face in rebuilding your ISV business for SaaS is that you will have to offer your customers a higher level trust than you might currently have in some (or even all) of your own suppliers. This is a key aspect of your risk in offering a SaaS solution, and this is exactly of sort of risk that you have tried to avoid in the past.
A key issue that all ISVs have had to address in the past is the extent to which they can afford to be dependent on external suppliers. This issue often comes up in discussions about the use of development tools compared to doing everything in-house. I can certainly recall a lot of discussions with our application ISV customers when selling application development tools in my previous life.
As you move to SaaS you are going to have to face up to coping with supplier risk is a fact of life for all SaaS ISVs. While you might have been able to justify developing your own database abstraction layer (for example), you are not going to be able to develop all (or even most) of your SaaS platform yourself. You are going to be dependent on a lot of external suppliers, many of which are new players in the market.
Getting all of these moving parts to work together in a reliable manner that you can repackaged for your customers is a critical part of what it means to be an SaaS ISV. It is your job to come up with ways of abstracting the risk so that you can offer a higher level of service to your customers than you might get from your suppliers.
You have a big advantage compared to the new entrants who will be trying to steal your customer base with their new SaaS-only offerings:
Your new competitors do not have either of these benefits. While they might have a lot of VC money to spend on high-end hardware, advertising or building the latest Web 2.0 client—what they do not have is any quick way of getting their potential customers to trust them with their critical data and applications.
This is where you are way ahead of the game. You have trust and can build on that as part of your defensible competitive position for your vertical niche in the emerging SaaS market.
All the rest is just technical detail.
http://isvsurvival.com/trackback/35/
No comments yet
Start the conversation on article “Why ISVs need a SaaS trust architecture to survive the shift to SaaS”.