SaaS Blog Posts

One of the unique benefits of SaaS is that the application user interface (the components the user interacts with) can be designed to monitor the users behavior and give the vendor information on how the software is actually being used. This not only provides insight into how the SaaS should be improved to meet changing customer requirements, but also how to proactively reduce customer churn.

On-boarding, the process of getting customer signed up and using a SaaS is a good example. Effective on-boarding is critical in terms of determining the tenure and profitability of a SaaS customer relationship. The challenge for SaaS vendors is to immediately gain and leverage an early understanding of new customers behavior and then drive relevant communications to facilitate both immediate on-boarding and continued engaged use for the first 60 days (and beyond).

Designing your SaaS to take advantage of monitoring

So what are some of the steps in application design for effective monitoring?

• Identify the high value scenarios for your SaaS application. We use a systematic and formal process to determine these, but on a casual level try to imagine what what customers/users want to accomplish (not what you think they need).
• Define 2-3 key benefits that differentiate your software from the competition from a customer point of view (e.g. customized interface / ready to use out of the box / cheaper / faster).
• Define the critical behaviors a user must take to successfully accomplish the high value scenarios (e.g. they must import their contact list).
• During the application design process, as you streamline workflows and user-validate the UI, track where even a small percentage of users face issues. While a goal in the design phase is to refine the user interface to minimize these friction points, track any issues that do arise, no matter how infrequently. These can be used to develop processes for intervention during on-boarding.
• Build your UI as a modular system with the capability to track user patterns and clicks, and relate them to desired behavior sequences.
• When you deploy your SaaS, use these monitoring components to identify what features of the software do not seem to be used, where users get distracted from completing high value scenarios, where they make mistakes, where they stop at signup, etc, Integrated monitoring is essentially a continuation of user-validation testing and data collection we do during the basic application design. But here is it used both as information on how to modify the software in future revs, but also where to determine where you can provide assistance before those new revisions are out.

On-premise vs SaaS on-boarding

With on-premise applications, customer on-boarding is considered as outside of the functionality of the software product itself. But with SaaS, on-boarding is an essential process and monitoring the user behavior needs to be part of the SaaS application design. Whether you are trying to get users to complete signup for a trial, or whether you are trying to get users to successfully start using your software, tracking user behavior enables the software (or humans) to intercede at any points where the user might be dropping out.

For example, if users drop out in sign-up, only partially completing the process, the SaaS application can send out an automated, semi-customized e-mail which reads "Thanks for starting your online trial. To finish the process, do XYZ."

Or if users are not going through the critical behaviors that are necessary to complete high values scenerios (and thus experience the benefits of your service), then you can have a tech support person call (costly but effective, particularly for important individuals representing large clients), or you could send them links to videos or invite them to webinars explaining how to complete these behaviors, or point them to discussion board posts that answer other users questions related to completing the tasks.

For example, based on where a customer appears to be dropping out, an automated email goes out saying: "To really take get maximum advantage from our software, you will want to do XX. We have a options to help you through the process including one on one telephone support."

Customer Engagement

This same kind of monitoring can be used to determine intelligent automated (or human-based) up-selling or to tap into social networking for referrals. Once you have determined the high value scenarios and behaviors that users need to complete in order to find "addictive" or engaging value in your software, then monitoring and intelligent SaaS application design, can help users along.

Monitoring at the user experience level is an effective way both to to correct drop out points during the first 60 days, improve effectiveness and efficiency for your customers, and quickly determine how to modify your application on a regular cycle to meet user needs, increase sales and up sell, and reduce churn.

The SaaS life cycle framework was developed on the premise that there are specific business, customer and technology dimensions that must be examined as part of the design of a successful SaaS application. You systematically identify all of the points in a SaaS application where the software or staff will need to interact with the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, support etc). Then evaluate which of these “touch-points” should be handled as part of the SaaS application design.
Put in very broad buckets these touch-points address:
- Purchasing & Deployment
- Provisioning
- Usage
- Monitoring & Updates

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.  Automation and self-service do the tasks that would otherwise require support staff to service so that the cost of acquiring and supporting 100 customers is just marginally higher than for 1 customer.  This is essential to achieve economies of scale, rapid iterations, and broad market appeal.

But pure on-demand 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 and determine how you design your application to address them - based on your specific business and technological situation.

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 (the “pure” SaaS model).  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 human services. 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 Software-as-a-Service (SaaS) solution is not simply a new way to package and deliver applications. It is a fundamental shift in the relationship between the software service provider and the customer." This is the kind of thing you read all of the time in the IT press or hear from pundits at conferences. By now most senior executives in companies are saying "OK, I understand I have to have a new mindset. But what $@!% does that really mean in terms of how I build my application and my business?"

In other words, how can you translate this 'new service mindset' into an actionable roadmap for building a profitable SaaS application?

On-premise application design focuses on the core functionality

