SaaS Customer Success – Best Practices (part 1)

 “The only place where success comes before work is in a dictionary” (Vidal Sassoon)

Nostalgia
In 2003 I was managing the operations of Mercury Managed Services (today, HP SaaS). A large Mercury customer was about to give up on the product as he could not manage the complex in-house requirements, and was suffering from too much downtime. The capable account manager convinced the customer to switch to the SaaS model for a higher (!) price than what they were originally paying.
After a complex migration project the customer switched over and in the first week of the service we noticed a problem with the migrated data causing errors in the process. I called the application manager and apologized that we needed to take down the service for two hours until we fixed the problem (We abhorred the idea of more than a few minutes of downtime). The guy was ecstatic, happy as a puppy with two tails. I cautiously inquired why he was so pleased when I informed him of the service being unavailable. He told me that in the old model, no one would notice there was a problem, and when IT was notified of the issue it would take them two days to respond and a week to fix, and here we knew of the problem in real-time and service will be restored within two hours!
Obviously, customer satisfaction is a matter of expectations; within a few months this particular one got used to high availability and started complaining of less than outstanding response times.

So then, customer success is a combination of real value, of perceived value and TLC – Tender Loving Care.

Do it right the first time
As I have written in a previous post, the cost of acquiring new customers is between five to seven times more expensive compared to retaining existing customers, yet most SaaS CEOs/VP Sales are focused on new customers, optimistically hoping that ‘once a customer always a customer’.  
From a recent poll conducted by Totango it is evident that the fastest growing SaaS companies “…have a significantly better record on churn and upsell, underscoring the critical role of managing revenue from existing customers…”. In other words, being successful in the SaaS model means that you have to make your customers successful.
Bellow, I provide a list of best practices that a SaaS company should follow to improve Customer Success; of which Customer Satisfaction is a crucial but not sufficient factor.

Real Value – Perceived Value
Let’s start with something as trivial as bringing value to the customer. Obviously your service/product has to provide an advantage to the business that was not there previously, but many times the users may not be even aware of the real value. If the end user is coerced by her boss to use a certain business process without her seeing the value in it, it is not going to fly. Or, if the service was procured by a business manager that wanted a simple function that was not available or affordable prior, it could be that the users are not even aware of the full range of functionality (‘value’) of the offering.
Therefore it is crucial that the SaaS company be aware of the reasons why people are using (not using) the service, what their expectations are and how they perceive the value. This can only be done through engaging the end-user, not just the business entity that is paying for the service.
Which is a perfect segue into the next item…

Customer engagement
Remember the ‘good’ old days where R&D defined the product, the needs and the functionality? We’ve come a long way since, with Product Marketing defining the offering and releases; still, it is not clear how much real feedback is being collected and integrated into the roadmap.
How do you know what makes your customers successful? Ask them. Direct calls, forums, surveys, any means available to you. Involve the customer in the process. Ask for feedback on the product, workflows, and features. The end users typically would love to voice their opinion, to know that what they think is important.
The best venue for this kind of engagement is building a community around your service. Whether using a LinkedIn or FaceBook group or building your own community page in the corporate site. Create forums, discussion groups, a Q&A/FAQ section, an expert panel and blogs. This serves both as an invaluable source of knowledge into your customer’s deepest desires but also enhances loyalty. Consider gamification to promote participation in the community.

Branding
The community engagement is highly important for building your Brand Name. You want people to remember your name, and in a positive way. Twitter, FaceBook and other social media will kill you as easily as promote you. You must be aware of what is being discussed, chatted or Tweeted about you on any network and try to engage angry users and deal with their issues, real or imaginary.

Tell them they are successful
If you, as the service provider, know what brings the customer value, make sure they know it as well and can gauge it. Provide ‘success’ reports and ‘success’ dashboards as part of your product offering. Whatever metrics that you can define as gauging success, let them know how your service improves it, every time they use your software.

Know what is going on
“If you can’t measure you can’t improve”. There are two areas in which you must make sure you know what is going on. The first is Churn Management. You should be able to collect every bit of information on why customers left you, after how long, how big were they (revenue and company size), who was responsible for the engagement, etc. Only by analyzing, trending and reviewing this data will you be able to predict future behavior, identify telltale signs and reduce your churn.
The other area is how your product is being used by your customers. You could analyze log files and perhaps fields in your web pages, or use ready-made solutions such as Totango. Totango’s analytics and reports allow you to identify behavior indicating loss of interest, or patterns leading to disengagement. In addition, they can show you which components of the service are being used by whom, and when (e.g. EOD, Weekends), and which paths are abandoned in the midst of the flow. This can all be fed back to Product Management to improve the service and the experience, and therefore the customer’s success.

