Saturday, July 19, 2014

SaaS Incident Management Best Practices (The STORM™ Series)

"Remember that failure is an event, not a person" (Zig Ziglar)

(this post was first published on July 14, in SaaS Addict)

Shift Happens
No matter how much you prepare, the amount of resources you pour into your operation and the experts you hire, something will break in your production system eventually. (This is not a new subject  - see the Black Swan Event in SaaS Ops and STORM™ for Dummies)

Incidents could manifest themselves as slow response time, loss of a function (e.g. email not being sent, Backup data not FTPed to client), a whole module malfunctioning or a full scale downtime for some or all of your customers.
I have witnessed too many service disasters in my professional career and I have the battle scars to show for it. On the bright side, the STORM™ methodology grew out of the smoldering ruins.

Following is a three piece article discussing how to prepare for, manage and survive your next incident (and it is out there, lurking in the dark right now, rubbing its palms together, waiting to strike).
As in any good apocalyptic novel, this article is divided into the Prologue, the Main Story and the Epilogue. The first article will cover Act I – Before the world came to an end.

Prologue - ACT I
Plan for failure. Expect things to break. With that in mind you should try to anticipate what might break first.
Keep in mind however, that as much as you plan, there is a good chance of something else coming out of a dark corner and biting you in the behind, since you don’t know what you don’t know. Still, for all the other things that you could anticipate this is a good plan.

SPOF Analysis
Single Point Of Failure Analysis is an exercise that should be practiced once a quarter. Without going into too many details the following outlines the principles:
  • Map all your IT assets (and by ALL I mean not just the important stuff like databases and web servers, but also the phone connections to corporate HQ)
  • Perform on each item an Impact Analysis – What would be the Effect of Failure of that component on the service levels
  • Assess the Risk of losing each component. What factors might lead to failure
  • Mitigate the problem by taking pro active measures; e.g. invest in a better storage solution or duplicate the component and load balance between the two.

Monitoring & Alerting
These practices are explored in detail in the STORM™ Event Management chapters. Suffice to say that:
  • Monitoring allows you to detect the problem so that you can fix it
  • Detecting a problematic component allows you to react early on (before your customer calls in, pissed off)
  • Therefore, monitor EVERYTHING – components, processes, communications, workflows, response time, etc.

Escalation Path and Hunt Group
  • Define who gets alerted under what circumstances. E.g. if there is a slowdown on response time for the database, the first person that should be alerted might be the DBA. Map out the various scenarios, who is has ownership and if the event merits escalation.
  • Define the escalation path while you are calmly sipping tea before an event occurs, so those decisions are not made under duress.
  • Define the Hunt Group, policy and call sequence. Most PBXs and telephony services provide this feature.  This link for more info.

Document Changes
As part of the STORM™ Change Management practice, all changes to production should be documented and easily accessible, so that one can query changes immediately in case an incident occurs. (Across location, function, affected customers, Etc.). Remember that some change, somewhere in your production universe will always be the cause of an incident. It may be as obvious as installing a new Web server or as obscure as new browser version on one of your customer’s laptops.

Customer-Asset Mapping
Create a relationship chart of which assets (or group of assets) can be mapped to a customer (or group of customers).  An asset may be the AsiaPac data center in Melbourne or a config file on one of the VMs in AWS.
When the time comes, this will be very handy in both locating the problem and assessing the impact of service degradation. Therefore, saving this relationship in a DB table will prove valuable.

As part of the STORM™ Event Management practice, a Network Operations Center is always a great advantage. NOCs can be as elaborate as the NASA Mission Control Center, or a loosely coupled web-based dashboard, that presents monitoring data from various sources. A 24X7 manned NOC with 20 giant flat screens usually takes time and continuous investment to reach, but even a small SaaS startup can adopt the concept and start with little steps.

War Room
When the stuff that happens hits the fan, there is a tendency to lose one’s cool. I have witnessed  executives - CEO, VP Sales, major account managers – start running around and bombarding us with questions in the best case scenario, and shouting instructions and blasphemies in the worst case. In order to be able to calmly collect information, assess the situation and act to remediate, there needs to be a place where all those involved in actually resolving the issue, can sit together, isolated from the pressure.
  • Physical War Room– In one of the companies I worked at, I secured a separate room, packed it with a couple of large screens and communications. We prepared a list of exactly who was allowed to enter during an incident. I had the key and we actually locked the door during an incident. We had reps from Support, Ops, and Engineering and did not leave until the situation was under control.
  • Virtual War Room – Whether you have not built the physical War Room or an event occurred after hours, one can create a Virtual War Room using a Web based NOC and a dedicated communication group such as IM or WhatsApp.

