Customer satisfaction can be a science. That’s the opinion of University of Michigan’s Ross School of Business, which developed an econometric model to study it. (Visit www.theacsi.org if you want more details.) The model is fairly simple. It considers customer satisfaction with a product or service to have the following aspects:
· customer expectations
· perceived quality
· perceived value
· customer complaints
· customer loyalty
So what do these dimensions mean in respect to business software? To get a rounded view we need to consider it from the independent software vendor’s (ISV) perspective. The ISV is a specialist retailer selling a familiar business product. When it comes to customer expectations, in general we expect the ISV to provide a smooth-running application with few bugs (that are swiftly fixed) and regular enhancements that keep pace with the general software market. We expect good response times and a fairly intuitive user interface.
With respect to perceived quality, the most important aspect of business software is that it’s a good fit for the business. And the only way to genuinely assess that is to use the software “in anger.” So you normally trial the software in some way, and if an application doesn’t fit, you move on. Other differentiating factors such as look and feel, performance, availability and support, are a sideshow by comparison – although they have to be “good enough.”
Value can only be considered comparatively between similar products and, while it’s usually possible calculate a “per-seat-per-year” cost in some way, other “perceived factors” such as business fit, service, performance, and configurability can only be estimated in financial terms, unless or until they prove inadequate.
Customer complaints is an interesting area as it has a curious relationship to the final factor of customer satisfaction, customer loyalty. If a customer needs to complain frequently, then customer loyalty becomes strained and customer churn become likely. However, it is also the case that customer loyalty is often strongly influenced by how well a customer’s complaints are dealt with.
There’s psychology to this. Your normal use of a product or service is habitual and barely remembered. You may be loyal but not intensely so. But when something goes wrong it makes a memorable impact. If subsequently your complaint is dealt with effectively and efficiently, that makes an even stronger impact, and generates customer loyalty.
The Customer Perspective
The dimensions of customer satisfaction are regularly surveyed to create the American Customer Satisfaction Index (ACSI) for a company or for specific industry sectors. At www.theacsi.org you can browse through the various companies that are regularly evaluated. However, you’ll only find ratings for very large companies there and such ratings will be no help when buying business software.
Let’s put ourselves in the software users’ shoes and consider what might engender customer satisfaction – assuming an application fits the business need, all ISVs strongly focus on that. They nurture their customers, listen to their suggestions and implement them. If customers change ISVs, it will normally be because of other factors.
It’s curious that, if application functionality is set to one side, many of the characteristics of a business application that customers care about depend on the database.
In the pre-Internet era, companies sometimes switched from one application to a competitive one (i.e. from one ISV to another) because they were switching hardware platforms. This was one reason why the Oracle database was popular among ISVs, it ran on every platform that mattered.
More recently I’ve heard of companies switching between ISVs because of a wish or need to move to the cloud. The customer expectation in such circumstances is that the ISV will make it easy and the application will run well. However, there are complexities for the ISV in cloud migration.
The first complication is the cloud service itself. Cloud vendors do not offer the same level of technology access as on premises, so there’s no way to guarantee equivalent performance and availability, even when the hardware configuration is almost identical. Whatever the problems, the customer will bring them directly to the ISV.
For the customer, poor performance is user frustration and lost productivity; unavailability is “I can’t do my job.” From the ISV’s side, such problems may be caused by the cloud provider or their own software (the application or the database) but they’ll have to fix it either way.
Other issues for the ISV are likely to be database dependent. The ISV will surely want to run a multi-tenant implementation in the cloud and the customer will want that too, for the sake of security. Some databases are particularly good at multi-tenant operation and some are not.
The ability to run applications in a hybrid fashion will also depend to a great extent on the database. Few customers may want that, or better put, are only likely to want that if it can be done transparently. But some customers may want to be able to migrate between the cloud and on-premises. The ISV will be hard put to make his applications do that unless the database can easily do it.
All of these database issues, which might never previously have mattered much to the ISV, loom large when it comes to cloud operation. The ISV needs to make cloud migration and cloud operation as effective as possible. Database performance needs to be good. High availability is a necessity. An active-active database capability would be ideal for this and for data distribution. Data distribution and replication will need to be versatile for companies that are themselves distributed or who wish to distribute the application between more than one cloud location.
The ISV needs to deploy database technology that supports the flexibility that the customer aspires to even though the customer is unlikely to care or even ask what brand of database is used. The customer who moves to the cloud is making a step-change in how they consume software, as surely as if they were moving from Unix to Windows, and the ISV needs to make it as transparent as possible – customer retention depends on it.
In the end, for the ISV, customer satisfaction means customer retention and it depends on the database in no small way.