The Cost of Not Having IVR Analytics

Many companies seek out an IVR solution provider to buy and build an IVR for them.  This is typically quite expensive. The expenses are due to the software and deployment costs as well as the complexity of designing and developing a quality experience for the end consumer.

The solution provider in most cases will also pitch “reporting” or IVR Analytics.  The costs for this additional functionality can easily add $50k or more to the cost of the overall solution.  All companies are cost conscious, so this is usually one of the first things to be eliminated. Ironically it is one of the first things that the customer wishes they had after deployment.  Why?  They immediately need to see how the IVR is being used and ultimately whether the IVR is providing the ROI that their solution provider promised or that they pitched to their management team.

Analytics is crucial to answering questions about the IVR’s performance. For example, it enables an organization to see how many people are calling, how many are hanging up and how many are successfully completing self-service tasks.   It can answer questions about which DNIS’ are most heavily used and which menus need to be tuned in order to improve the caller’s experience.  Without them you are flying blind.  There is no practical way to measure success at almost any level.

When budget is a challenge or analytics isn’t prioritized, some companies will try to build their own systems.  This seems fairly trivial at the onset.  They will say, “Let’s just parse some log files.” This is a path that is long and arduous and may cost your company a significant amount of money. I will give you an example of what your journey to build a home grown analytics solution might look like based on personal experience.

Take One

You know that your log files have most of the information that you need to build the required reports.  Here is a partial list of the things that one needs to consider to get started.

• Where are the logs?
• How do we copy them on a regular basis?
• How do we keep the log parser from processing duplicates?
• What about permissions to copy the files?
• Firewall access?

And the list goes on…

Once you have the log files, you determine that you’ll just load the data into a simple database.  Thus the reporting schema is born.  This will be the scourge of your organization.  This is because you seldom think through all the use cases for your reporting database, thus it’s poorly designed from day one.

A program is written to pull the data out of the database and put it into an Excel spreadsheet.  This is always a moving target because the data you want and need is not in the database.  Thus the input parser is changed, the database is changed, and the post processing code is changed.  This goes on until someone finally realizes that this approach is too expensive and brittle.  Time to refactor…

Take Two

You now know exactly what you need to do.  Realizing that the data that is needed is scattered throughout the log file, there is an effort to create one record that has everything about the call in it.  The input parser is changed, the database is changed and a web based reporting system is deployed.  This necessitates a deeper analysis of what just happened.

The entire IVR had to be amended to change the call record that gets written to the log file.  How much did that cost?   The database probably required hiring a real DBA or shifting resources onto your team.  And what did that cost?  The parser was rewritten and an entire web based interface was built… that hurt.  This process makes the $50k upfront cost not look so bad.

And then your company is wildly successful.  Your call volume hits 50k calls per day and seems to be rising.  Your ability to keep up with the data volume fails horribly. The machines are underpowered, the database was not designed around these types of queries, the reporting system is slow, and it takes too long to get new reports.

Take Three

You now start your third attempt to get an IVR analytics solution deployed.  This is the real Enterprise level solution: message queues for real-time feeds, several multicore machines to run it all, a database that is built from the ground up using Data Mart design principles, and a decent tool to build and deploy reports.  Building, testing and scaling this is a set of non-trivial tasks.

Maybe you should have paid the money upfront; it would then be someone else’s problem more or less.

The Upside

If you choose speech analytics from the strategy phase of your IVR implementation, your path to visibility and tracking would look slightly more streamlined and cost efficient:

Step 1: Design and build your IVR

Step 2: As part of the testing process, an IVR analytics solution is deployed. This involves installing pre-built binaries for Call Data Record(CDR) processing, a database schema and the reporting front end. Throughout the testing process you will get real-time reports on the overall progress of an evaluation of the IVR. At the same time, you will develop an understanding of the capabilities of your reporting system.

Step 3: When it’s time to go to production, the same components are deployed. Once callers hit your IVR, you will immediately begin to see live, real time reports.

When you implement a pre-built, incremental reporting solution, you save time and money.  Out of the box, you will get basic reporting.  If in 6 months you decide that you need a tuning report, you can just turn the report on (there may be additional fees for this).  You will also have the ability to build custom reports and extend the schema as necessary (add-on service).

To learn more about IVR analytics, contact PTP.