Skip to main content

SaaS Design Principle #1: Design SaaS to Manage the Full Customer Life Cycle User Experience

By June 14, 2011Article

Migrating an application to SaaS (Software as a Service) means rethinking and redesigning the software in several fundamental ways including changing the hosting model from single to multi-tenant, the business model from perpetual license to subscriptions and the update cycle from years to months.
The customer life cycle
But in our experience, having designed over 60 SaaS applications, one of the most significant changes is in the management of the customer life cycle. Customer life cycle refers to the full progression of steps a customer goes through when exploring, purchasing, using, getting support and upgrading a product or service. With SaaS you build some or all of these steps directly into the software. This is a dramatic shift in software design but is essential to meet modern user expectations as well as achieve scalability and profitability. Let me detail this out further.
On-premise software customer life cycle (traditional)
With traditional on-premise software, the customer life cycle is handled by many departments and individuals. There is a large up-front sales effort with a protracted sales cycle, from a large team (pre-sales, account manager, marketing, advertising) that “manages” the buyer through the sales process. A purchase cannot even move forward without engaging with the sales team. Installation/setup including customization and provisioning requires a systems engineer or consultant. Training and a post-sales support staff manage the usage and ongoing maintenance phases. A person in finance handles renewals. At every customer life cycle “touch point,” the buyer must engage with a human gatekeeper that is outside of their everyday use of the “core” application (e.g., the CRM or ERP).
SaaS customer life cycle
With SaaS, the above “high-touch” model falls to pieces due to economics and user expectations. When you migrate to SaaS, you still have your core application as the center of focus, but then you systematically identify all of the points in a SaaS application where the software or staff will touch the customer (e.g., early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, support, etc.). Based on your specific business, customer and technology dimensions, you evaluate which of these touch points can and should be migrated online and be built into the SaaS application.
Put in very broad buckets, these touch points address:

  • Purchasing and deployment
  • Configuration and provisioning
  • Usage
  • Monitoring and upsell

Designing for buyer self-service
In a pure SaaS model, the underlying economics mandate that almost all of the touch points in the customer life cycle be designed, delivered and managed via the SaaS application. So in addition to delivering the core application, the software is designed to use automation and self-service to do the tasks that would otherwise require support staff to service. Buyers can do these tasks on their own, right within the software. This is essential to achieve economies of scale, rapid iterations, and broad market appeal. When implemented correctly, the cost of acquiring and supporting 100 customers should be just marginally higher than for one customer.
Of course, pure SaaS is not appropriate to all business models. The underlying business value of a piece of software may require unique customer processes, or complex integration tasks that can’t be automated. The steps in the SaaS life cycle framework are, however, still appropriate for developing a roadmap on how to design your SaaS. Examine the touch points in the life cycle of your own organization and your product to determine the appropriate combination of self-service and high-touch services interacting with one another.
In some cases you may need to offer enhanced customization, additional sales support, or on-site professional services; and the premium you charge for this will cover the cost hit you take by not being able to scale via automation or self-service. But even in these cases, don’t fall back on traditional on-premise software approaches. You should still thoroughly examine all points in the customer life cycle and determine the fundamental cost advantages of addressing each component in software vs. with sales and support staff. This will help you to align your business model with the underlying economics of how the core application and supporting services are exposed to users.
A real-world example
We worked with one of the leading SaaS CRM providers on a problem they had with losing more than 20 percent of the people who initially signed up for the service. Because SaaS makes it possible to track online activities, we were able to determine where users were dropping out. The company had assumed the problem was in their core application, but it was actually in the customer life cycle during the provisioning and customization process (that at this point was still being managed by support staff). Once we knew where to work, we were able to move these touch points into the application to create a smooth and simple user experience to allow self-provisioning and customization. This very effectively reduced the dropout rate.
A visual model
The diagram below explains the SaaS customer life cycle visually.

On the left in the diagram is a traditional on premise solution. This inside area is the part of the software that the customers touch, i.e., the core application. Around this on the outside are all of the touch points of the application that are not built into the software. Someone has to come in to sell it. Someone has to come into provision it. Someone has to come in to customize it. Someone has to come on site to do training. etc. So there are many touch points that are not part of the design of the software.
On the right in the diagram is a SaaS application. You still have the core application in the middle that users touch. But there are many points around the core application but still inside the circle (the life cycle of that product) that users can touch. This includes things like trial software, purchasing, configuration, provisioning, etc. Buyers have an expectation they can do these things on their own without the need to interact with a sales or support person. Consequently the implementation and user experience need to be simple, easy and effective.
As an organization, you need to understand the life cycle touch points that surround your product. If a touch point is inside the circle, it means buyers are going to touch it as part of the software; if outside the circle, it means that aspect will not be built into the software.
Paul Giurata is a managing partner and lead solution architect for Catalyst Resources. His work focuses on the design of software for mission-critical solutions in cloud computing, SaaS, financial services and mobile.