Image: Ise Grand Shrine is a Shinto shrine located in the city of Ise in Mie prefecture, Japan and is one of Shinto’s holiest and most important sites.

Akafuku was founded in 1707 and is Japan’s most famous sweet company. Their sweets are the traditional gift for visitors to the Ise Shrine, Japan’s holiest religious site. In autumn 2007 a story broke that shook Japan. Trust in the Akafuku brand built up over 300 years was not enough to protect them.

Akafuku makes bean-jam sweets (rice cakes wrapped in red-bean jam), claimed to be freshly made every day with any sweets not sold that day thrown out. This was not true. Akafuku had been lying for more than 30 years.

It was revealed that sweets not sold that day were not thrown out. They were frozen to be thawed and resold later. The labels of the frozen sweets were forged with future expiry dates. Japan was appalled and the impact was immense. It was if Starbucks was exposed for selling instant coffee!

Akafuku’s massive mistake

While there was no risk to health in what Akafuku was doing, it totally destroyed trust. When bringing sweets back home or to the office as gifts, the expectation was that they were fresh. Frozen sweets did not match the story Akafuku was telling.

Even with a 300 year track record, the Japanese were not prepared to forgive what Akafuku had done. The local government stepped in and Akafuku was forced to suspend production indefinitely. The flagship store at the Ise Shrine was closed and products removed from shelves all over Japan.

The lesson for SaaS

As a B2B ISV selling via SaaS must meet user expectations each and every day. In the sales process trust, and your service level agreement, were big issues. Now there is a risk standards will slip. What would never have been allowed at the start of the user relationship somehow becomes acceptable.

You must ensure what you say is what you do — each and every day. If you say one thing but do another, your subscribers will not forgive you when they find out. And find out they will.

Akafuku built trust with Japan over 300 years. Even so, when the truth came out it did not protect them. They were not doing what they said. Expectations were not being met and the Japan was appalled and stopped buying.

Subscribers have more choice

A key difference between SaaS and licensing on-premise software is ability to swap. SaaS subscribers feel it is easier to change when things go wrong. If you do not live up to their expectations then they will leave. And they will tell others as well.

I do not know if the system at Akafuku was approved from the top. It was likely a local decision. An employee had a lot of sweets left over one day and did not want to waste them. A one-off decision slowly becomes accepted practice. When the truth was revealed it cost Akafuku 300 years of trust.

Building trust is hard, losing trust is easy

You face the same risk. Any of your people could make a choice that costs you user trust. And what is worse, you can never keep any problems secret. On-premise software customers were isolated. SaaS subscribers talk to each other. A small problem can become a wildfire of upset customers.

Building and maintaining user trust is the most critical part of SaaS. It takes a lot of time and money to grow trust. It can take one comment on the phone, or a hasty email, to destroy it.

You must make visible to all of your people how critical trust is. It does not matter if they are user facing or not. All staff must be aware of trust.

Appoint a Chief Trust Officer

Consider appointing a “Chief Trust Officer” to show how critical trust is for you!

Winning at SaaS needs more than having the right technology and the right marketing. If you lose the trust of your subscribers they will head for the door. A story reaching back 300 years did not help Akafuku when they lost trust. The length of the relationship with your SaaS subscribers will not help you either. Lose their trust and they are gone.

Do you have a “Chief Trust Officer”? Do you make your people aware of the trust impact of their day to day actions? How do you monitor trust levels?

PS: The local government lifted its ban on Akafuku at the end of January 2008. Regaining 300 years of lost trust will take a little longer.

Early on Friday the Amazon S3 cloud storage service crashed in a big way. Lots of websites, some very well known, could not access their data.

Amazon quickly found and fixed the problem. It was not a hardware or network problem as many assumed. Amazon said that the issue was a web service at one of their 3 data centres. The service checks all user requests and SSL links. It was slowed by a sudden peak in SSL requests. Non-SSL requests were blocked. The whole of Amazon S3 stopped.

During and after the problem customers talked about the lack of feedback from Amazon. For the future Amazon will release a service health dashboard. This is a good step and is required; but how would you have responded in the same situation?

You can learn from Amazon’s mistake. Take a look at how this fault was covered by blogs and in the press. How would a problem like this affect your SaaS platform? What will you do when it occurs (and it will, sooner or later)?

Keeping your subscribers informed

Many ISVs now rely on Amazon S3 and EC2 for their SaaS platform. Not all of these ISVs were prepared for a failure in Amazon S3.

Friday’s fault showed how vital it is to inform your subscribers when things go wrong. Amazon did not do this and their customers were upset. In a chain reaction, subscribers to the ISVs sites were also very upset.

What process do you have for when a similar problem occurs on your SaaS platform?

• Do you have monitors to report a change in service status at your back-end suppliers?
• Do you use a DNS redirect to show your subscribers a status page when the system is down?
• Do you have a way to inform logged-in subscribers of the problem?
• Do you run your status and monitoring on a totally independent platform to your main SaaS platform?
• Do you provide status information in human and machine readable forms?
• Do you make it easy for your subscribers to bring your status information into their existing management and support systems?
• Do you have a way to tell your subscribers the system is up again?

Its your problem now

With on-premise software you did not need to worry about all this. These were issues for customers and their IT groups to manage. This all changes with SaaS. You are now offering a service and not just the software. This is now your problem, not theirs.