Integration
While your solution may be the best thing since sliced bread, your users do not live and work in a vacuum. There have been business processes in your client’s organization and other SaaS and onsite software in place long before you came into the picture. You must make sure that your SaaS application blends seamlessly into your user’s working day. This means allowing them to import or export data and tasks to the other applications they are already using the run their business and smoothly switching between applications (through SSO). SaaS entrepreneurs tend to focus so much on building a great application that they sometimes forget that true success occurs when you users start to see you not as an application but as a platform. Integrations are one of the ways to become a platform.

Having a good base of integrations also makes your customers decision to buy & use your product a much easier one. There is a wide variety of integration consulting companies and integration and SSO SaaS solutions out there. There is also a new breed of companies like Bondable which enable SaaS businesses to build integrations with other SaaS businesses, without having to constantly maintain these integrations.

Keep in mind that the more you are integrated with other services, the more ‘stickiness’ it adds to your solution and the more difficult it becomes to disengage.

Culture
In the next post I will talk about company culture and its direct impact on customer success. It is important enough to merit a standalone post.

STORM™ For Dummies (part two)

This is the second part of my previous post.
 
Communication Management

Back in the days of shrink-wrapped software, the ISV usually had a single touch point with the customer, i.e. IT. All issues on the customer’s end were addressed by their IT department, and what they could not resolve would find its way to Support (sometimes, months later). 

But with SaaS this is no longer the case. The customer CIO may have a direct line to the SaaS CEO. IT may be in touch with professional services, and customer business managers could be speaking with the Program Management group. The Ops group will inevitably be in touch with supervisors or IT managers on the customer side, and Sales will have developed personal relationships with managers on the customer’s side, as they nurture the relationship to expand the sales in-house. And, of course, the end users might be in daily contact with Customer Support.

If all these functions within the SaaS company do not talk to each other, if they do not share the info about the customers, there is potential for embarrassing situations that lower customer confidence and loyalty.  E.g. imagine a Sales rep calling the customer to up-sell a service, and that customer informs the rep that the service is down right now and that he might consider switching to the competition.

The Ops group is the hub of all the service activity. It deals with R&D, QA, Professional Services, Customer Support, Sales, the Customers and the Service Providers. It should initiate and manage daily, weekly, bi-weekly, monthly and quarterly meetings with the various functions and provide communication channels with the end users and the customer’s managers. 

Communication with customers takes many shapes and forms. It can be via email, phone calls, quarterly meetings, an RFO, notifications on the application message board or via the Status Page web site.

You won’t find ‘Communication Management’ in any ITIL/ITSM vocabulary, but the importance of it cannot be overestimated.

Release Management – um, DevOps?

So, we want to upgrade to the newest features or bug fixes. In today’s very complex environments, with multiple configurations, possibly geographically distributed, some on real servers, some on virtual ones, the management of a release update could be a grueling task. This is where automation becomes crucial. This is a growing discipline with many cool products and tools, making strong use of virtualization. 

Although it has become the norm in the industry that DevOps is all about configuration automation scripts, I would argue that DevOps is nine parts communication, one part automation, 

I claim that between Change and Asset Management, with agile development and Continuous Delivery, Release Management is not much of a discipline of itself, but part of the orchestration and conversation between Product, Engineering, QA and Operations.

Operations Intelligence - OI

There are other aspects of STORM™ that are not covered in this short article (e.g. Churn Management,  Cost Management, Service Continuity, Team Building, Product Serviceability), but a crucial derivative of a good STORM solution is Operations Intelligence.

Collecting and compiling all the reports of the STORM practices in a repository allows the management of the SaaS vendor to gain insight into the Operation of the company, assess progress and plan for next steps to improve the overall Service Operations of the provider.

The executive team must be able to answer questions such as:

•  How are we really doing vis-a-vis our SLAs?
• How long since our last downtime?
• What do we invest our next dollar in?
• What are the main causes of our customer churn?
• How many changes have succeeded, failed, rolled-back?
• Which components are most troublesome?
• What customers might be affected by changes to this particular asset?
• How are our TOP 10 customers fairing?
• Are we improving with our incident management?
• How do the last twelve trailing months look like?

The ability to gain insight into the various aspects of the Service Operations allows to plan more sensibly, focus efforts and resources where needed and improve the clockwork, therefore improving customer satisfaction and loyalty

The Dummies

The title “STORM™ for Dummies”, is not just a marketing play on the ‘X for Dummies’ series – there is a philosophy behind it as well. Software developers are bright, creative, out-of-the-box thinkers that may disregard the rules in search of a better solution. Smart, creative people do not necessarily make a good operations team.