Status Page
Create (on the corporate site – not the production site) a page that depicts the current state of your production systems with a time stamp, a color or image code, and a line of text describing the current state. This is somewhat similar to the Salesforce Trust site.

There is a new service out there - - that provides much of the needed functionality.

As will be discussed in the next article, this will significantly reduce the number of angry customer calls, facilitate communication and help with the Closure phase (third article)

Knowledge Base
Another subject that merits a chapter of its own. However you realize the KB, with home-grown tools, a bunch of articles on your ITSM Help tool, Salesforce Knowledge or a dedicated tool, one must start early on, collecting how-to, tips, known problems, etc. in a central repository, with an easy search and category index. This KB could also contain admin level scripts to allow quick resolution of known issues.With a full implementation of the STORM™ Incident Mgmt, alerts will already have pointers into the relevant articles in the knowledge base.

Now that you have done your preparation work, you are in much better shape to reduce the occurrence of a catastrophic event and have the ability to respond and remediate faster. All that is left for you is to pray that it doesn’t happen at night, or at least not on a weekend night, or at least not on a holiday weekend night, or at least not when you are on your way out of the house, with the suitcases packed, on your way to your annual vacation.

The next post will discuss The Main Story -  best practices during an incident.

Monday, May 19, 2014

Why ITIL is not a great fit for SaaS?

"Maturity is a high price to pay for growing up". (Tom Stoppard)

Last week I visited a customer who is a global leader in their market and that had been gradually, over the past three years, transitioning their software to the Cloud. Ther have an impressive operation and reached a maturity level that required them to take the next step - they are hiring a ITIL consultant to help them formalize their operations. I congratulated them on their initiative, but I raised an eyebrow as well.

There are many IT System Management (ITSM) tools out there; some have been around for decades. Most are ITIL based, and since that is what is available, SaaS Operations managers will sometime use the ITIL-based tools that are available – This, of course, is the best case scenario, since many SaaS Ops are managed ad-hoc, with a mixture of documents,  tools, some homemade scripts and open source solutions.
STORM™ was conceived when following regular ITIL methodology just didn’t do the job. It was either too cumbersome, an overkill, or not accurate enough to cater for the SaaS Ops needs.

Initially, SasS Ops is similar to the IT department in many aspects:
Both teams are running the infrastructure, the applications and the service desk for ‘other’ users, writing scripts, configuring, monitoring, responding and in general, ‘keeping the lights on’.

But there are significant variations that make all the difference.

Quantity vs. Quality
The difference between the ratio "application/users" in the two entities is significant. In a typical enterprise there may be hundreds of applications being used simultaneously by hundreds or thousands of users. In a typical SaaS operation there is a single application, or a very small number of applications that are used by thousands, or tens, or hundreds of thousands of users. On top of that, there typically are a large number of environments and stacks that are being used in the enterprise – numerous kinds of databases, operating systems, middle-ware, network boxes, and functional servers. In the SaaS application environment there is usually a single kind of database, a single OS, a single type of application server, etc.

This distinction demands completely different types of staff, skill sets, tools etc. Whereas the Ops group of a SaaS company will know the application and environment intimately, there is no ability of the IT staff to become as familiar with the applications as they would like. They end up knowing a lot less about a lot more. The complexity of the enterprise environment is therefore a hundredfold less manageable.
And that does not even take into account the provisioning of a multitude of devices that IT is responsible for, including desktops, laptops, phones, printers, scanner, etc. taking even more attention from the application management.

The complexity of an enterprise IT environment might justify a CMDB, but that is an overkill for most SaaS operations that could be managed with a simpler Asset Management solution.

Know thy Customer
As mentioned, a SaaS company will deal with a user base that is one or two (or more) orders of magnitude larger than the IT department. Also, where as a SaaS company will have hundreds or thousands of customers, IT deals with at most ten to fifteen different entities within the organization, and perhaps a number of partners as well. 

