There was plenty of coverage the past week about the new SproutCore HTML/JavaScript framework that was used by Apple to develop their MobileMe site.  “A SproutCore application is a JavaScript application that runs entirely in the web browser. It can often run on its own, without even needing support for a web server except when it makes sense for the application. This frees the server developer to focus on the things the server can do very well such as saving, restoring and aggregating data and performing expensive operations. Meanwhile the ‘thick’ client running in the web browser can handle the task of presenting the user with a friendly interface that is fast and intuitive,” from the SproutCore Web site.

What is interesting is that the description of SproutCore applies to any RIA stack - HTML/AJAX, Flex, Silverlight, Curl or any new flavor that comes along.  RIA is now the defacto standard for web application deployment.  This applies to applications ranging from simple e-commerce sites, to desktop widgets, to full blown enterprise applications delivered as SaaS.  The particular application develop platform an organization should choose should depend on two things:

1. The core technology for your application (typically .Net or Java). The core technology is driven by a much broader set of issues than just the presentation layer. If you already know what the core technology will be, put a stake in the ground to constrain your evaluation of RIA platforms. We have seen very few teams be successful in delivering an application within the required scope and schedule requirements when the team had to change to an entirely new technology base.
2. The primary device and platform where you plan to deliver your application (e.g. public web, in-house, iPhone, desktop widget, combined off-line and on-line interaction)

Lately we’ve done a lot of work with Adobe Flex because it met specific client needs (e.g. bidirectional network sockets), it is very good at media handling, it is fast to prototype and develop, and it is scalable. For SaaS, we can build smart, adaptive, and reusable interface and data handling components. These can be used in the core application as well as with all the supporting services delivered in software (e.g. billing, provisioning, configuration and support).

Most of our financial services, insurance and banking client work has used GWT and BackBase.

As we develop more applications specifically targeting mobile devices in the enterprise, we will be adding SproutCore to our list of AJAX/HTML solutions.

Regardless of the platform or technology, this is an exciting time to be developing enterprise applications.  The business value of user experience is no longer a hard sell.  Companies get it!  The success or failure of an enterprise web application or SaaS deployment is dependent on using RIAs to deliver compelling, addictive and productivity-enhancing user experiences.

The realities of the SaaS model are that there is less upfront revenue, it is transaction/usage-based, and it is renewal dependent. To be successful a SaaS must optimize time to market, control fixed & variable costs, and keep headcount low, even as services grow.  This is on top of the need to create compelling user experiences using RIAs to keep customers engaged.

With traditional on-premise applications, most phases in the customer life cycle (sales, marketing, customization, provisioning, training, billing, etc) are managed by people and services that are not part of the “core” software application. But with a successful and scalable SaaS, all aspects of the customer life cycle are exposed directly to the customer and all need to be handled as part of the strategy and design of the SaaS.  You are not just migrating the core application online, you are migrating the customer life cycle management and interaction points online and into the software. If each interaction point does not scale without adding staff, you forgo economies of scale and profitability becomes elusive. 

Not all phases of the customer life cycle are as easy to move to software as others. Depending on the nature of the business, internal momentum and constraints of IT or SOA architecture, organizations may not move a particular phase into software and instead handle it the more traditional, albeit less scalable way - using people. Our poll asks you to indicate which phase in the life cycle are you least likely to move into software.

In Part I of this post I talked about how RIAs and web services offer an opportunity for financial institutions to integrate online banking, electronic billing and payment, and value-added services such as graphical tools and cash flow forecasting, into an end-to-end solution. Reusable interface components in the RIAs can be built once and shared across channels to increase upsell of add-on services, reduce training / support costs, simplify regulatory compliance, and save as much as 85% in application front-end development cycles.

The opportunities for banks, insurance providers, investment firms, and other financial institutions become even more interesting when you add SaaS into the mix.

Software-as-a-Service (SaaS)

“Banking 2.0” is of course, broader than just using RIA technology to create compelling and addictive user experiences. Banks are in a unique position to offer their corporate, small and medium business (SMB) customer a range of integrated business services.  Customers may not naturally think of their bank as an innovative and cost saving software provider, but Internet banking already has good market penetration and banks have the potential to be a SaaS provider of choice for other business services. Banks are already trusted for security and reliability and can use SaaS to deepen their relationships with SMB and enterprise departmental groups. Boston AMI-Partners find that the services desired most by SMB include banking/finance, instant messaging and payroll processing applications, and human resources management.

SaaS and managed services aren’t a new concept in banking. Aite Group, estimates that 60 percent of community banks deploy a majority of their internal IT applications through SaaS including expense reporting, travel booking, payroll, PR services, and recruiting. For external facing applications such as consumer lending and loan processing, many savings and loans rely on the infrastructure and services from larger banks.