Do not wait until your SaaS platform crashes. Amazon did not get away with not talking to its customers. Neither can you. Now is the time to plan and prepare!

Were you affected by Friday’s Amazon S3 downtime? If so, how did you tell your subscribers? How did you keep them up to date? How did they react to the downtime?

Image: Nozbe offers a SaaS GTD solution, but read the TOS and you’ll think twice before “dumping your brain” there. Not to pick on Nozbe, but SaaS SLAs have a long way to go before users will entrust them their most critical stuff.

For day-to-day task planning and management I use a light version of David Allen’s Getting Things Done (GTD) method.

Earlier this year I saw a reference on the ZDNet Office Evolution blog to a new SaaS GTD tool called Nozbe from apivision.com. I was reminded of it when lifehack.org included Nozbe in their 11 Top New Web Apps of 2007.

Over the holidays I thought I would give Nozbe a try and see if it could replace my current Microsoft Outlook solution. My initial impression of the site was positive, until I clicked on the Terms of Service link at the bottom of the Nozbe home page.

When I evaluate a new SaaS service on of the first things I do is have a look at the terms of service to see if there are any traces of a SaaS Trust Architecture. What I saw at Nozbe showed little or no thought had been given to convincing qualified prospects (in this case me) to trust their company enough to consider taking the next step and trying their service.

Extract from Nozbe’s terms of service

Here is an extract from the “Service” section of Nozbe’s Terms of Service. I had added highlighting for the text which I immediately noticed:

“Apivision.com may suspend the Service for any reason whatsoever, including but not limited to, repairs, planned maintenance or upgrades, and will not be liable to you for any such suspension.”

“Apivision.com reserves the right to refuse service to anyone for any reason at any time.”

“Apivision.com may suspend the Service for any reason whatsoever, including but not limited to, repairs, planned maintenance or upgrades, and will not be liable to you for any such suspension.”

“Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account.”

“Apivision.com reserves the right to make any changes to the Service or to discontinue any aspect or feature of the Service without notice, and will not be liable to you for any such change.”

“Apivision.com, in its sole discretion, has the right to suspend or terminate your Account and refuse any and all current or future use of the Service, for any reason at any time.”

Who do these terms protect?

It seems to me that Nozbe’s terms of service have been written to protect the interests of apivision.com as the SaaS supplier, and not the customer.

These terms of service are not customer-friendly. There is no commitment to providing the service. It even sounds like my data can disappear at any time without any recourse.

I am sure that this was not the intention, but it is almost as if the terms had been written with the sole intention of scaring potential customers away.

Trust is the very first sales qualifier

In my recent post Why ISVs Need a SaaS Trust Architecture to Survive the Shift to SaaS I explained when you offer your application software via SaaS, building a trust relationship with your customers is the most important thing you must do.

I looked at Nozbe’s terms of service for a first impression to see whether or not they are giving trust the emphasis it deserves. I do not know apivision.com and I have no previous experience with their products or services. They therefore started with a trust level of zero from me as a potential customer.

Moving to a SaaS GTD solution might not be a big risk in overall terms, but the risk is too large for me to trust my data to Nozbe.

This is a shame as Nozbe might have been a good solution to my GTD needs.

The lack of any indication of a SaaS Trust Architecture means that I will never know how good Nozbe might have been. On the other hand, apivision.com has lost a qualified and motivated prospect at the very first stage of their sales funnel.

Let your competitors make Nozbe’s mistake!

apivision.com missed an opportunity to start building a trust relationship with me as a qualified prospect for their Nozbe GTD SaaS solution

The lack of a SaaS Trust Architecture means that all the time and effort that they have invested in building software or improving their back-end infrastructure are wasted investments. A little more thought on developing terms of service focused on building a trust relationship from the very first contact could have made all the difference.

Many of your future competitors will try to take the easy option and write terms of service like Nozbe that are solely for their benefit and not their customers. That is bad for them, but good for you.

Design your terms of services to focus on gaining and keeping your customer’s trust as part of your SaaS Trust Architecture. This will mean exposing yourself to new and unfamiliar risks. That is a core part of the new SaaS business model — get used to it.

You are not going to survive and profit from the shift to SaaS unless you can live with this reality. apivision.com does not yet seem to have learned this lesson.

Image: If you don’t trust your diving mate, your safety is a (potentially fatal) illusion. SaaS safety doesn’t mean having the best data centre or the right multi-tenant architecture. It’s a lot more simple than that: it’s only about trust.

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 scaleable 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.

Why trust is critical for SaaS

The reasons are simple and pragmatic:

• Wthout trust, it does not matter how scaleable your back-end platform is.
• Without trust, it does not matter which ddevelopment tool you use for your rich-client.
• Without trust, it does not matter what high levels of customer service you claim to supply.
• Without trust, it does not matter how economical your per-seat subscription model is.

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.

But our customers already trust us!

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.

The scope of your SaaS trust architecture

Your SaaS Trust Architecture must be at the heart of everything you do, including:

• Service level agreements
• Data protection and security
• System availability
• Disaster recovery
• New functionality
• Licensing and pricing
• Data portability
• Integration

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.

Trust is everybody’s responsibility

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.

Do you trust your suppliers?

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.

Trust is a key part of your defensible position

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 existing customers have an existing level of trust in you as a long-term supplier.
• Your potential customers have a certain amount of trust in you because other companies in the same field as them have clearly chosen to trust you in the past.

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.