Every SaaS company is bound by an SLA with all of its customers (some have more bite than others). The SLAs within the enterprise (if they exist at all) are much less binding than a legal document signed with an external entity, and there seems to be a lowered expectation as well as a more forgiving attitude towards the internal IT organization.  

Therefore, while it is becoming more common for SaaS companies to display a Status Page for the users to view the availability and performance of production systems, it is rather rare In IT organizations. 

Centrality of the Ops group.
In a well managed SaaS company, the Operations group is the hub of the activity. They should be communicating with all the organization’s entities (R&D, QA, Support, Professional Services, Finance, Product and Sales) as delivery partners, not as customers. In most business organizations, IT is treated as a necessary evil; as an internal service provider that is always behind schedule and delivering at low performance; it is rare when IT is viewed as a delivery partner.  Whereas the Ops group is expected to participate in weekly customer success meetings, that practice is virtually nonexistent in an enterprise IT organization.

The operations staff at a SaaS company have the ability to affect the product behavior and “serviceability” (and in some companies they actually are part of the MRD/PRD process), while the IT staff at the enterprise can bitch about the problems at best, but have no influence on what features will be included in the next version. 

For example, the application may be spewing out hundreds of Warning or Error messages that are completely cryptic. The SaaS Ops manager has a responsibility to sit with Engineering and map those messages to actionable items.  In the IT world, this is practically impossible for shrink-wrapped applications. 

Service continuity
In ITIL parlance, Service Continuity deals with the ability to provide minimal service levels, and is designed to support Business Continuity.
In the STORM™ methodology, SaaS Service Continuity plays a completely different role. It is designed to provide the continuation of the service to the customers even when the SaaS provider is no longer an existing entity. This could occur under positive circumstances, when the company is acquired by a larger company or under a dire situation, when the company goes under.

Since most SaaS companies are small, many of them with little or zero profitability, and the consolidation of Cloud providers is a daily occurrence, customers need assurances that their services and data will continue to be available – at least for a substantial period.  Therefore, issues such as Financial Viability, Technical Complexity, Operational Complexity, Escrow and Data portability play a significant role and are rarely the concern of corporate IT departments.

In Short
There are many other day to day factors that differentiate IT Ops from SaaS Ops; the above discussion pointed out some of them. ITIL provides an important, structured framework for any IT operations, and SaaS Ops managers will benefit from familiarizing themselves with the principles and the vocabulary. But ITIL is too complex, cumbersome and high level to be of a practical value to the average SaaS operation. 

STORM™ practices flattens and simplifies the ITIL structure, and provide a practical and specific guide for an efficient and effective SaaS Operation.

Wednesday, April 02, 2014

To be or not to be… in the Cloud. Examining the Motivation

“The undiscovered country from whose bourn no traveller returns” (William Shakespeare)

Yes, it is 2014 and there still are thousands of ISVs who are selling their software in the old, on-premise model.  Surely, many of them are doing quite well, with a large, happy customer base, which is paying for upgrades, new versions and the yearly 20% maintenance fees.
Nevertheless,  I doubt  there is even a single board of directors that is not considering going to the Cloud.
Everyone wants to be in the Cloud. Many ISVs have started offering their services as a Hosted solution (claiming that they provide SaaS) just to have a presence there, and have added a little cloud to their logos or landing page to enhance that impression.

The Motivation
I have been advising ISVs for over a decade on their move to the Cloud (or SaaS as we old-timers still call it).  It is surprising though, how many of the companies I consulted to couldn't articulate why they were doing it.
I always begin with a Motivation session where the C-level staff is gathered to discuss what their thoughts on the matter are, and I find out, time after time, that there is no consensus on this matter.
Since the transition from a Product company to a Service company is so profound, the paradigm change so deep and the costs are not trivial (sometimes they could bring a company to its knees), it is crucial to understand why  the ISV is willing to set on this adventure.
The discussion below outlines the various reasons why an ISV should invest in this process.

Everyone is in the Cloud
Yes, it is fashionable, and I don’t belittle this motivation.  Sometimes a company must have a presence in the Cloud for marketing purposes, just because it is expected and the company brands itself as a forward looking endeavor.  But is this a good enough reason ? I would look into the next items to try to justify the move which is by no means a simple one.

