features:

• Transfer to extension

• Transfer to voicemail

• Transfer to a queue

• Play message (e.g., “our address is…”)

• Connect to a submenu (e.g., “for a listing of our departments…”)

• Connect to reception

• Repeat choices

In the open source telecom community, you will often hear the term IVR used to de‐ scribe an automated attendant. However, in the telecom industry, an IVR is distinct from an auto attendant. For this reason, when you are talking to somebody about any sort of telecom menu, you should ensure that you are talking about the same thing. To a telecom professional, the term IVR implies a relatively complex and involved development effort (and subsequent costs), whereas an automated attendant is a simple and

The most common mistake beginners make when designing an AA is needless complexity. While there can be much joy and sense of accomplishment in the creation of a multilevel AA with dozens of nifty options and oodles of really cool prompts, your callers have a different agenda. The reason people make phone calls is primarily because they want to talk to someone. While people have become used to the reality of auto attendants (and in some cases they can speed things up), for the most part people would prefer to speak to somebody live. This means that there are two fundamental rules that every auto attendant should adhere to:

1. Keep it simple.

2. Make sure you always include a handler for the folks who are going to press 0 whenever they hear an auto attendant. If you do not want to have a 0 option, be aware that many people will be insulted by this, and they will hang up and not call back. In business, this is generally a bad thing.

Before you start to code your AA, it is wise to design it. You will need to define a call flow, and you will need to specify the prompts that will play at each step.

Let’s go over the various components of this template. Then we’ll show you the dialplan code required to implement it, as well as how to create prompts for it.

The first prompt is the greeting. The only thing the greeting should do is greet the caller. Examples of a greeting might be “Thank you for calling Bryant, Van Meggelen, and Associates,” “Welcome to Leif ’s School of Wisdom and T-Shirt Design,” or “You have

reached the offices of Dewey, Cheetum, and Howe, Attorneys.” That’s it—the choices for the caller will come later. This allows you to record different greetings without having to record a whole new menu. For example, for a few weeks each year you might want your greeting to say “Season’s greetings” or whatever, but your menu will not need to change. Also, if you want to play a different recording after hours (“Thank you for calling. Our office is now closed.”), you can use different greetings, but the heart of the menu can stay the same. Finally, if you want to be able to return callers to the menufrom a different part of the system, you will normally not want them to hear the greeting again.

The main menu prompt is where you inform your callers of the choices available to them. You should speak this as quickly as possible (without sounding rushed). 2 When you record a choice, always tell the users the action that will be taken before giving them the digit option to take that action. So, don’t say “press 1 for sales,” but rather say “for sales, press 1.” The reason for this is that most people will not pay full attention to the prompt until they hear the choice that is of interest to them. Once they hear their choice, you will have their full attention and can tell them what button to press to get them to where they want to go.

After you have designed your auto attendant, there are three things you need to do to

make it work properly:

•Record prompts.

•Build the dialplan for the menu.

•Direct the incoming channels to the auto attendant context.

We will start by talking about recordings.

Recording prompts for a telephone system is a critical task. This is what your callers will hear when they interact with your system, and the quality and professionalism of these prompts will reflect on your organization. Asterisk is very flexible in this regard and can work with many different audio formats. We have found that, in general, the most useful format to use is WAV. Files saved in this format can be of many different kinds, but only one type of WAV file will work with Asterisk: files must be encoded in 16-bit, 8,000 Hz, mono format.

The simplest method of recording prompts is to use the Record() application. For example:

Here is the code required to create the auto attendant that we designed earlier post(Dialer plan). We will often use blank lines before labels within an extension to make the dialplan easier to read, but note that just because there is a blank line does not mean there is a different extension:

         exten => 1,1,Verbose(1, Caller ${CALLERID(all)} has entered the sales queue)

ny call coming into the system will enter the dialplan in the context defined for what‐ ever channel the call arrives on. In many cases this will be a context named incoming, or from-pstn, or something similar. The calls will arrive either with an extension (as would be the case with a DID) or without one (which would be the case with a traditional analog line). Whatever the name of the context, and whatever the name of the extension, you will want to send each incoming call to the menu. Here are a few examples: