How sticky is sticky?
Great VMSCo’s are often referred to as having ‘sticky’ products. Sticky in the sense that customers don’t want to (or can’t) stop using the product and hence keep paying recurring fees to the vendor. Sticky products keep customer attrition low and recurring revenue streams high, which ultimately leads to greater business value. They also enable VMSCo's to more easily increase prices. So what makes a VMSCo product sticky? How sticky can software really be? How can VMSCo’s make their products stickier?
Procurement
Let’s start with how the customer obtained the software from the vendor. While long sales cycles may be a pain for the vendor initially, they can actually be beneficial when it comes to protecting recurring revenue. For example, formal Request For Proposal (RFP) processes can take many months or even years before a vendor is selected. The time and effort put forth by the customer are, at least in part, an indication of the commitment that customer is making to their choice of software. After such a process, the incumbent VMSCo can usually be assured that the customer will not take switching software vendors lightly, as it would mean they would have to spend additional time and money to redo the entire procurement process.
Deployment
It’s also interesting to look at how long it took the vendor (and customer) to get the software up and running following procurement. This deployment time and the costs of the associated delivery services represents another form of commitment by the customer to the chosen vendor. Some software products, particularly enterprise software, require specialized training, on-site installation and configuration, consulting and project management. It is not unusual for the cost of these services to be equivalent or greater than the cost of the licenses for the software. Particularly in vertical markets, where customers are expecting a highly tailored solution, VMSCo’s are often required to expend considerable effort to get the software deployed. As long as the VMSCo can do this reasonably efficiently, ‘delivery’ services can make the product stickier as the greater deployment time and effort creates an obstacle for customers looking to switch vendors.
Customization
Product customization's are a specific area of services delivery that can result in greater ‘stickiness’. When a VMS customer requires custom development work in order to meet their needs, such an investment in the software by the vendor (and the customer) further raises the hurdle to switching software vendors. VMSCo’s encounter this situation all the time because their target customers have very specific requirements and there are relatively few competitors in the respective vertical market. Examples of common custom development services for VMS projects include: integrations with 3rd party or in-house systems, business-specific algorithms and management specific reports. Custom deployment work can be viewed as a challenging distraction for the VMSCo, but it is often well worth it, especially if the development and deployment services can be done profitably. Custom development and deployment work is an important driver of stickiness for VMSCo’s that do not offer a market-specific pre-packaged software product.
VMS deployments themselves can get quite complex, depending on the type of business the customer is in. As an example, think about a customer that operates a fleet of vehicles. This customer could be in any line of business from limousine services and airport shuttles to postal delivery or waste management. Suppose this customer purchased some sort of VMS with a fleet management component. If the VMSCo has to pull the entire fleet off the road and out off service in order to deploy their software, imagine how much of an interruption this would be to the customer’s service. Planning the deployment to minimize customer downtime may extent the elapsed deployment time by many months. Once such a VMS product is up and running, the potential pain of service interruptions becomes a considerable switching cost. Depending on the industry, customer and product, stickiness can at times be inherent in the process required to deploy a VMS product.
Use
Another important aspect of stickiness is how the customer uses the software...or if they are actually using the software at all. Businesses purchase software all the time but they do not necessarily go through the process of learning how to use it and making it a part of their day-to-day operations. The stickiest VMS software is mission critical, which means it is frequently used by customers as part of their every day operations and without the software, the customer could not conduct business. Such software will often have ‘specialist’ or ‘power’ users within the customer’s business whose entire job it is to operate the software. In some cases, the sheer number of users within a given organization is a good indication of how important the software is to day-to-day operations. For example, if the entire call center staff at an insurance company all use the same software to provide quotes, administer accounts and accept payment. It’s a pretty good bet this software is important to the operation of the insurance company and that considerable cost and effort was required to get this system up and running. If the software is truly mission critical, users will often engage with the vendor through support channels, regarding training courses, conferences, product feedback and customization's. Some really niche, mission critical software products have a cult-like following within their respective vertical.
Can they turn it off? Can you?
There is a difference between user stickiness and recurring revenue stickiness. The distinction hasn’t really mattered thus far as the factors discussed above play into both types of stickiness. However, the distinction is important in truly understanding a VMSCo’s stickiness. For instance, whether or not the vendor can unilaterally ‘turn the product off’ plays a role in maintaining recurring revenue. Products that are deployed on-premise are hard for vendors to turn off, particularly if they are behind a firewall with no call home. This is in no way unique to VMS markets and is a particular problem when vendors sell perpetual licenses with annual maintenance. A VMSCo may have a VMS product that is ‘user’ sticky by all measures discussed above, yet it does not generate sticky recurring revenue because the customer can keep using the product whether they pay for maintenance support or not. The vendor cannot turn it off. This is usually fairly rare for mission critical software in vertical markets because the customer cannot risk being without support, but it is a factor to consider for on-premise deployments with no call-home controls. Source code licenses, while rare, can have a similar impact on recurring revenue stickiness as technically savvy customers can modify and tailor the software to their own needs and are hence less likely to need support from the vendor.
VMS products hosted by the vendor (or in a public cloud) are usually less sticky because they require considerably less commitment on the part of the customer to deploy. The very fact that cloud solutions typically lower the cost of ownership by centralizing the deployment model makes them more appealing to customers but potentially less sticky. Fortunately VMS products in the Cloud typically benefit from vertical market dynamics [see previous posts] that help keep customer churn lower. However, such products will be inherently less sticky unless they are truly mission critical.
If you're enjoying this blog post, check out Galaxy, a new CRM system designed specifically for dealmakers in corporate development, M&A, private equity, venture capital, search funds and family offices.
Price
As discussed, the higher the initial commitment from the customer, the less likely they are to switch products easily. But how does the pricing model itself factor in? Some VMSCo’s aim to have multi-year recurring revenue contracts in order to lock the customer in contractually. This can work pretty well as it forces the customer to commit up front and even if they are dissatisfied, potential legal hassle may not be worth it. But then again, they could simply stop paying for maintenance support entirely if they have on-premise software and a perpetual license.
Other VMSCo’s focus on product satisfaction as a driver of recurring revenue and don’t try to lock up customers into multi-year deals. In this strategy, vendors see their willingness to let the product itself drive renewals as a competitive advantage in winning new business.
I’ve seen both strategies work, although the former generally puts the VMSCo at greater long term risk of being replaced by a superior product alternative.
Alternatives
The final stickiness factor I’ll discuss is related to the available alternatives. In previous posts I’ve discussed how there are generally fewer competitors in vertical software markets however, whatever competition that does exist factors into the overall stickiness of a given VMSCo. If a VMS product meets many of the ‘sticky’ criteria described above, then the available alternatives generally don’t matter much because even if there are several competitors, it’s hard for customers to switch. However, if there are ‘apples-to-apples’ competitors with the same value proposition, dissatisfied customers will eventually switch. At the very least they will try to leverage the competition to negotiate lower recurring fees.
Final thoughts
Stickiness is really about the different switching costs a customer might incur to change VMS products. While each market and product has its own nuances, there are several factors that play into the overall stickiness, both from a user and recurring revenue perspective.
Procurement process
Time and cost to deploy
Complexity of deployment
Level of customization
Use of software
Degree of mission criticality
User engagement and penetration
Deployment model
Pricing model
Alternatives
When evaluating a VMSCo investment, it is important to analyze these factors during diligence to ultimately determine how sticky is sticky.
If you enjoyed this or other vmscos.com content, please click on the button below to subscribe.
