800PBX Inc., USA has a very interesting IVR product. This is essentially an IVR Application that uses voice recognition for receiving customers calls and taking orders for pizza!

I found this quite interesting! Many a times, occasional Pizza eater like me, when I call up Domino’s Pizza, I get stumped by many jargn as well as various option and find no clue how to answer and prefer to hang up! But with Dial A Pizza (Restaurant) IVR Application will be of great help for people like us who will be able to listen the menu again and again ( which is not possible while talking to a live agent.) and try to understand and order the correct pizza.

800PBX offers toll free numbers too as the name suggests! They have offices in USA as well as in India. They have hosted IVR solutions.

Recent news article about 800PBX appeared on TMCNet.com from where I also got this information. Interesting quote as per the above article:

“A lot of automation is possible in the hospitality vertical,” said 800 PBX CEO Manohar Chapalamadugu. “It’s not just cost-driven, but quality enhancing as well.”
800 PBX Inc. provides virtual PBX and hosted IVR applications for both small and medium sized enterprises. 800 PBX specializes in IVR solutions like automated appointment scheduling, telephone orders, address captures and phone support systems.”’

For further reading or the full article, you can click here.

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.

All great products are great service to man kind. Or all great product becomes services to be availed by everyone!

IVRS or commonly known as Hosted IVRS is also a such product!

Apart from the analog low density IVR Applications, the digital and high quality IVRS has always been costly for small sized companies and they were trading quick and efficient service for cost. No longer now!

With growing acceptability as availability of quality service providers, Hosted IVR has become a reality and came in very much in the range of small companies!
Angel.com, a subsidiary of MicroStrategy, is the world leader in this!