Recently, Tata Docomo, India is advertising about IVR used in its customer care where it says that in order to keep it simple, they allow caller to speak to human agent quickly without going through maze of key-presses, listening lengthy and boring menu announcements!

Well, one line comes to my mind quickly, if you want your caller to get connected to human agent, without having to use self service IVR, then please use ACD ( automatic call distribution ) system available in almost any PBX available now a days!

The actor is Ranbir Kapoor, one of the most popular young actor in Hindi film industry. The script is in Hindi, the English translation would look resemble below :-

“Think if every one starts speaking the way customer care of mobile compaies treat their customer when they call,”

Daughter would say, “Daddy, may I have ice cream ?”
Father would reply, “If you want now, press 1, if you want to have it later, press 2″ ( laughter)

Daughter : Daddy, do you love me ?
Father : Your question is very important to us, please be online

(laughter)

While TATA-DOCOMO may think that making their caller to speak to human agent, “they are keeping it simple”, they should remember few points here about IVR :-

1. IVR is essentially a system which is capable of providing important information to caller on telephone in voice without any human intervention. While the same task can be performed by human, but machines perform better than human 24 hours a day with more efficiency as they don’t tire, they don’t take lunch break ( or attends natures call )!

2. A machine like IVR gets tired or bored unlike humn either it is morning or evening, summer or winter and can never abuse the caller even when abused or provoked by the caller!

3. Machines do not leave the job and join a rival company!

Finally, while IVR may not be the answer to all customer problems, but it can surely provide some information related to mobile phones like prepaid balance, listen to current bill amount and bill due date etc.

So, TATA Docomo should hire IVR specialist or VUI ( Voice User Interface) designer to make their customer care simpler and more efficient!

Recently, I have been getting many messages from this IVR blog visitors asking how to choose right IVR system for their organisation. While majority of the people who asked wanted to automate their customer service process, they have one common requirement, minimum initial investment possible!

IVR (Interactive Voice Response) Systems are available in two ‘forms’, hosted IVR and On Premise IVR. Choosing right IVR solution among these two types, may not be easy. I would try to document few points to consider between the two IVR types.

1. Cost of IVR system
Every IVR system has three cost components apart from general maintenance and up-gradation cost.

a. Cost of CTI hardware as well as Computer Systems
Normally this is fixed and one time cost unless some capacity enhancement is required in future. There are many options for CTI boards now a days, low cost and high cost. For example, Synway, Sangoma at the low cost end and Dialogic at the high cost end.

b. Cost of Customised Voice Application
This is the IVR call flow implementation cost which may include integration with third party application like CRM, Web Services etc. Now a days, many DIY ( Do It Yourself) tools are available in visual or simple TAG based format. For example, visual tools from Invox, Omnivox3d from Apexvoice, Osidial from Ositron, Comsys etc. and VoiceXML, PPHVoice. But one has to invest in either in-house qualified manpower or get the voice application developed from IVR software provider.

c. Telephone Cost
While incoming call is free any telephone number, still there is rental cost associated with even normal telephone connection. Toll free numbers, outbound IVR call are charged ‘per call, per minute’ basis to the IVR owner. Many IVR involves call transfer and it may also cost per call, per minute basis.

In an hosted IVR system, cost component 1.a does not arise but it can not escape the cost components 1.b and 1.c.

In on premise IVR system, 1.a would be a must along with 1.b and 1.c, but it can escape from call transfer cost by using PABX system. In a call center scenario or where human agent has to interact with IVR caller, the cost of ‘call transfer’ could be quite high in the long run depending on call volume!

2. Flexibility of the Voice Application or IVR Call flow

This is a important factor for choosing an IVR system. There are some IVR application which have fixed call flow and there are some where call flow needs to changed or configured continuously. Flight announcement, Train status, IVR payment are few of IVR applications where the call flow can not be changed being public utility. There are IVR surveys, which need to changed or configured after completion of any survey!

Even IVR in call center need not be changed frequently as it may confuse regular caller. But call center IVR needs many ‘call transfer’ for human interaction with IVR caller.

So, one has to choose between hosted IVR or on premise IVR depending on voice applications running on the IVR system. It may influence the cost of the IVR as well as its maintenance and flexibility.

So, according to me, these two factors should mainly decide what kind of IVR sysetm one should opt, either hosted IVR or on-premise IVR.

