A recent survey from AppDynamics and Dimensional Research found that:
1) 88% of respondents indicated putting a monetary value on the cost of poor user experience was important, but only 38% quantified that themselves despite having the analytical tools to manage user experience
2) 74% of respondents blamed a lack of data integration for the disconnects between teams and gaps in monitoring end-to-end app performance
3) Nearly 70% of respondents didn’t benchmark their performance data against competitors
We know from numerous reports on the subject that outright downtime typically costs organizations hundreds of thousands of dollars per hour, or well over $5,000 per minute. We don’t yet have clear cost estimates for poor performance however. Admittedly, this is hard to quantify, as on/off is simple to measure, whereas performance problems would need to be measured on a spectrum (along with the corresponding estimated costs).
The New Uptime Status: Poor Performance Rather Than Downtime
Most customers (and providers) have come to expect “five nines” of uptime, that is 99.999% uptime. This usually does not include scheduled maintenance, but sometimes will. There are some software providers claiming 100% uptime but when giants like Google go down, “five nines” seems significantly more credible a claim.
Rather than continue to compete on uptime as the absence of downtime, providers are now being forced to compete on uptime as the absence of slowness (Aberdeen Group recently re-iterated the sentiment “slow is the new downtime.”)
Customer Experience and Uptime Status
It is not merely uptime, not merely optimal speed, but consistent speed (the ‘uptime’ of speed) that end-users now care about. And just as you owed it to your end-users to inform them of instances of downtime (no software company wants their customers knowing their app is down before they do), so do you owe it to your end-users to inform them when there’s a disruption in the peak performance of your application.
While it may be uncomfortable to admit that there’s a problem (especially if it’s not the first one in recent memory), it’s better that you be transparent about it, for two reasons.
First, you establish trust with your end-users. They know that they don’t need to watch out for you trying to hide things from them and take advantage of their ignorance- you’ll come to them before they need to come to you when a problem arises.
Second, you establish appropriate expectations for your app’s performance. Yes, it is unfortunate that you had to send out two alerts this week that the software is having issues, but better that and your end-users know what to expect than to not say anything and have your end-users wonder why your software is so buggy and inconsistent.
This hits on both aspects of credibility in customer experience – you want your customers to trust your product, trust your words, and trust that their business relationship with you will help them succeed, because you’re both on the same team.
Comments are closed.