The movement now is for financial institutions to use RIAs and SaaS to offer their corporate and SMB clients a diverse portfolio of services. Very large financial services organizations may choose to develop the projects completely in-house. Most financial institutions will build their SaaS applications by linking together services from larger banks (e.g. Fidelity) with other SaaS infrastructure providers (e.g. Saleforce or OpSource) . In either case, the keys to success will include developing a consistent and user validated UI across all services.  On the development side this shortens development time for new services. On the customer side, if a customer knows how to use one application, then it will be easy for them to try and then subscribe to additional services without training or frustration.

Address the Full Customer Life Cycle

The real determinant of success however, will be how well financial institutions develop their RIAs and SaaS to deliver the full customer life cycle that accompanies the new services.  It is not enough to deliver a well-designed forecasting tool, for example. That is just one component of what the customer experiences.  Equally important, the SaaS must provide the demo, sign up process, provisioning of services within the SMB,  support, monitoring or internal use, and billing - the entire customer life cycle - all with the same level of user validation testing, customer engagement, and RIA performance and design consistency as the core application.  I’ve described this life cycle approach in a previous post,  and it is no less critical to apply to SaaS services provided by financial services firms.  It is more important to start with just one new service, but address ease-of use, UI consistency and all aspects of the life cycle, then it is to come up with a complex new portfolio of financial products but not address the full life cycle or UI consistency.

Monitoring in Saas to Cross Sell and Upsell Services

SaaS offers a unique opportunity to monitor when and how the software is being used, or when and where the customer stops using the software. This information can then be applied to correct drop out points in the life cycle, improve effectiveness and efficiency for your customers, and quickly determine how to modify your application on a regular cycle to meet user needs.

Monitoring also enables financial institutions to plan and execute targeted marketing campaigns aimed at improving online and mobile banking, bill payment adoption and usage and select value-add financial management services.

Back in April I was interviewed by the American Bankers Association (ABA) Banking Journal for a feature they were writing on how banks and financial services firms were beginning to adopt RIAs and modernize their web presence into a full-service channel. I explained how our clients have used RIA features to drive business and help enhance self-service capabilities.  In the last month, I’ve seen several other news stories on similar topics.

RIAs

ReadWriteWeb noted the significance of RIAs to banking in their post about a survey of 1000 Facebook users (admittedly a young and tech savvy audience, but definitely the future of banking).  Almost half of respondents said they would use secure gadgets for personal banking if their bank offered it. A little over one quarter said they would consider switching to another bank that offered Web 2.0 gadgets for online banking.  With Gears or Adobe Air this could be extended to the offline world.

CNNMoney referenced Mint.com, an AJAX-based web application built for consumers to manage home finance - a service gap that banks have left open. Mint is particularly notable in how it delivers an RIA/Web 2.0 style experience that gets adults immersed in managing their finances the way teenagers immerse themselves in playing a video game. Mint is also highly viral - customers become advocates and evangelists for the services. This level of RIA user experience will be a requirement for any financial institution that develops their online presence.

Using RIAs and web services, financial institutions can integrate online banking, electronic billing and payment, and value-added services such as graphical tools,  and cash flow forecasting into an end-to-end solution. Moreover, the same web services that push electronic banking and bill payment functionality to the online channel,  can also push services to mobile devices, ATMs, teller stations and call centers. Reusable interface components can be built once and shared across these different channels. Componentized, re-usable UI will increase the probability of customers trying new services, reduce training / support, simplify regulartory compliance, and save significantly (as much as 85%) on application front-end development cycles.

Part II of this post will look at how banks and financial services firms can add SaaS into the mix with RIAs, to offer corporate customers, departments within organizations, and SMBs a diverse portfolio of services, that will effectively engage existing customers and lure new customers from other services.

Twice last week I went out to dinner.  At one place the food was exceptional and at the other it was merely good.  Can you guess to which restaurant I plan to go back? 

Before I answer, you might be wondering why I want to share my personal dining agenda in a blog about Software-as-a-Service. The answer is that my impressions about the restaurants offer a simple way to explain what makes for a successful SaaS.

The restaurant with the exceptional food was a high-end California cuisine hotspot. The food was complex and expertly prepared.  But when you go to a restaurant, there is a lot more involved than just the “product” of the food.  There is really this little, micro customer life cycle that you experience. There is the advance reservation process, the parking, the alacrity and courteousness of seating, the speed at getting menus, the helpfulness and attitude of the waiters, the lighting levels (i.e. can my aging eyes read the menu without having to ask the waiter for help), the prices, the length of time waiting for the bill after I am ready to go, and of course, the general ambience and the consistency of that throughout the dining experience.  So the restaurant’s “product” is much more than just the food.