Designing applications for traditional perpetual license, on-premise software may be complex, but it is relatively straightforward because the entire development focus is on the core application - the CRM, ERP, BI itself. The marketing, purchasing, provisioning, support, billing etc., all of the other "touch-points" in the customer life cycle are managed by the vendor's sales and support staff. Hence the functional design of the application typically only needs to address the core product functionality (the features and the UI for exposing these features).

What changes with SaaS

What changes with SaaS is that the software, not a large support staff, services most or all touch-points in the customer life cycle. So in addition to the core application design, you also need to design the software to address the full progression of steps a customer goes through when exploring, purchasing, deploying, provisioning, using, referring, and upgrading a product or solution. I first proposed this SaaS customer life cycle strategy back in May of 2008. Since then we refined and vetted the approach with a score of enterprise SaaS application design projects.

All touch points of the Customer Life Cycle are included as part of the core SaaS application

If the SaaS application does not provide a satisfactory experience at each touch point along the way (e.g. acquisition, usage, support, monitoring, referral etc) you get customer abandonment. If the way you handle each touch point does not scale without adding staff, you lose economies of scale (i.e. profitability).

This type of life cycle analysis can deliver an actionable roadmap for designing a successful SaaS application. Examine each phase in the customer life cycle and design a strategy, software functionality and release plan for moving these points into software and optimizing their delivery. For practical reasons not all components will be addressed in the first release, but it is critical to have each included in a release roadmap. Many of the components can be based on other on-demand services that can be fed into your own SaaS application (e.g billing). For these, a key design focus is to smoothly integrate the service into your application so that it offers a positive user experience, rather than an opportunity for friction.

Choosing the right application design firm for a mission critical application, is in itself a mission critical decision. Much of that assessment is determining if the requirements for your project match the skills & experience of the provider. That can narrow down the field pretty quickly.

But another component is learning how a firm thinks relative to your own project needs. That is why we are launching the a new online webinar/workshop series called SaaS Roadmap @ Lunch.

SaaS Roadmap @ Lunch is intended to help software-as-a-service entrepreneurs, executives, and investors assess their SaaS business and operational readiness and build a roapdmap to improve the bottom line through SaaS application design.

But it is not your typical lecture/sales webinar. Instead we want to give you the chance to bring your own SaaS design issues to the table, for a quick on-the-spot review. Show us your current application or plans for a new application and ask for our candid feedback. This gives you the opportunity to "test-drive" how we think, and how we interact with your team. (It also gives us a chance to learn about you, your company and the kinds of issues you are facing.)

The agenda for each SaaS Roadmap @ Lunch event is as follows:

• We begin by examining a group of elements from the SaaS Life Cycle framework for bottom-lining your application.
• We then review examples of well-designed SaaS applications that effectively illustrates thess life cycle components.
• Then we ask attendees to present their current software or development projects and ask for our input from the perspective of the SaaS life cycle framework.

Our first workshop is schedule for Friday May 29, 2009 at 10:30am. Pacific.

You can register to attend on our Webinar page.

We look forward to seeing you there.

While the buzzwords viral marketing and viral adoption are certainly overused, there is no doubt that they can be powerful tools for increasing brand awareness and increasing sales. Viral adoption can be particularly relevant to SaaS, where profitability (or internal corporate success) depends on quickly achieving and retaining a critical mass of users.

The term viral refers to individuals using existing social networks to share their experience/excitement about a product/service, creating the potential for exponential growth (analogous to the self-replicating spread of pathological viruses). In the best designed case of viral adoption, users become your sales force and PR team.

There are multiple way to design a SaaS application for viral adoption:

• Design the product/service to offer such a great user experience and give users sufficient feelings of perceived control that they become rabidly loyal and evangelistic (think Mac and iPhone users).
• Design the product/service with sharing and the value of sharing as an intrinsic functional component. From a mechanical perspective this means finding the right conceptual model so you can build a UI and workflow that make it easy and clear how to share. From a desirability perspective, this means strategically designing the product/service so that it's value increases as more user join. (think Skype or LinkedIn where inviting others to join is essential to using the product more fully).
• Design the product/service to target a niche (preferably under-served by current offerings) and provide an intuitive interface/features to help these users connect and interact. (think vertically-targeted SaaS).
• Build in ways for your community to actively influence product development to create a sense of ownership. Critical to this is to build in monitoring to identify when a customer succeeds or fails at each phase in the SaaS lifecycle. Use this information to proactively ask for feedback on how to improve the software or increase performance.

SaaS applications designed with viral functionality as an integral component of the customer lifecyle will create referrals, increase usage, and reduce customer churn. While you cannot force viral adoption, you can intentionally design your SaaS application to facilitate and organize communities and encourage "virulence".

It used to be in the healthcare arena, that investment dollars followed the companies searching for the next new breakthrough drug or treatment. Recently however, the opportunities and incentives have started to shift to less glamorous products aimed at health care efficiency, and cost-control using SaaS, RIAs and optimized user experience design.

A $19 billion nudge

This move is spurred in part, by provider funding freezes, regulatory scrutiny and the growing push for universal health coverage. The other driving force, of course, is the $19 billion in the Obama stimulus package to encourage doctors to convert to digital medical records.

