Non-Profit Tech Blog

IVRs – what the heck are they? IVR stands for interactive voice response system. Why would you want one? Because many non-profits are understaffed and need to have people answer calls on their PBX. Is it impersonal and perhaps not really reflect the ethos of the caring, sharing social services non-profit? Probably, but it doesn’t have to be that way. A well-programmed application doesn’t have to result in “voicemail hell” for the client.

The major reason for non-profits to do this is cost. The cost of one person answering a phone can come out to thousands of dollars a year if you’re not prepared to really dig into the issue and find a solution.

The non-profit I work for has an IVR. I wrote up the grant request and we ended up with a wicked open-standard IVR from Plum Voice Portals. Why an IVR and more importantly why an IVR that uses the VXML 2.0 standard?

A properly programmed IVR can SAVE money AND provide better service AND increase employee morale by reducing the amount of stress employees have in fielding calls from the client population. My org keeps client’s snail mail around so that they can pick it up. These clients are homeless so without our org’s snail mail address they could not effectively communicate with the outside world. What’s in this snail mail? Practically everything — checks, letters from family and loved ones, communications with parole officers, the whole gamut of communications between a homeless client and his or her social services. You can imagine what would happen if a population of several thousand clients all decided to call our one mailroom person as to the status of their snail mail. She literally couldn’t answer the phone anymore.

We did some research and set some criteria for purchase:

• Make sure it conforms to open standards. You’d be surprised at how hard it is to do this in the world of proprietary IVRs. Many of the old-school telephony vendors erected barriers to interoperability in a marked divergence from the rapidly evolving world of open standards PC-based solutions. It was the old razor and blades routine but both the razor AND the blades were expensive.
• Make sure you’re not so dependent on the vendor after the initial purchase. This is a huge problem in the telephony space. No one person can know everything (especially me). While I’m strong in application development and pretty good at systems administration, there’s a limit to what I know about telephony. Vendors love to exploit any gaps in your knowledge especially if it results in future sales. To PlumVoice’s credit, I have not had to ask them to build any new applications for us. They also don’t show up on my door trying to sell me something I don’t need.
• Look at TCO for the box. I wanted to keep any costs after the purchase as low as possible.
• Ease of use – PlumVoice’s application setup screen is VERY easy to configure and you can set up a “Hello, world” type application for the IVR literally within 30 minutes of installation completion. Plus, VXML is a very human-readable programming standard and Javascript is also pretty open-standard too. Having a large developer community already familiar with both standards is far better than trying to learn some proprietary API that few people write code for.

In general, the IVR application answers the phone, ask for a client’s 5 digit password and the IVR would then retrieve that client’s record from our database that tracked client’s snail mail and then says “You have mail” AOL-style at them. It does this in Spanish as well.

This immediately decreased the number of visits to our org by the clients and the mailroom staffperson was very happy. Soon afterwards, reports came back to me saying that the clients PREFERRED the IVR over the staffperson because a) the lines to the IVR were never busy and b) they could call any time 24 hours a day, 7 days a week.

Here’s the technology behind this project:

Plum Voice Portal IVR – http://www.plumvoiceportals.com

Microsoft SQL Server – http://www.microsoft.com/sql/

IIS 5.0 – http://www.microsoft.com/windows/iis/

VBSCRIPT and ASP – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/0a8270d7-7d8f-4368-b2a7-065acb52fc54.asp

VXML 2.0 – http://www.w3.org/TR/voicexml20/

BTW, the number of lines you assign to the IVR is an important key to success. If you only assign one line to the IVR, you won’t have enough throughput to make the application work well because the line does get busy.

Also, you’ll need to have a fairly good knowledge of the administrative options of your PBX. In my case that’s the Avaya S8100. We purchased this in 2003 — well before Asterisk and it’s VOIP-based PBX/IVR project.

Confessions

1. Wish I didn’t have to use an Avaya PBX — the one I’ve got the Avaya S8100 is overpriced and underperforms accordingly. For instance, I can’t pass the caller ID/ANI from the IVR to the Avaya S8100.
2. Would like to re-engineer this so that the vbscript didn’t generate VXML on its own but instead worked as a web service that passed XML which in turn was converted by XSL into VXML
3. Would LOVE to add more languages – the human kind not the computer kind
4. Computer-generated voice on the PlumVoice IVR is passable but we don’t use it. It sounds like the computer is very, very nervous. My wife always has a good laugh when she hears it
5. Need to read up more on proper VXML app design (one of the problems of being the only IT guy around is that you never have time to do more than just hack an app together) Check this link out — http://www.voiceingov.org/blog/?p=66
6. I wish I could make it so that users would be able to simply bypass the greeting and type in a number. Unfortunately, users need to type in which human language they want the system to respond in so that always wrecks my dream of a super-simple interface.
7. Would have been nice to set it so that each user had a set preference of which language they wanted but the problem is how to administer afterwards. Changing languages in the middle of a phone call is a bit complicated to script and I’d hate to have our clients get confused.
8. Wish I didn’t have to do this in vbscript but that’s the platform we had when we were doing this.
9. Would love to put this on a 1-800 number.

Oh, and if all this sounds like a plug for PlumVoice. It’s not. They didn’t know I was going to write this nor is there any compensation. Unfortunately, time marches on and there are many other and cheaper (by roughly 33% to 50% of cost) options available now if you’re looking to set one up for your non-profit. In fact, I strongly urge non-profit IT directors looking at IVRs to consider the built-in IVR option for Asterisk although I think it’s a C++ interface. I prefer VXML because there seems to a be a lot more developer support for VXML than C++ in an Asterisk IVR context. There also seems to be another option besides Asterisk — sipX. Check out this link — http://sipx-wiki.calivia.com/index.php/SipX_MediaServer_Functionality. From what I can tell, it’s a full VXML interface that lets you also serve cool little media files too.

Send me an e-mail if you want to try out the app although it’s not a local call if you’re not in New York City.