With SaaS, Software Not Only Service Needed

Software as a Service

Software-as-a-service (SaaS) simplifies much of the complexity involved in implementing and using enterprise software. However, recent insights gained from several SaaS selection deals over the past two years have raised concerns that some SaaS providers may be neglecting key elements of success for buyers.

Please note that in this post, we are not addressing the distinction between multi-tenant and single-tenant hosted systems. Although there are important differences, the concern about services transcends this distinction.

As the name implies, software-as-a-service (SaaS) turns software into a service. No longer does the buyer need to install software in its on-premises data centers. Nor does the buyer need to provide its own day-to-day internal support for maintaining and operating the application infrastructure. The entire system is delivered to users “as a service” by means of a network connection.

But is the software the only service that SaaS buyers require? What about implementation services such as project team training, help with prototyping, data migration, end-user training, acceptance testing, and go-live support? Whether the software is delivered as a service or installed on-premises, these systems do not implement themselves.Moreover, once the company goes live on the new system, what about ongoing support? Is there a help desk to deal with problems such as system unavailability or response time? What if a bug is uncovered or a patch needs to be applied? Who does the buyer turn to when there are questions about how the system operates? Are there good, up-to-date system documentation and training materials?

SaaS-Only Providers May Attempt Arms-Length Implementation Services

There is a distinct difference in the selling approach of what we may refer to as the “SaaS-only” providers versus traditional enterprise software vendors. The SaaS-only players, being 100% committed to the online model, attempt to move as much of the selling process online as possible. For low-end applications such as survey software or email marketing, they offer free trials with online conversion to the paid service. For mid-level or higher-end applications such as accounting systems or ERP, they offer self-directed online demonstrations and perhaps some sort of limited trial use of the system. If at all possible, to minimize cost of sales, they attempt to close the deal on the web or over the phone with as little on-site selling as possible. All of these sales methods are good, and traditional vendors would be wise to move in this direction.

The problem, however, is when vendors attempt to move their implementation services to this low-touch model. They try to use online computer-based training, web-based instructor-led training, and phone support with as little on-site or personalized service as possible. This may work for lower-end applications, but when you move into those mid-level or higher-end applications, the customer can often be short-changed. It puts more responsibility on the buyer to organize its own resources for deployment.This may work for some small companies, but not all. Some companies simply need more hand-holding.

Where SaaS-only providers do a good job is in post-implementation services. Because these vendors are entirely web-based, they generally have good capabilities for ongoing support such as self-help systems, user-support communities, and web-based training. They also have experience in migrating customers to new versions, which is far less painful than the upgrade cycles of traditional on-premises software vendors.

Traditional Vendors and Channel Partners May Not Be Good at Post-Go-Live Support

The traditional vendors–and their channel partners–face the opposite problem. Their sales model has always been a high-touch model. They conduct face-to-face sales meetings and demonstrations. They bring services people into the process to help close the deal. They derive substantial revenue from implementation services, so they invest in those resources.

What happens when these vendors offer a “cloud” or “hosted” version of their systems? This is where the traditional vendors and their channel partners risk falling down. They can sell their systems as they always have, but now, what about post-implementation ongoing support? The software developer often does not want to get involved in the day-to-day management of their customers’ systems, so they push that responsibility to their VARs. The VARs, in turn, often cannot afford to invest in their own data centers, so they turn to data center hosting partners to operate the system.

This arrangement can work, but the result can be a complex relationship:

  • The software vendor develops and issues new releases of the software.
  • The hosting provider operates the customer’s system.
  • The VAR helps the customer implement the software and provides day-to-day ongoing support for the customer such as help desk services and resolving any issues with the hosting provider. They also provide services when customers need periodic version upgrades.

The risk in this arrangement is largely with the VAR. Their legacy is being an implementation partner. Their experience is in projects. They come in, do a job, then leave. They do not have a culture of providing day-to-day support to their customers. Furthermore, these partners almost always have a mix of on-premises customers and hosted customers, with hosted customers forming a smaller or much-smaller percentage of business. They might have some help desk personnel to take calls, but they cannot dedicate technical resources just to the hosting customers. Rather they must use their implementation consultants when a customer has a routine problem. If the consultant who knows that customer’s business is deep in the middle of another customer’s go-live, the first customer’s problem may go unresolved.

Most of the SaaS-only providers do not have this problem. They develop the system, they host the system, and they provide day-to-day ongoing support for the system, including version upgrades. If there is a partner involved, it is usually only for initial implementation or help rolling out new functionality.

What Should SaaS Buyers Do?

Seeing that there can be problems with both the SaaS-only providers and the traditional providers offering hosted versions, how can buyers minimize their risks? The answer is to perform more due diligence beyond what software buyers typically perform for on-premises enterprise systems.

When considering SaaS-only providers:

  • In the sales presentation: observe whether the SaaS provider pushing an approach of mostly virtual services, claiming the system is so easy to implement that you don’t require much help. If you are prepared to implement without much direct support, fine. Otherwise, you may be starved for resources when you most need them.
  • In your reference checking, ask about the implementation experience. Who provided implementation services, the SaaS provider directly, or an implementation consulting firm? What type of support did they provide? Were their on-site services adequate? What do you wish you had done differently?

When considering traditional vendors with hosted offerings:

  • In the sales presentation: observe whether the vendor is mostly talking about the software and implementation services, or are they giving sufficient time to talk about on-going support after the go-live? This may indicate they are still thinking of themselves primarily as sales and implementation services providers, not as ongoing support providers.
  • In your reference checking: ask about the day-to-day experience with ongoing support. Does the provider schedule a lot of downtime for maintenance? Is there much unscheduled downtime? Do the customers ever have problems getting the right person on the phone to resolve issues?

All these questions can be asked of every vendor, but you should place more importance on these questions depending on whether the vendor is a SaaS-only provider or a traditional vendor with both on-premises and hosted offerings.

Finally, if it is not in the contract, it does not exist. Be sure all of your needs are reflected in the actual contract and associated statements of work. An experienced consultant can help with the negotiation of these documents.