Service Operations is a routine, day-to-day, unimaginative process. You want to have the best people at your disposal and to have them respond in creative ways to unexpected events. But, you want to reduce the unexpected events to a minimum and make sure you cover all bases. And when an unexpected event does occur, you want to make sure that lessons have been learned, so that next time it will become part of the routine.

The Dummies will benefit from the fact that all they have to do is follow a rigorous routine, so they can go home, have a beer and play with their kids instead of staying around late and figuring out creative ways to deal with the current crisis (now tell me, who is the dummy?).

STORM™ For Dummies

This is the first of a two-post article. As I promised in my previous post, Taking the Cloud by STORM™, I will elaborate here on the various practices.

Change Management
Curiosity killed the cat? Change is what killed the cat – I’m talking about Schrodinger’s cat, and if you don’t know what I’m referring to, just keep in mind that a tiny change in a subatomic particle is what caused the cat’s permanent downtime.
In a broad sense, Change is what causes all service degradation, whether full downtime or bad response times. In other words, “if it ain’t broke, don’t fix it”. But changes are always needed in your SaaS environment, whether adding another web server to the load balancer, changing a configuration file or upgrading the software overnight. Add to that the fascinating fact that between 60%-70% of service disruption is caused by the human factor.
So, Change must be done very carefully. There are so many things that can go wrong, that one needs a disciplined routine that takes as many factors into consideration as possible, and done in a rigorous manner, following precise instructions. It includes the Change Request, the Change Calendar and Window, the CAB, the Operations Maintenance Plan, the SOPs and the Change recording. This is what Change Management is all about.
 In my many years in the field of SaaS Service Operations I have witnessed all the possible horror scenarios at SaaS companies where Change Management was at best very meager, and usually nonexistent.

Asset Management
Changes are done to Assets. An Asset could be as large as a datacenter (new router that affects all boxes), it could be a database cluster (upgrade of the Oracle RAC) or as small as a JPEG file embedded in an HTML document. In an ideal world, a SaaS company would deploy a CMDB (Configuration Management Database) with a team of administrators that do nothing but maintain it. But in the real world, as SaaS companies grow from two to four to ten boxes and beyond, the assets are maintained, in a best case scenario, on an excel  worksheet on the sys-admin’s laptop.
When a change is performed on an asset there is a need to understand the possible impact on other assets, or on customers, and it needs to be documented. An Asset Management solution records each asset with relevant information (name, IP address, location, function, make etc.), records the relationship to other assets and maps that asset to a customer (or group of customers). When change is performed to an asset, the Change Management system will point to the relevant asset and record the history of modifications to that asset.

Event Management
With the understanding that changes to assets cause bad vibes, we need to look out for changes and understand their effects. That is done mainly by monitoring and responding to reported changes. Look at as many attributes of your assets and detect when things have changed. High CPU, low disk space, an OS service that has stopped functioning, long response times, etc. But detecting the change is not enough; how do you respond to the changes, when do you determine that a change is cause for trouble? How much automation should you employ? (short answer: a lot). What do you do when a threshold is reached? How do you control Alert Overloading? How do you build Escalation into the alert mechanism?  This is what Event Management deals with.

Incident Management
OK, so you are now practicing a robust Change Management regime, with all your Assets accounted for and monitored with a good understanding of impact of changes to your service. You are in much better state than before, but will service disruptions still happen? Of course they will! They will bite you when and where you least expect them to. What to do! What to do?
One option is running around hysterically screaming “the sky is falling” and shooting in all directions, while making sure you cover your behind in anticipation of the blame game that will surely take place after the crisis is over.
Another option is to implement Incident Management. IM covers all aspects from Detection, through Recording, Classification, Notification, Escalation, Diagnosis, Resolution, to Closure. All in a cool headed manner, following a well trained routine that will allow the company to analyze the incident and apply lessons learned so that you will not face this particular crisis again.

SLA Management
And then, some (or all) of you customers will require that you adhere to your SLA; but who knows if it was breached? Sometimes it is very clear- the system was down for an hour - everybody was affected and the SLAs were breached. But many times, it could be degradation of the service, or partial downtime. Who knows which customer was affected by what and for how long? This is where SLA Management comes in, and why it is so important to have Incident Management in place, so that one can compare the actual damage with the particular SLA. The other option is going through a bunch of printed documents (if you can even find them), trying to figure out for each customer what their agreement covered, and if it was breached, should they be compensated and how much.



In the next post I will discuss Communication Management, Release Management (DevOps), Operations Intelligence and The Dummies.

Taking the Cloud by STORM™

STORM™ - SaaS Tactical Operations Resource Management

Like an experienced and greasy auto mechanic, there is not a single mistake that I have not done (or witnessed) throughout my years as managing Operations from Fortune 500 companies to startups.  I have learned from my experience and painstakingly put together a set of practices that dramatically improve the quality of life for the whole team and the satisfaction level of the customers. IT JUST WORKS! There is no reason for a SaaS company to improve only after making mistakes that have previously been made by others.