In the case of the hotspot, the food was awesome, but some of the other pieces of the experience were suboptimal (high prices, waiters that were more interested in the party of six, then my party of two, slow to deliver the bill, and a bathroom that was jarring because it seemed like it was from a completely different restaurant).  On the other hand, the little Italian place had good food, was speedy without feeling rushed, had a casual trattoria ambience throughout, and was reasonably priced.  Where do I plan to go again soon?  The little Italian place of course.

Spaghetti alle Cozze - Mussels and spaghetti lightly spiced with garlic, olive oil and chili

I’m a customer like any other and my reaction is not unusual.  The little Italian restaurant knew that their company’s “product” was the food, the pre-, during- and post - service, and the ambience of everything from the foyer to the bathroom -  in other words, they developed their product to address the full customer life cycle around dining.  They sold a complete user experience that keeps customers coming back for more.  The high-end restaurant, on the other hand, thought that providing outstanding food was the totality of their product.

The difference between the two restaurants is not tactical, but strategic. Relying on the superiority of the core product is a short-term strategy.  Sooner or later, another company will match the core product or improve upon it.  Either the customer will abandon the original company, or the original company will need to pay a price in an attempt to save the relationship. I am talking about restaurants here, but the issues are the same for SaaS.

With SaaS, your goal is to get as many customers as possible to try your software, and then return month after month.  Many companies think they can focus on developing a great core application and then let traditional sales, support and engineering staff handle everything else.  But reality is that you need to develop your SaaS to deliver the complete customer life cycle experience from evaluation, to use, to billing - with each phase of that life cycle taking just as much developmental attention and user-validation testing, as any other.

So as you plan your SaaS strategy, think about the little Italian trattoria that successfully captures your regular business by managing the complete “product” life cycle.

I was invited to participate in a roundtable at the Red Herring North America conference a few weeks ago. The topic was "Enterprise software - The Online Revolution." The focus was on how SaaS challenges the existing status quo in enterprise software.

I wrote down some brief summary points I wanted to share. The ideas mirror some of the points in the life cycle framework I have discussed previously for SaaS.

In the previous blog post I introduced the concept of using a customer life cycle framework as a strategy for designing a profitable software-as-a-service enterprise application. The gist of the idea is that with traditional on-premise applications, most phases in the customer life cycle are managed by people and services outside of the “core” application. The real innovation and they key to profitability for SaaS, is to build the SaaS application to handle all of these phases as scalable, standardized services.  The SaaS application handles everything from services for evaluation and purchasing, to provisioning and support, to monitoring and loyalty building.

We have identified several primary phases or “touch points” in the customer life cycle that a SaaS strategy and application design needs to address.  Whether customers follow the phases in sequence or whether they jump around unpredictably, the SaaS needs to provide service for every activity of every phase in the life cycle.

• Evaluation
• Purchasing
• Installation
• Deployment
• Customization
• Provisioning
• Training
• Support
• Monitoring and Billing
• Renewal and Referral

Each of these points represents a potential trigger for customer friction, abandonment or attrition (often referred to as “customer churn”). A subscription-based business with even moderate customer churn, is expensive to grow. The cost becomes prohibitive if customer churn is high. Moreover, given the low monthly subscription fees of SaaS, the method for managing these points needs to be scalable in software so that as you sign up more users, you don’t need to add more staff. A SaaS business can be profitable if and only if, it can achieve strong economies of scale.

Minimizing friction and maximizing efficiency/scalability does not come automatically; it has to be explicitly planned for and architected into the SaaS application design. Over the next few posts, I want to explore each of the phases in the customer life cycle and describe the key points for moving these (in whole or part) from being handled by many people, to being handled by the core SaaS application.

Common across all phases of the life cycle framework for SaaS is the need and ability for the enterprise or ISV (the organization delivering the SaaS solution to customers) to monitor customer behavior. Monitoring in SaaS is not a new idea.  Saleforce.com has been preaching the unique ability of SaaS to be metrics driven.

While traditional on-premise applications are generally a black hole as far as information about user adoption and feature usage, with SaaS, the application can be designed to monitor when and how the software is being used, or perhaps more importantly, when and where the customer stops using the software.  Monitoring becomes orders of magnitude more interesting when you extend it beyond the “primary” application (e.g. the CRM or ERP), to encompass all phases of the customer life cycle. Not only can you monitor how the customer uses the “primary” application, but you can monitor how a customer succeeds (i.e. good user experience) or fails (i.e. potential for churn) in all of the other phases in the life cycle.

For example, during the evaluation phase, while a customer is using a “try-before-you-buy” version, you can track where users click, what features of the software seem not to be used, where they get distracted, where they make mistakes, and where they stop using the trial. Essentially it is on-going user validation testing for the evaluation phase of the life cycle. You can track similar information during the other touch points of the life cycle such as purchasing, installation, support, billing, etc.

This information can then be applied to correct drop out points in the life cycle, 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.