I’ve recently blogged about what any good IVR monitoring service should provide in terms of reports. Now, let me take a step back, and address some of the reasons why you might want to consider monitoring your IVR application in the first place.
Customer satisfaction should be one of your primary objectives, as always. As part of any good customer satisfaction strategy, you certainly want to have the overall user experience as smooth as possible. While a smooth experience relies on an efficient dialog interaction design, following industry best-practices, continuous tuning, along with a high level of testing, all these efforts become irrelevant the minute your customers call your application and get a busy ring tone, dead-air, latencies, or plain transaction failure.
Our Mirador service continuously monitors your application, calling in and performing transactions with your IVR system, exactly as a real customer would. As soon as one of the selected performance metrics does not meet the configured level, a real-time alarm notification is sent to your operations team, which can instantly take action and therefore limit any potential negative consequences. Instant notification, instant reaction.
Service Level Agreement (SLA)
To quote wikipedia,
“A service level agreement (frequently abbreviated as SLA) is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.” – Wikipedia
Here, performance is the key. And performance is tied not just to the IVR application itself, but to the overall infrastructure. That is, you not only have to make sure that your application meets the performance requirements set by your internal stakeholders, but you also need to be able to assess that your infrastructure providers meet their respective SLA. When you think infrastructure providers, think about the whole solution in terms of point of failures from a customer perspective, including telecommunication pipes, toll-free and local numbers (all of them!), telephony hardware and software, IVR and CTI platforms, databases, etc.
But then again, how can you assess that such requirements are met? Metrics to the rescue! Continuously gathering metrics about the health of the overall application is key to such SLA acceptance or even to back your claim about any unacceptable performance issues from your provider.
You have launched your IVR service a while ago and you’re really satisfied in terms of ROI. However, in the last few months, you have heard about customers starting to complain about latencies. How odd. This situation could be explained easily: your IVR service has gained popularity. While your overall infrastructure was initially provisioned to comfortably handle a maximum of 10K calls on peak periods, your system is now handling 25K calls, thanks to an efficient marketing and communication department! While analyzing Erlang tables for your specific requirements, there is unfortunately no actual way to achieve prescience and predict your overall system popularity and success.
The only way to avoid user experience degradation due to usage growth is to rely on proactive provisioning. By continuously monitoring your application, gathering performance metrics over time gives you a powerful way to see trends and anticipate problems that will unavoidably occur if the infrastructure is not appropriately expanded. A constant increase in terms of response delay constitutes a good indicator of call handling performance degradation, while an increase in terms of both call setup time and failures might highlight a problem in terms of telecommunication capacity.
Last but not least: Revenue. There is a good chance that your business is interested in a constant revenue stream, where more transactions mean more profits. From this perspective, there is also a good chance that your IVR application serves as one of your company’s income vehicle, where each customer calling might be converted into a profitable transaction, either directly or indirectly. In this regard, each call lost may also mean a lost transaction and hence, potential revenue gone… forever. While a web transaction is, by its redundant nature, more tolerant to failures, where connection can be re-established, and transactions rolled over and such, it is not quite the case for over-the-phone transactions. Once the communication with your customer is gone, it is really gone. There is no such thing as a callback failover, agents or systems calling back your potential-revenue-customer. That could be a interesting business idea though. But that is another story : )
Mirador monitors your IVR system to make sure it is up and running, ready to accept incoming calls and perform transactions. That is, potential revenue-generating transactions.
Can your customers truly reach your IVR application? What about now? …And now? …now?
Coming up next: What’s in your monitoring alarm notification triggers?