The employees are demanding it
As flimsy as it may sound, this is not dissimilar to the previous motivation. The workforce is getting younger (in age and in mentality). Employees who think that the company is not ‘with it’ might start looking elsewhere, to companies that are more on the bleeding edge of the technology and market. Although this should not be a major consideration, it still is a consideration and might tip the balance toward a decision.

The competition is offering it
As we all know, SaaS solutions are very attractive from many perspectives. If there are a number of new, pure-play SaaS companies that are starting to bite into your customer base, this is a serious consideration. But, it should not be the only consideration; one must examine and compare exactly what the competition is offering. Many times, SaaS companies will offer a small subset, or an over-simplified solution of what your product does. If the competition is up-to-par in most aspects of your solution, you may already be fighting a retreating battle. If not, it is possible that you may lose the smaller customers but could still have an advantage in the larger companies. If this is the case, you should consider the transition to SaaS, while maintaining your advantage, rather than compete with the smaller players.

Your customers are demanding it
That is a very compelling argument. No one knows better that your own customers. If customers are requesting an Cloud solution, the company should listen carefully. Still, it is important to engage with the customers and understand exactly what it is they are looking for in a SaaS solution. Perhaps it is the recurring payment option – that could be done with an on-premise solution as well. Perhaps they are looking for certain features. Maybe it would make sense to offer new options in an integrated version, rather than rewrite the whole application from start.

You want to expand into a new customer base
Often times, the SaaS option will allow a company to reach out into a large customer base that was below the radar because of price or complexity.  While you were selling to the high end customers, there might be a vast group of smaller businesses that could benefit from your solution, but were always out of reach. If this is the great motivator, one should carefully examine what should be offered. Is it the same set of features? Is it a light weight version, or a subset? Are your potential, future SaaS customers different from your existing customer base, not only in size but in their needs ?

You want to expand into new territories
One of the advantages of SaaS is “Anytime-Anywhere”. While the old model necessitated local presence for sales and professional services, the SaaS model will allow the company to sell around the globe without the need to have ‘boots on the ground’.  If your local market is saturated, SaaS is a great venue to reach out to the other side of the globe without the expensive and complex logistics it used to take to make that happen. Here again, it is important to articulate what will you be to selling the customers in the geographies; not necessarily the same as the local offering.

To be – Of course
The discussion above does not suggest that after examining the motivation, one would conclude NOT to offer a Cloud solution. Of course every ISV will have to be there sooner or later, otherwise it will become obsolete. But going through this thinking exercise will allow you to define your approach. Understanding the motivation will help identify the target market, the go-to-market approach, the timing and the offering itself.

As an example:  A large British ISV I worked with, wanted to switch to SaaS by taking its flagship product to the Cloud. After going through the process we came to the conclusion that their product was a cash cow for the foreseeable future, and there was no reason to dive into such a large undertaking at this stage. Instead, the decision was to develop a LITE solution to offer to different customer types in new geographies. This allowed the ISV to experiment with a less demanding task, while learning the ropes of the new architecture and new market approach. I am happy to say that they are launching their SaaS solution these days in two new territories.

Saturday, March 15, 2014

SaaS Customer Success – Best Practices (Part 2)

“There are two rules for success:
1. Never tell everything that you know”     (Roger H. Lincoln)

Company Culture and Customer Success
In my previous post, I discussed perspectives that dealt with the technical and formal issues of improving customer success. It suffices to remember one fact – companies are more successful when their customers are more successful. In this article I will talk about a crucial facet of SaaS: company culture - that not only affects Customer Success, but many other aspects of running a successful SaaS operation.
(I have written about Culture in a number of articles in the past – some posts are pointed out)

Multiple Touch Points
In the on-premise business model, the touch points with the customer moved slowly from one part of the organization to another: Sales and Pre-sales were engaged with the customer at the beginning; then Professional Services engaged with the customer until implementation was complete. Following that stage, the ISV did not interact much with the customer. There may have been a yearly status call; sometimes the customer inquired about bugs or perhaps sent a request for features that was pushed into a waiting list. (The product may even have been sold through a VAR, leading to an even larger disconnect).

