Thursday, August 13, 2009

Transparency in SaaS Service Operations

“Life is filigree work. What is written clearly is not worth much, it's the transparency that counts.” - Louis-Ferdinand Celine

Companies like to boast about their transparency, but in practice, information dissemination is highly controlled. At an on-demand company, hiding the backstage operations seems like a smart thing to do. As long as you are servicing the customer, and as long at the customers do not complain, why should you wash your dirty laundry in the public?
So what about SLAs? The guiding principle seems to be ‘Don’t worry about them if your customers do not demand them’. And even when they do, there are SLAs and then there are SLAs. There are so many ways to interpret these elusive numbers (assuming you even know the real ones) that most companies will portray better results than those that reflect reality.

Varying degrees
There are different modes of Transparency communications; from the non existent to the reactive, the proactive and full disclosure.

The reactive type is the common case where there are service disruptions and customers call in to complain. In this case you will determine how much information you would like to divulge. This could be done with a customer call, an RFO (Reason for Outage) that is sent to particular customers or a message on the corporate site.

A proactive approach would have a Service Status Page depicting the current service availability of the various production systems.

A full disclosure mode will provide customers with a historical view of production systems availability and response time such at Salesforce’s Trust or SAManage’s Status Page .

Advantages of Transparency
My experience has been that the more transparent you are with your customers, the better relationship you will foster with them and the more forgiving they will be when things turn sour. And things do turn sour; it is unavoidable.
Your customers are not dumb (in general, that is – I can relate many amusing stories of individuals that should have not been awarded fourth grade graduation, but that is another story). The people on the other end generally understand that you are dealing with a complex environment with many factors that are not always under your control. They will be willing to accept that scheisse happens, but they also must know that you are ready to accept responsibility and learn from these events. There should be a closure process for each event including Incident Recording, Post Mortem, RFO communication (more on that in Incident Management).
Of course, nothing beats a good, reliable, available and responsive service. If you are not able to provide that, you will end up loosing your customers regardless of how much camouflage and finger pointing are used to cover the smell.

How transparent should you be?
I am not advocating that you have to run out and tell the guys every time you messed up or that you should bombard the customers with a technical exposition as part of the RFO document.
Striking the balance is an art that comes with practice and common sense. If an incident occurred that did not disrupt services, you must undergo the full Incident life-cycle practice to ensure that lessons are learned and the incident will not repeat. But you do not necessarily have to go and boast about it.
As for the RFO, in my days I have been asked to put my signature on many customer facing documents that had a bland, general, canned message that meant nothing to the reader. (“service was lost do to a system failure”). I realized that customers will not trust the messaging and choose to either ignore it while snorting in disgust or have a techie call in and start drilling the poor customer service rep for technical details which would be hard to provide.
I have also seen RFOs that contained multiple pages and read like a PHd dissertation in electronic engineering. I do not know who approved these RFOs and if the purpose was to wear down the suffering reader so that further RFOs will never be requested.

Company Culture
And finally, keep in mind that if the company’s culture tolerates half-truths and spins when facing the customer, you run the risk of it percolating through the company’s internal activities and reports. Don’t you expect your employees to be truthful, accountable and not shy away from reporting mistakes, even if it makes them look not too great? Your customers have to expect your company to do the same. And, if the results of truthful reporting will cost you a customer then something was probably wrong with the relationship to begin with, and the customer may have been looking for an excuse to break away.


Michael Moulsdale said...

Yep, all looks good; couple of typos to track down but nothing serious.

I would take the customer relationship bit a step further. Whether the customer is the business (and you are IT), or the customer is an external customer the advantage of transparency has the following advantage:

If they see what you are up to and how you are going about dealing with incidents, risks and problems gives them more of comfort level with what you are doing and therefore more likely to give you more business (as well a bit of slack when things go pop as you have already mentioned)

In demonstrating transparency I would advocate the use of a tool such as an IT dashboard (

good luck with the blog -> book


Chi-Chang said...

This is an important yet often under-attended subject. The article is well-written and many excellent points were made.

How transparent should it be? IMHO, we should be as transparent as relevantly needed to help our customers. The number one goal of serving customers should be to make them successful with the product/service the company provides.

Two points I want to add:

1) The level of transparency in service operations, to a large extent, reflects the corporate culture and is an end-to-end and company-wide operation issue.

2) Not all customers need/are able to handle the same level of transparency. Like many things, it needs to be managed to optimize for every customer.

Good luck with your new book.


project timesheet said...

SAS70 rules dictate that you can't expose too much - can't be too transparent. Hope you have a whole chapter on SAS70.

Dani Shomron said...

Thank you all for your comments.
Good points.

It is true that SaaS and enterprise IT are similar in many ways, but there is one difference that should be pointed out.
Both SaaS and IT will be successful if the customer is successful, but in IT the reverse works (the business is successful if IT is), and not necessarily in SaaS. If the SaaS company is not successful then the customer will suffer a bump in the road but then switch to another provider.

Thank you about the comment on transparency reflecting company culture. It was a point I was trying to bring across.

Finally, I am not a great advocate of SAS 70, and if I write a chapter on SaaS certification I will clearly mention SAS 70 and explain why it is the wrong approach.