Apart from many benefits of IVR ( Interactive Voice Response) System for any business, call logs of IVR can be very beneficial. Normally, all IVR systems maintain a detailed call logs also known as CDR ( Call Data Record). In any modern and intelligent IVR, Activity Report is also expected to be maintained where every key-press, option choices made by the caller are maintained with time stamp as well as menu level.

These call logs are presented in human readable format and some IVR may even provide off-line simulation (playback) of the activities done by the caller! This kind of information and reporting of IVR calls can not only be used for improving usability of the IVR but also learning caller behaviour as well as lead capture and generation purposes for various businesses! Travel and Hospitality industry is such business where this kind of information can be converted to qualified business lead immediately.

What kind of Call Logs IVR system owner should expect ?

There are majorly two types of call logs an IVR can maintain.

1. Call Reports

This is an IVR report which stores and present number of calls, Caller ID, duration of Call, dialed number date wise, month wise or duration wise or any other way user may want. This can give quick overview of total usage of the IVR. The IVR which are used in call center or in situation where the call is transferred to a human agent, it should keep record of whom ( extension number) the call was transferred. This may become important in establishing as well as verifying efficiency of the human agent.

2. Activity Reports

Activity report should contain all activity performed by the caller call wise as in #1 above. This report contains every voice prompt played, menu options, as well as any database retrieval or third party API integration if any. This should also store time spent by the caller in responding any menu options. Few small information like if caller pressed any key while menu options being played or at the end of the menu options should also be stored.

How these reports can benefit a business ?

The benefits of above information and report is quite obvious. It can help a business following way:-

1. It will help determine peak time for IVR callers. When peak time are monitored, some one can relate it to any other business activity which may have triggered the increased IVR calls. This information is valuable to for any business planing.

2. By Caller IDs, one may be able to determine the areas from where maximum numbers of people are calling to the IVR. This information can be used to determine potential thrust areas for marketing or problem areas if they are found to be lodging complaints all the time!

3. Activity reports may help learn about callers interest in certain products and this information could be related with their caller ID and area. This may help depute suitable man power for such areas.

Apart from above, there are many ways to use IVR Call logs to benefit business activities! So if your IVR is not providing both Call Records as well as Activity Records, it is time you demand it from your IVR vendor or IVR developer.

Also, if you were not spending time studying call reports provided by your IVR system, it is time you do it and do analyze !

Watch this space for future article about benefit of IVR call reports specific to any industry.

The only direct revenue generating IVR Application is Voice Portal.  I have posted about using IVRS as Voice Portal before.  There I tried to explain the overall Voice Portal operation.  Here I would try to discuss about technical challenges of developing and running a voice portal.

I would say, Voice Portal Application should be broadly divided into three tasks.

1. Call Handling

In a voice portal, many calls land on the IVRS Application simultaneously.   The number of calls at one time depends on the number of voice resources hardware used. There are not many CTI cards which provide high voice resources in a single board.  Server PCs too have 3 or four PCI slots only. So, in a single server, one may not have very high number of voice resources. Though there are various ways to connect voice resources between separate servers, one IVR application is going to work on a Single Server only!

Presently I have worked on one server ( IBM X3400) that has one Dialogic SPCI4 and two DNI2410 connected through CTI cables. We have total 480 Voice Resources and we have experienced 480 calls during Class X board examination result. And our server dutifully crashed too ! I still do not know why it crashed due to CTI card failure, Dialogic HMP Crash or Our IVR Application simply crashed! A quick restart of the server itself was the quickest remedy and also calls began to decrease with time, but this experience has forced me thinking to handle large number of calls without Server crashing or needing to restart.

For any large voice portal SS7 protocol  is the best and most suitable connectivity with Switch. It gives many flexibilities in the design, architecture and scalability.

So, with the above experiences, I would say one should design IVR Application with the following points in mind:

1. One process should only handle one call.

2. This process should implement only the call flow part and interact with Call related Messaging exchange with CTI device driver. It should though give out periodical status and updates to another process which will record those updates.

3. Event Driven Designing might be better proposition than synchronous status driven design.

4. Application should be built with online debug and monitoring facility. .NET remoting seems to eb an excellent option. I have no idea if there is any Linux Equivalent of .NET Remoting.

5. Activity Logging Facility should be there with another process. The call handling process should not be given any other task other than call handling. I have observed major problems occurring with other tasks like writing to disk, database etc. which might crash the call handling process.

2. Database Handling

Voice Portal Application generates huge amount of database records. Mainly apart from mandatory, CDR ( Call Data Record), it is expected that it records each and every activity by the caller. This produces in turn huge records. Many people tend to overlook this during designing of Voice Portal and pay heavy price later. And these many people includes me for sure.  All database handling tasks should be given to dedicated process whose sole activity is to insert and fetch data by Call Handling Process.

[ad#large-ad]

My personal preference of database is MySQL as it is free and MySQL 5.0 and above have really cool features! But MS SQL is easy to install, learn and compartively larger trained manpower available.

Here are few guidelines I wish I had followed:

1. Two Tables one for Call Log and another for Activity Report are very important! So these two tables must be designed very well keeping in mind that these two tables will be used for many inserts as well as fetch during billing calculation.

2. Proper Indexing and avoiding data types like varchar, or any other datatype which takes longer time to process should be avoided.

3. Professional DBA should be given the task of Database design is the bottom line while IVR Engineer should restrict themselves to Call handling Part!

3. Content Management

Content management is often overlooked part of any Voice Portal Application! But once the above two tasks are complete and works flawlessly, its is the Content Management that needs constant upgradation with news services, applications! So, designing CMS application at the beginning of Voice Portal development should be stressed and followed. If possible, I would say Billing Computation should be totally seperate application than CMS.

I would say the following points to should be kept in mind:

1. CMS should support only local site (Single Site) or has to support remote site (Multiple Sites) too.

2. CMS Should have facility to check content before actually uploading the content. It should forcefully ask remainders to play the content once. Though its annoying, but it will help adding wrong content at wrong place!

3. It should support various wave format/ mp3 format conversions.

4. Should have remote FTP facility for remote upload/download.

hmm! Pretty Long and boring Article! Well, these are my own experiences and I have not actually developed very large Voice Portal yet. I tried Googling/Yahooing a lot about information about Voice Portal Development, I did not find many useful information. So I thought myself writing one! Please help me with your valuable input. I am a quite newbie here! Thanx in advance.