In the SaaS model, at any given moment there could be multiple touch points with the customer: The end users may be speaking with Support, while the customer IT is talking with the Ops group; the customer business manager is engaged in a call with Sales, while the CIO is speaking with the SaaS CEO about the latest outage, and Finance on both sides are figuring out last month’s bill. Some SaaS companies assign Technical Account Managers to large customers, but that would not alleviate the problem if end users continue calling Support, or IT happens to be talking with the network manager in the Ops group. In any case, TAMs are only assigned to a few, large enterprise customers and this will not work out if the company has hundreds or thousands of active customers.  
Mapping the touch points of the customer is therefore essential, and making sure that everyone who might have contact with the customer is using the CRM (or equivalent - I know, it is not cheap).

Need for Speed

Everything switches to Fast-Forward in SaaS. The sales cycles are shortened by at least an order of magnitude. The release cycles are shorter through agile methodologies and DevOps technologies; the impact of bugs is immediate (the new version is released at night and the following morning thousands of users interact with the software) and the response from the customers is almost instantaneous. Customers expect a fast turnaround and Information about success or failure travels as fast as the latest Tweet. Numerous customers may be added in a single day through self-service, or might churn at the end of the month.

Therefore, SaaS companies must shift into high gear. Especially if they come from the old, legacy, on-premise world, where the staff is used to much longer cycles in every aspect (I have been giving seminars at these old-world companies to emphasize that fact and push for cultural change). Quickness of response, of decision making, and pro-activity result from the elements discussed below: Transparency, Communications, and Openness.

I have written in the past about Transparency and it is still a valid article. I do not wish to recycle old material but suffice to say that customers will not only appreciate the openness and honesty as a virtue; they can also benefit from the knowledge while helping your company improve. When service is down, or slow, or erroneous, covering it up will not make your customers feel more confident. If you discuss the issues with them (s**t happens, you know,) you may work out together how to deal with service degradation in the future; that will help them become more successful.

When you promise a certain feature that you know will not be delivered on time or as expected, you may gain a few weeks of industrial peace, but that will clearly not make your customers more successful. If, instead, you openly share the status of your release, your customers would be better prepared. Working together, you may formulate an alternative solution that will allow the customer to succeed while reinforcing the ties between the companies.

Communications and Openness

The fact that almost anybody in the company might be in touch with someone on the customer’s end and that everything has sped up means that inter-department communications is crucial and internal transparency is a must. There is not time for ego games, or gaining an edge by holding important information close to one’s chest.
Transparency within the company is crucial (there usually is a correlation between external and internal transparency). If you promote a culture of openness and acceptance of mistakes, problems will be reported earlier and be dealt with the maximum available information, therefore reducing their negative impact. Both the company and its customers will benefit.
(Recommendations for periodic meetings can be found in my article on Inter Department Communications)

Service Level Agreements
The Support staff usually take the first hit when bad things happen, but every employee must understand the impact of service degradation. Make sure people empathize with what it is like not to be able to complete the task that the end user is evaluated on.
SLAs are usually regarded as a necessary evil, forced upon the SaaS provider by a standard expectation in the market, and is usually reduced to the minimal accepted level. (read more about SaaS SLAs).
But, imagine a company that takes it SLAs seriously, that thinks about the Service Levels that it provides its customers and that is proud of what it can offer to the end users and is open about it.
Imagine that someone within that company actually read the SLA and thinks about how to improve the Service Levels, not only the dead horse of the Availability section. Imagine what that might do to enhancing customer success!

A Point about Priorities
Some companies emphasize that the ‘Customer is Always right’ and keeping the customer satisfied is the top priority of the establishment. With other companies, making the shareholders happy is the major driving force.

The following observation is based on my subjective experience and understanding and has no scientific or statistic corroboration:
If you manage to make your Employees Proud, Dedicated and Happy, they will make your Customers Paying, Loyal and Happy, which will make your Shareholders Fat, Supportive and Happy.

This is why company culture is so crucial. Getting people excited and unified behind a common goal of excellence and customer success will result in Excellence and Customer Success.

Friday, February 28, 2014

SaaS Customer Success – Best Practices (part 1)

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

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.

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.

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.

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.

Friday, February 07, 2014

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?).