Most probably, the debate on merits and demerits of using ASR ( Automatic Speech Recognition) would continue for some time to come, but in case of India, there are three compelling reason avoid using ASR where simple, old, robust and universally understood ‘keypress’ can do. While ASR can surely speed up and increase interactivity of an IVR system, in Indian scenario, it can be a big nuisance, specially for IVR vendors providing IVR to be used nationwide.

Here are my reasons:-

1. Poor Recognition due to background noise

With due respect to all ASR engines, India is a loud country with lot of noises all around! So, with lot of background noise, it is not possible to recognise words or phrases with high degree of accuracy. Indian cities are noisy with lot of noise pollution all around. Even Indian houses are not well ventilated. Indian villages are crowed with various domestic animal who create lot of sounds.

Because of this background noises, good ASR engines also fail to perform properly and end up with poor accuracy. But users will never appreciate the ‘genuine’ technical problems behind this, but the blame will fall squarely on IVR developer or IVR Vendor.

2. Languages and Accent

India is home to 1652 languages. Out of these, 29 languages are spoken by more than more than 1 million people and another 122 are spoken by more than 10,000. It has officially recognised 22 languages. English is widely spoken and understood all around the country but India also has more than 250 million illiterate people.
So with this statistics, one can easily figure out the changes in accents for speaking even English numerals, forget about English words or Phrases!

This lack of common accent for speaking out any word or phrase prevent any ASR engine detecting them accurately. But, everyone who has dialed into an IVR system, already know how to press a key from the telephone instrument or the mobile. So, in order to wider use of IVR as well as accuracy, ASR should be avoided.

3. Poor Mobile Signal

Most of the recent telephone users in India are mobile phone users. Apart from big cities, large areas as well as large pockets of cities too, have poor network signal and keeps fluctuating rapidly. Due to which, two human may be able to somehow communicate, but in case of IVR, there chances that it would miss some voices, part of voice which are vital for recognising a word or phrase by ASR.

So, even the best ASR would fail to detect words accurately resulting in caller dissatisfaction, call abandonment which will defeat the very reason for using an IVR system.

While there would be remedies, tricks and techniques to address these problems, but these are top reasons if some one wants to avoid using ASR in India!

Today on 23rd August, ivrsworld.com has turned two years old!

I would like to thank all readers and their valuable comments on this blog. When I started writing this blog two years back, I simply wanted to keep posting about information about IVR that I Google in internet, various IVR related news, my personal experiences with various IVR projects. But I think it has now become a blog about IVR!

IVR Visitor

The turning point came somewhere December 2009, when this blog had started getting more than 100 unique visitors per day and I thought I should take it seriously ( presently, the latest figures in Google analytic shows 4400 unique visitors a month, majorly from India, USA, Canada and Europe). It felt good when this blog is shows up at first page in Google while searching for many IVR related keywords! The registered readers ( Google Feedburner) of the blog has reached 100 with email IDs ending with dialogic.com, sangoma.com, pronexus.com, invox.com, aculab.com to name few! These were surely inspiring!

Then VBVoice, IVR toolkit for .NET developers came as sponsor which was moral booster! Otherwise I was majorly using Google Adsense to display graphics, not to earn anything!

Then MessageTech, the hosted IVR Service provider has come to sponsor and I even could afford a paid WordPress Theme for the blog.

I thank you all the sponsors for sponsoring this IVR blog which were really helpful and inspiring. I hope to have one more sponsor this year so that I could host www.ivrsworld.com on VPS/dedicated server with minimum down time . Presently it is on a shared hosting and I have been embarrassed few times when readers mailed me to inform they were not able to open the site.

I thought I would prepare a PDF book in the second year, unfortunately I could not not achieve that, but this year, I will again try to achieve that. Other wise, I think, ivrsworld.com has had a good year!

This year, I would test more CTI boards, IVR RAD tools and post my experience here. And at the end of year, I would like to prepare a comparison chart using some common parameters.

There are few parameters or features of IVR which are important and are common to almost any type of IVR application. These parameters play very important role in making the voice application more user friendly. These parameters are used at many stages in IVR software or in any call flow. I hope, knowing these would help people who are looking to develop an IVR or looking to purchase IVR software.

These are very small parameters, but they may play crucial role in reducing call abandon rate in IVR. Some of them are :-

