One piece of criticism constantly aimed at SaaS is that it’s not as “customizable” as on-premise software. Before examining this claim, we need first to define “customization” from the perspective of licensed software to provide the proper context.
Traditionally, “customization” meant a change to the application source code or the creation of a module for a specific client, often with the result that the vendor ended up maintaining a branch of source code to support each client. With custom modules, the vendor would maintain only the modules’ source code but had to ensure that subsequent releases of the core product did not break compatibility with the one-off modules. If they did, the modules had to be rewritten or the customer could choose to not upgrade from the version for which their one-offs were built.
This strategy works for licensed software vendors because all they need to do is maintain customer-specific source code and/or modules. This complicates the software development life-cycle, but it also creates massive barriers to exit for the client since their customizations are owned by the vendor. And since the vendor usually charges annual maintenance fees, plus time and materials for customizations and module compatibility upgrades, this approach can be profitable.
The antique application service provider (ASP) business was flawed because vendors couldn’t achieve the benefits of economies of scale. While it was technically trivial (though expensive) to add servers to host single-instance, single-tenant applications for clients, problems occurred with per-client customization. Instead of maintaining a source code branch for each client like their legacy vendor counterparts, ASP vendors also had to maintain active production, testing, staging/QA environments for each client. The ability to scale under any type of customization load quickly fell; eventually, so did the vendors. The customization-friendly model of legacy software did not translate to ASP vendors and it doesn’t translate to SaaS providers.
SaaS vendors must understand that customization is the Cardinal Sin of SaaS: once committed, retribution stretches into Eternity. SaaS vendors should view customization requests as threats to their very existence because customization literally breaks the SaaS model. This includes any request for running a “private version” behind a customer’s firewall or in a “hosted” environment. By adopting this mind set, SaaS vendors will have an easier time saying “No!” to the customer or asking for significant premiums to make that happen. In a sense, the issue of how to deal with customization as a SaaS vendor is a red herring because true, client-by-client customization should be avoided at all costs.
Put succinctly, there is no way to handle one-off customizations within a SaaS business architecture. Period. But customers still request customization without considering if they truly need them.
Some customers have a checklist they use every time they buy a new accounting package. The original checklist included a requirement for a custom widget that no one has used in 10 years, but it’s still a “must have.” When the company goes to a SaaS vendor with that same checklist and asks for that widget, what is the SaaS vendor going to say?
As a SaaS vendor, it is critical to stop thinking like a software company and think like a service firm. Think about how a CPA would handle a client who asked to use an outdated IRS form. The CPA would say, “No.” Period. SaaS vendors should position themselves as the experts in their market and tell their customers what they know is good for them, whether they want to hear something different or not.
Many SaaS vendors will argue that one-off customizations will help them generate cash in the short term, which will, in turn, help them through the lean times while they grow recurring revenue. Although the custom design-and-build business can be lucrative and tempting, consider the ways it can hurt a SaaS business. First, it distracts application developers from making rapid and high-quality improvements to the product core, the multi-tenant application. Further, one-off customizations interfere with your sales group learning how to accelerate sales process and shorten buying cycles while encouraging them to hunt for other big-dollar customizations. Finally, over time, the customization business can take the entire company’s focus off of the nimble, scalable architecture that is SaaS.
Flexibility is the answer to the customization dilemma for a SaaS vendor. From a marketing and positioning standpoint, being flexible sounds similar to being customizable. At an implementation level, the SaaS vendor must consider what amount of flexibility will be built into the system. Ultimately, all of this should be dictated by the target market of the vendor. A SaaS vendor should seek to meet the needs of the majority of the target market and build flexibility into the service for the rest of the market to meet their individual needs.
At Softletter, we like to see SaaS vendors meet 80% of the target market’s requirements and allow the other 20% to be met through inherent flexibility; a 65:35 split is a good starting point. This flexibility, including the user interface, reports, workflows, templates, etc., should be meta-data driven, where the underlying application does not change for each client. Being meta-data driven, each client, or even individual users, can make changes to the elements on their own without going outside of the sandbox created by the built-in flexibility of the system.
When considering flexibility and SaaS business architecture, remember that the more horizontal the product, the more flexibility will be required to meet the majority of the needs of the target market. As the focus becomes more vertical or on a tighter niche, more can be built into the core product to meet the market’s needs. With a tighter vertical focus, it is also easier for the SaaS vendor to be positioned as the industry expert who leads the market on requirements.
For horizontal SaaS offerings, it is more difficult for the vendor to position itself as a vertical expert. For example, if a CRM firm wants to move into the hospitality market, the vendor may need to find ecosystem partners to fill in this specific gap in its feature set.
Salesforce.com is an example of a vendor that has created an ecosystem with its Force.com platform and toolsets, which enables firms to build out into verticals. Salesforce.com essentially met 50% of the needs of everyone who requires CRM out of the gate. With their internal customization capabilities, they can meet 70% of customer needs. But the other 30% they can never meet because that extra 30% is vertical-specific expertise or functionality that they don’t have and don’t want to add to the product core. Instead, they’ve turned the opportunity over to the Salesforce.com community. If you know the hospitality business and understand its CRM needs, build on top of the Salesforce.com platform and everyone wins.
To conclude, instead of reacting to the FUD being tossed out by anti-SaaS pundits and legacy software vendors, it is time for SaaS vendors to step up, embrace their chosen business architecture, and begin the process of positioning themselves as trusted business experts. It’s time to understand how flexibility and customization are not the same. Flexibility is the SaaS vendor’s best friend; customization can kill your business. And remember that as a SaaS vendor, you are in a unique position to arrive at a deep understanding of your market and your customer’s needs and establish yourself as an expert in your market segment in ways not available to on-premise software firms.