One of the major problem faced by any IVR developer using analog CTI board is “Detecting Disconnect” after call is hung up by IVR caller. With different disconnect tones used by different PBX manufacturer does not help either.

Detecting Call End or Disconnect is very easy while using digital CTI board with digital interfacing like ISDN, SS7 etc., but detecting DISCONNECT is not that straight forward or easy while using analog CTI boards. It is mainly because of exchanging “control information” with analog technologies!

There are few techniques or information using which DISCONNECT event can be detected and Call End process can be initiated in any CTI application:-

1. Disconnect Tones
This is most widely used information which is used by all PBX systems in the world. In analog telephone call scenario, in India, called party can not hang up the telephone call. It is the calling party which can disconnect the call and when he disconnects the call, PBX generates some “Disconnect Tones” which is recognised by CTI board and may send an event accordingly to the CTI application.
Normally, a “Disconnect Tone” vary from one PBX to another. But they follow same pattern, some Tone with fixed freqency for few seconds, then silence very short period, then again tone with another frequency, short silence, again first frequency, short silence. This sequence of “Tone1-Silence-Tone2-Silence” continues for some time and the line goes completely silence.

There are many tools available to get these frequencies and duration of tones, silence. Dialogic provides PBExpert ( requires two telephone extensions or telephone lines) which can be used directly to configure its driver to detect disconnect tone. One may also record the “Disconnect Tone” and find out its frequency, duration of silence, duration of tone period and then use them in the CTI programs to detect Call Disconnect event. CoolEdit, Audacity are few sound software which can give you information about frequency in sound file as well as duration.

Detecting CALL DISCONNECT using these “disconnect tones” are slow ( takes 10 to 30 seconds) and may not work with 100% accuracy. Also, many times, busy tone and disconnect tones in PBX systems tend to be same or similar. With recent introduction of CRBT ( Caller Ring Back Tone), task of detecting Disconnect Tone has been made more difficult!

2. Loop Current Drop

This is another method of detecting DISCONNECT condition while using Analog CTI boards. Many PBX systems use Loop Current Drop or Loop Reversal which is detected by analog CTI boards and pass on to CTI applications. Many analog CTI boards may not support this facility and many modern PBX too stopped this feature.

3. Using Timer in CTI application

One of the widely used “Call End” condition is detecting silence or time out waiting for caller input in the form of DTMF key pressing or Speech. This is easy to implement, independent of any PBX, but it is time consuming and tend to be very slow.

So, best way to detect call disconnect while using analog CTI boards would be to us hybrid of techniques mentioned above. And the best method, according to me is to use digital CTI boards, but this may not be possible always, though!

Caller Ring Back Tone or CRBT has become major revenue earner for both teleom companies as well as value added service providers. Not to mention, music companies. Though, I personally prefer the “good old” ring back tone to the latest music number, but many people have been using it on their cell phone, or even land line numbers.

Occasionally, I keep getting mails about how CRBT can be implemented, recently one guy mailed me specifically, “could we implement CRBT locally in our PABX installed in our office ?”, It got me thinking, and I thought I would share my thinking here. Yes, anyone can implement CRBT or caller ring back tone ( Color Ring Back Tone is also used by some, specifically in Dialogic Application Notes) in their PABX system as long as it has digital interface for CTI boards. Technically, that is. Be careful with music copyright though!

But, in a way, CRBT was always present in PBX system in the form of HOLD music during transferring a call, call parking, call on hold ( in a limited way of course)! The same hold music was converted to CRBT which became very successful in terms of hype and revenue.

I have always maintained that CRBT is nothing but an IVR application which generates lot of money ( for Telecom companies) and which has brought IVR to masses! So, it order to implement CRBT, all you need is IVR applicaion with database integration!

Here is how one can implement CRBT on a ISDN PRI in a on premise PABX :-

• Every incoming call is send to IVR application by PBX which is connected PBX using ISDN link.
• IVR applications receives the incoming call on say channel A, retrieves “dialed number” information from the incoming call.
• IVR then checks the database if the dialed number has subscribed to CRBT and also a particular music.
• IVR now dials out the “dialed number” using separate and available channel ( say channel B) of the ISDN Link and checks if it is ringing. If yes, then it plays the particular music to the incoming call ( CRBT of dialed number for the caller). If not, it is busy, it will play busy tone or directly bridge both the channels, ie incoming and outgoing channels A and B.
• As soon as channel B detects call pick up by the “dialed number”, it will bridge both channel A and B.
• When any one of the parties disconnects, change back to original!