Extraordinary people, great products, domain knowledge, specialization and wonderful intentions are the ingredients that bring and make success; yet sloppy SaaS service operations management will break that success.
SaaS companies always end up paying a heavy price for doing something they do not excel in – Service Operations.

STORM™ - SaaS Tactical Operations Resource Management, is a comprehensive methodology for managing the Service Operations of a SaaS Company. It includes a set of practices that have been defined over years of building Operations at SaaS companies and consulting to SaaS companies on excellence in Service Operations.

SaaS – While using ITIL terminology, STORM is not for general IT. Nor is it for any general service provider. The Methodology was devised specifically for the unique needs and characteristics of SaaS companies.

Tactical – Other methodologies offer high-level frameworks. STORM defines how to handle every aspect of the Service Operations, providing workflows, reports and templates and defining tools, so that a SaaS company could very quickly adopt these practices and put them to use.

Operations – the hub around which all the service revolves, in a SaaS company. Connecting Engineering, QA, PS, Sales, Finance and Customer Service.

Resource – Dealing with all the assets of the service – Px4 (People, Programs, Practices and Property)

Management – comprehensive methodology giving management visibility and decision making tools

STORM Principles
At the highest level, STORM  deals with three notions:
1.    Enabling a smooth, efficient and effective day-to-day management of the Service Operation:
 While dramatically reducing the human error factor, the smooth operation ensures that although the service is up 24X7, the staff can enjoy a good night's sleep and weekends with their families.
2.    Allowing management to view, control  and understand the components the Service Operation:
 Keeps the decision makers on their toes and provides them with the visibility of the status of various parts that make up the service.
3.    Provide a better customer experience:
Thus keeping your customers happy, growing the revenue and reducing churn

STORM Practices
The methodology contains a number of crucial practices that cover every aspect of the service operations of a SaaS company. These are (mostly using ITIL parlance):

• Asset Management
• Change Management
• Incident Management
• Event Management
• Release Management (as part of DevOps)
• SLA Management
• Churn Management
• Costs Management
• Communication Management

SaaS Operations Intelligence
A central component of STORM is SaaS Operations Intelligence, or SOI.
Through a smart collection of data from the various practices (which require tools to collect that data), reports are produced to derive crucial strategic insights of the Service Operation and enhance decision making as to what may be lacking in the service and where to invest the next dollar.

Samples of these reports are:

• Change Analysis
• Incident Analysis
• SLA Analysis
• Churn Analysis
• Customer / Asset Mapping
• Impact Analysis
• Costs Analysis

Why  STORM?
ITIL or eTOM (Enhanced Telecom Operations Map) just don’t cut it for SaaS. There are too many unique characteristics of a SaaS operation that are not being addressed by existing methodologies. (I will explore this theme in a future article).
Throughout the years I have written extensively on SaaS Service Operations.

• Most SaaS companies that I have worked at and consulted to, have similar traits and are suffering from the same problems (see Your Typical SaaS Operations).
• Most SaaS companies have a problem with Operational discipline and are suffering from Operational Fatigue (see Discipline (or lack thereof) and Operational Fatigue).
• Most SaaS companies are not doing a good job managing their SLAs (see SLA Management for SaaS).
• Most SaaS executives cannot answer basic questions about their service since they do not collect the metrics (see Questions that SaaS executives must be able to answer - KPIs that matter).
• In many companies Change Management is akin to wishful thinking and usually results in disastrous events. (see Change Management and the Sanctity of Production).
• I have seen (and worked at) SaaS companies that do not exchange critical information in real time thus causing inefficiency and embarrassment (see Inter Department Communications).
• Fast growth is a blessing but SaaS companies break at the seams on scalability issues (see 2 x E-cube = S-cube - Simple math for SaaS Scalability Success and SaaS, Scalability and the Three Little Pigs).

A methodology that is addressed specifically at SaaS companies, dealing with real issues that plague most SaaS companies is needed.
The STORM methodology has been successfully fully or partially implemented at SaaS companies and has delivered immediate results.

STORM Automation
STORM methodology contains practices that can be implemented using simple tools (I have employed MS-Word, Excel, Google Calendar, some scripting, HTML and Bugzilla).
However, STORM’s full value is realized when it is supported by automated workflows, data entry forms and data bases. The SOI component is very hard to realize without an SQL database, tools capturing the data and report generators.
Still, a great value can be derived just from following the practices in a disciplined manner, using productivity tool templates and simple repositories.

In the next article I will expand on the various practices and in future ones I will differentiate it from ITIL (and somewhat, from eTOM), and layout the basic principles.