Efficiency and cost-cutting through health care software solutions can be achieved in many ways, across many sectors of the healthcare industry - in everything from research, to Pharma clinical trial management to patient scheduling, records and billing. The design of these applications will be a high growth area in both the short and long term. SaaS solutions will grow particularly fast as tighter regulatory compliance forces more standardization and interoperability in healthcare protocols, reporting and practice.

The success of these new applications will depend on how well they are designed to maximize efficiency, usability and performance. A few of the key best practices for successful application design include: define the high value scenarios, determine the best conceptual model, user-validate, design for perceived control using RIAs, and create application UI that is modular and reusable.

So where will optimized UI and SaaS application design play especially prominent roles? Here are a few targets that are already moving steadily in that direction:

Medical Research

Efficiencies in clinical research can be achieved from analyzing workflows, user interactions and then designing software interfaces to streamline the process. For example, for Ventana Medical we developed a dynamic Rich Internet Application (RIA) that interfaced to a piece of complex equipment for immunohistochemical assays for diagnosis of cancer and infectious disease. The new user interface greatly increased efficiency and reduced delays, allowing labs to do more screening in less time.

Pharma

Pharma is already moving to a SaaS model, particularly for clinical trials with electronic data capture (EDC) and analysis, and sales & marketing using CRM. The SaaS delivery model allows companies to easily scale resources as needed depending on the number of drugs in clinical trials or based on a dynamically changing sales force. Ease of use, performance and mobile access will be the key drivers.

Patient scheduling, records and billing has Service written all over it

Less than 9% of U.S. physicians in small practices and less than 30% in medium size offices are using digital patient records, according to a June 2008 study in The New England Journal of Medicine. This represents an enormous opportunity for companies to develop solutions to provide provides patient registration, scheduling, patient electronic health records with HIPAA compliance, clinical work flow, billing and collections. The key to success is to package the technology, functionality, and support at a cost/usability/perfomance level that makes it accessible to the average physician. This translates directly to user-validated UI and a SaaS business model. A well-designed modular SaaS application will be able to handle a sole practitioner seeing 20 patients a day or a multi-clinic operation seeing hundreds of patients a day.

Moving beyond the entrenched culture

Healthcare is one of the largest software and IT footprint has the most to benefit from the use of SaaS and user experience design. The biggest challenge will be cultural. But change is finding its way through the cracks and the new federal stimulus money will be a compelling motivator.

Although clients frequently asked, I generally don't recommend particular cloud computing platforms on which they should build their SaaS. The big 4: Amazon AWS, Google App Engine, Force.com, and Microsoft Azure, as well as many smaller players, all offer scalability, performance, security, and reliability. Some offer more comprehensive and targeted development environments then others. Which one you choose should be based on your own research through the lens or your development resources, estimates of growth and your unique SaaS life-cycle application strategy.

Since choice of platform is as much of a bet-the-farm decision, as designing the right user experience, you should be diligent in your research. To help, we've started a Cloud Computing section in our SaaS Application Design Resource Center, where we try to point you to useful articles. In particular check out this top four article or a more comprehensive list of top providers.

As for high-level recommendations, as you look through these articles and evaluate vendors, consider these issues carefully.

• Portability: Are you locked into the provider once you move your data? Is there an API to integrate with other applications offering value-add opportunities to "re-mix" applications? Is there a proprietary API that ties you to that platform and is the advantage that 'IDE-ness' worth the lock-in?
• Ramp-up time: Do your developers already know the basics of API or development language. If for example, you are a . NET shop already, then there are obvious advantages to working in a .NETplatform. If your developers live and breathe Python, then Google App Engine is worth a look.
• Flexibility: Will the service meet your needs after you roll out v1.0? Does it offer extensibility and integration with other services, enterprise mashups and data sharing? Plan for at least one full release in the future and re-evaluate the service from that angle.
• Multi-tenancy and metadata-based configurability: Do not overlook this. If you are moving to SaaS, you want an infrastructure that supports multi-tenancy - one code base that can be customized via meta-data. Multi-tenant may seem like a philosophical argument, but it is based on simple dollars and cents economics.
• Terms of Service: Can they expel you from their platform if they decide you are competitor or an "inappropriate" business?
• Service Level Agreements: What are their up-time and support guarantees?
• Track record: What is their track record with security? How have they responded to mistakes they have made in the past (and they have all made mistakes).
• User reports: What do other developers say? Other users will give you the lowdown on their experiences without the marketing hype. Use community.

The above list of questions is certainly not comprehensive, but it does give you a begining framework as you evaluate each of the offerings. Catalyst Resources' developers have designed SaaS applications that run on top of each of the major cloud platforms, so we know there is no right or wrong choice overall. It is always specific to your project and growth strategy.

Always keep in mind that the behind the scenes technological infrastructure is only one small part of your SaaS application. Your customers don't care about the underlying hardware or code. They are buying enhancement and improvement of their business, which means you need to focus on streamlining business processes, designing for high value scenarios, maximizing perceived control, and innovating to give people a reason to try your service in a crowded marketplace.