FAQ – Frequent Asterisk Questions – #3

Last updated on June 25, 2014

Introduction

I’m a contributor at StackOverflow, answering questions concerning the Asterisk PBX system.  These types of questions, at their core, are part of my bread-and-butter work.  I’ve been working with Asterisk since 2004 and have personally deployed it successfully in 10 different countries under a wide variety of circumstances and use-cases.

Q: What Guidelines  should I follow to set up an IVR with Asterisk?

IVR design in Asterisk is not difficult, but there is a bit of a “learning cliff” associated with getting your first Asterisk server up and running.  Once you are that far, then you can consider taking on an Interactive Voice Response (IVR) system.

• I cannot stress enough that call quality is everything. Pay to have professional grade recordings done for your IVR prompts and your announcements.
  • Record your sound files in in 16-bit, 24-bit or 32-bit sound.
• Ensure that you’re using 64 kbit/s bitrate codecs such as uLaw and aLaw; GSM (cellphone) might be cheap on bandwidth, but it breaks your customer expectations about quality.
  • If you can, use the new HD audio standard codecs such as g.726.  Make sure your Internet Telephony Service Provider (ITSP) supports HD Audio, end to end;  JKL5’s Cloudphones SMB PBX service and our ITSP partners does.
• I strongly suggest that you put the IVR into it’s own dial plan context and then direct calls into it. That makes managing things like menu choices much easier. For each sub-set of options, use a different dial plan context.
  • I go a step further and break each menu into it’s own configuration file, and use “#include” statements to hook everything up.  It is easier to manage and maintain this way.
• If you are going to do something fairly cool with database look-ups, account authentication or the like, I’d recommend using an Asterisk Gateway Interface ( “AGI”) application.
  • My personal favorite is “Adhearsion“, which blends well with Ruby/Rails on the DB/Web side.
• Try and keep your menu “shallow”. If it takes more than three menu options to get the information your customer is looking for, they are very likely to hang up, or just press “0” to talk to a human. That defeats the point of your IVR.
• Make sure you have some plan for recording what options your customers pick, and if they hang up before “getting to the end”.  Have a plan to review that data regularly and take action of some kind on it.
  • An IVR your customers won’t use is worse than useless;  it’s a motivator for them to go elsewhere.

Your IVR is your “big handshake” with the customer.  If a customer is calling you, then it’s serious business time.  You absolutely need to get it right at every level.  It really is worth considering hiring a professional consultant to help you get the initial job done right.

Conclusion

So, that’s one common issue that I deal with regularly.  I’ll put a few more up next week.  If there is anything you’d like to see in particular, let me know in the comments below!