1. Allowing or not allowing caller to press a key while IVR plays the menu options

IVR may be configured to accept or to reject any key press while caller is listening the menu options. Allowing to press key during playing of menu allows caller to ‘cut through‘ the IVR menus and reach his desired IVR stage or menu quickly. But it may also increase chances of wrong key press, specially when some menus options are changed. Many regular caller may not like to hear known menus again and again.

2. Duration to allow a caller to press any key or voice command

Waiting time for callers key press or voice command may become crucial. During wait period, IVR does not play anything and become silent, so if this wait period is too long, caller may think the IVR is not responding, so disconnect the call.

3. How many times to play a same menu and number of attempts to choose correct menu options

Naturally, people make mistakes while pressing key or may make mistakes intentionally. So, it is important to decide the number of attempts one may try for each and every menu options. This kind of parameter may be required even while accepting some valid input from caller, for example mobile number, customer ID, complaint ticket etc. If this is not defined, then some caller may occupy some channel of the IVR unnecessarily.

4. Confirming menu menu selection of digit (s) pressed or voice command spoken

It is an important decision to make. Should IVR confirm every menu choice made by caller or not! Even in any software, when some one tries to do some important task, it pops up an confirmation window, similarly, IVR also ask confirmation for menu choice! But it may also irritate IVR caller. When using ASR ( Automatic Speech Recognition), confirming every option may become a necessity rather than a choice.

5. Inter-digit pause while expecting more than one DTMF keys as input from caller.

While caller enters multiple digits as input to the IVR, for example, credit card number, phone number, ID number, the duration of pause in between two consecutive DTMF digits or key press is important. Very long inter digit pause may result caller disconnect.

6. Using # ( hash) or star (*) keys to terminate

Deciding to use # or * keys to end entry of multiple digit is a good option. But these keys may also confuse some people who do not know about # or * keys as many of them do not use these keys. In India, many land line phones do not have # key. But with penetration of mobile phones, one may expect people to know about these keys.

These parameters are quite common and many developers use some configuration files or provide user friendly forms to configure.

What is IVR customisation ?
Normally, an IVR application is designed and developed as per requirement of the customer by IVR companies. But they have ready-made modules tested and readily available for quick development. Normally, the modules like, telephone interface, ring detection, caller ID detection, database connectivity etc. are always readily available. Also many people use RAD tools for IVR customization where they simply implement call flow required by the customer. So IVR customising can be described as implementing call flow of the IVR application as desired by customer using existing IVR related software modules.

In fact, after RAD (Rapid Application Development) tools have been introduced, IVR development have become just IVR customisation. Many IVR functionality, modules are available in RAD tools ready-to-be-used. It is not easy to develop an IVR application from scratch, as it involves auxiliary knowledge and experience about telecommunication switches, telecommunication standards and protocols, speech recognition, TTS.

While RAD tools are easy and quickest way to developed customised IVR application, but it may not suitable for IVR customisation which needs to interact with existing business processes or existing software which generate various data to be provided by the IVR. For example weather update, complaint ticket generation, complaint status update etc. Apart from these kind of complex and very sophisticated IVR systems, RAD tools are excellent development or customisation tools for IVR solutions.

One important aspect which many people overlook is writing script of voice prompts and recording of voice prompts professionally. IVR systems are to be deployed to be used by normal people for availing services, solutions from it. IVR system interacts with its user ( caller to the IVR) through voice prompts. Any mistake in voice prompts may render the IVR useless. For example, if the voice prompts announces, “to know your complaint status, press 1, or press any key to end the call.” Now imagine if IVR is coded to recognize 1 for disconnecting the call and any other key for asking further information to retrieve complaint status!

So, while customising IVR application, one must write script for voice prompts and record them with professional voice artists. Without this, IVR system may have the best of the hardware and most well coded software, still IVR system will not be useful to its intended users.

While customising an IVR application, one should think about future enhancements. Many times, one finds out that existing codes can not be used for enhanced services, features and everything needs to be done from scratch. This not only delays the process of upgrading IVR systems, also it become costlier.

While integrating with third party application or software, direct interaction with their database should be avoided. If you do so, any changes made by them would require you to make changes in your code too. So I think HTTP URL is a very good approach where you send few parameters for exchanging data from third party application. This will ensure that your IVR code need not be changed even if third party database is changed.