This scheme may not be the optimal solution for implementing CRBT as it uses two channels known as trombone, but this works! Did I mention, you must use Digital CTI board which supports call bridging feature ? Almost all Dialogic digital boards or equivalent from other manufacturers have this facility.

So, if someone is thinking of implementing CRBT for one’s office, you may see all people dialing each other, listening to music!

Most probably, the most dreaded and time consuming part of deployment of IVR system is the integration of CTI board with the telecom switch or EPABX. And if EPABX or switch is of lower end or from smaller EPABX manufacturer ( there are few in India), it may become really a nightmare for IVRS integrator or IVR Software provider.

While integrating IVR System with big Telecom operator, the blame of technical incompetence always fall on IVR software provider, specially in India. And if it is a government agency or PSU (Public Sector Undertaking), it is a real pain (anyone can guess where it is)! One needs real talent for handling those people. I have seen technical support engineer from CTI vendor spending months trying to integrate high end CTI board with certain Indian PSU! Once it took me almost 2 months of cajoling certain Indian PSU official to explain and make them understand them they are not sending DNI(Dialed Number Identification) due to which my Dialogic Board is not detecting any DNI.

Here is a list of problems IVR System integrators face with EPABX supplier or Switch People:-

1. Interfacing protocol
Most of the time, switch people or EPABX support people do not provide proper and complete information interfacing protocol to be used. Most commonly used interfacing protocols are SS7, ISDN PRI, R2MF or analog. One may say, analog interfacing is the easiest as it requires the least interaction with switch guys or EPABX supplier for integrating with CTI boards.

2. Lack of experimentation support
It is really pain to ask them for minor parameter change like CRC ON or OFF, which is a major problem in interfacing digital CTI boards with switch/EPABX. Many switch guys or EPABX people just do not want to change those parameter even for 5 minutes or so for testing purpose. Also worst part is, they do not inform accurately about the CRC status at their switch end. To be fair to switch guys, I think they do so because they can not afford to change those parameter as they may effect their existing working connections! But than there are various options, right ?

3. Lack of common jargon
EPABX or switch people seem to be using a lot jargon which is not easily understandable to CTI Board support team or IVR developers. With lack of proper communication, normally by the switch or EPABX manufacturer, things get worse. E1 lines are known as PCM lines by many Telecom engineers. In SS7 protocol, time slot number for signaling and voice differ from one Telecom operator to another and this is normally not communicated properly. In ISDN protocol, many EPABX manufacturer use Trunk Mode or User mode while CTI manufacturer use jargon like Terminal Mode and Network mode. It is not easy to relate those and poor IVR system developers suffer in between.

4. Lack of Communication between Switch team and CTI Technical Support
Generally during IVR system deployment, IVR software provider supplies the CTI board as well as the IVR software. In that scenario, most of the time, CTI technical support engineers do not interact with switch team or EPABX supplier and every communication go through the IVR software provider. This also add to the problems of IVR Software provider as he gets to hear complaints ( taunts) form both sides that the hardware from other side is not working properly. IVR software provider may experience really hard time providing logs from both sides to each other and explaining the significance to both sides.

Well, many IVR engineers, consultants must be facing these kind of problems or many more all the time and somehow managing to solve them. But this kind of avoidable problems really is painful to third party IVR developers.

One thing I keep asking myself is, EPABX manufacturer does not support IVR application developers while that is in their interest ? IVR developers or third party CTI developers can surely help EPABX manufacturer by helping developing many value added services for their switches PBXs.

My personal experience has been that CTI manufacturer provide very good support and assistance to IVR developers while EPABX manufacturers or switch guys do not provide much help to IVR software providers. I have been quite happy with supports from CTI manufacturer like Dialogic, Donjin, Synway. They have been helping me quite out of the way to integrate their boards with various switches/EPABX. Sadly, I can not say same thing with switch guys or EPABX manufacturers.

Most probably, the time has come to form an association of IVR suppliers in the world to demand and protect their rights by IVR professionals where they get legitimate and necessary support from switch/EPABX manufacturer for smooth deployment of IVR systems.