The Automated Attendant(asterisk)

The Automated Attendant

In many PBXs it is common to have a menuing system in place to answer incoming calls automatically, and allow callers to direct themselves to various extensions and resources in the system through menu choices. This is known in the telecom industry as an automated attendant (AA). An auto attendant normally provides the following

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

An Auto Attendant Is Not an IVR

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
inexpensive thing that is common to most PBXs.

Designing Your Auto Attendant

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.

basic automated attendant

Screenshot from 2019-09-25 12-53-33

 

Screenshot from 2019-09-25 12-55-55

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 Greeting

The first thing the caller hears is actually two prompts.

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

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.
Another point to consider is what order to put the choices in. A typical business, for example, will want sales to be the first menu choice, and most callers will expect this as well. The important thing is to think of your callers. For example, most people will not
be interested in address and fax information, so don’t make that the first choice. 3 Think about the goal of getting the callers to their intended destinations as quickly as possible when you make your design choices. Ruthlessly cut anything that is not absolutely
essential.
Selection 1

Option 1 in our example will be a simple transfer. Normally this would be to a resource located in another context, and it would typically have an internal extension number so that internal users could also transfer calls to it.

Selection 2
Option 2 will be technically identical to option 1. Only the destination will be different. This selection will transfer callers to the
support queue.

Selection #

It’s good to have the option for the directory as close to the beginning of the recording as possible. Many people will use a directory if they know it is there, but can’t be bothered to listen to the whole menu prompt to find out about it. Impatient people will press 0,
so the sooner you tell them about the directory, the better the odds that they’ll use it, and thus reduce the workload on your receptionist.

Selection 3

When you have an option that does nothing but play a recording back to the caller (such as address and fax information), you can leave all the code for that in the same context as the menu, and simply return the caller to the main menu prompt at the end of the
recording. In general, these sorts of options are not as useful as we would like to think they are, so in most cases you’ll probably want to leave this out.

Selection 9

It is very important to give the caller the option to hear the choices again. Many people will not be paying attention throughout the whole menu, and if you don’t give them the option to hear the choices again, they will most likely press 0.
Note that you do not have to play the greeting again, only the main menu prompt.

Selection 0

As stated before, and whether you like it or not, this is the choice that many (possibly the majority) of your callers will select. If you really don’t want to have somebody handle these calls, you can send this extension to a mailbox, but we don’t recommend it. If you
are a business, many of your callers will be your customers. You want to make it easy for them to get in touch with you.

Timeout

Many people will call a number and not pay too much attention to what is happening. They know that if they just wait on the line, they will eventually be transferred to the operator. Or perhaps they are in their cars, and really shouldn’t be pressing buttons on
their phones. Either way, oblige them. If they don’t make any selection, don’t harass them and force them to do so. Connect them to the operator.

Invalid

People make mistakes. That’s OK. The invalid handler will let them know that whatever they have chosen is not a valid option and will return them to the menu prompt so that they can try again. Note that you should not play the greeting again, only the main menu prompt.

Dial by Extension

If somebody calls your system and knows the extension she wants to reach, your automated attendant should have code in place to handle this.

Building Your Auto Attendant

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

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.
There are essentially two ways to get prompts into a system. One is to record sound files in a studio or on a PC, and then move those files into the system. A second way is to record the prompts directly onto the system using a telephone set. We prefer the second method.
Our advice is this: don’t get hung up on the complexities of recording audio through a PC or in a studio. It is generally not necessary. A telephone set will produce excellent- quality recordings, and the reasons are simple: the microphone and electronics in a telephone are carefully designed to capture the human voice in a format that is ideal for transmission on telephone networks, and therefore a phone set is also ideal for doing prompts. The set will capture the audio in the correct format, and will filter out back‐
ground noise and normalize the decibel level.

Using the dialplan to create recordings

The simplest method of recording prompts is to use the Record() application. For example:
[UserServices]
exten => 500,1,Playback(vm-intro)
same => n,Record(daygreeting.wav)
same => n,Wait(2)
same => n,Playback(daygreeting)
same => n,Hangup
exten => 501,1,Playback(vm-intro)
same => n,Record(mainmenu.wav)
same => … etc … (create dialplan code for each prompt you need to record)
important point-
In order to use this context, you will need to include it in the context where your sets enter the dialplan. So in your [LocalSets]
context, you will want to add the line include=>UserServices . In a production environment, you’ll probably want a password on this so that not just anybody can record prompts.
This extension plays a prompt, issues a beep, makes a recording, and plays that recording back. It’s notable that the Record() application takes the entire filename as its argument, while the Playback() application excludes the filetype extension (.wav,.gsm
, etc.). This is because the Record() application needs to know which format the recording should be made in, while the Playback()
application does not. Instead, Playback() automatically selects the best audio format available, based upon the codec your handset is using and the formats available in the sounds folder (for example, if you have a daygreeting.wav and a daygreeting.gsm file in your
sounds folder, Playback(daygreeting) will select the one that requires the least CPU to play back to the caller). You’ll probably want a separate extension for recording each of the prompts, possibly hidden away from your normal set of extensions, to avoid a mistyped extension from wiping out any of your current menu prompts.

The Dialplan

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:
[main_menu]
           exten => s,1,Verbose(1, Caller ${CALLERID(all)} has entered the auto attendant)
           same => n,Answer()
          ; this sets the inter-digit timer
           same => n,Set(TIMEOUT(digit)=2)
          ; wait one second to establish audio
          same => n,Wait(1)
          ; If Mon-Fri 9-5 goto label daygreeting
          same => n,GotoIfTime(9:00-17:00,mon-fri,*,*?daygreeting:afterhoursgreeting)
          same => n(afterhoursgreeting),Background(nightgreeting) ; AFTER HOURS GREETING
          same => n,Goto(menuprompt)
          same => n(daygreeting),Background(daygreeting) ; DAY GREETING
          same => n,Goto(menuprompt)
          same => n(menuprompt),Background(mainmenu) ; MAIN MENU PROMPT
          same => n,WaitExten(4) ; more than 4 seconds is probably
                                                  ; too much
          same => n,Goto(0,1) ; Treat as if caller has pressed ‘0’
         exten => 1,1,Verbose(1, Caller ${CALLERID(all)} has entered the sales queue)
         same => n,Goto(Queues,7002,1) ; Sales Queue
         exten => 2,1,Verbose(1, Caller ${CALLERID(all)} has entered the service queue)
         same => n,Goto(Queues,7001,1) ; Service Queue
         exten => 3,1,Verbose(1, Caller ${CALLERID(all)} has requested address and fax info)
         same => n,Background(faxandaddress) ; Address and fax info
         same => n,Goto(s,menuprompt) ; Take caller back to main menu prompt
         exten => #,1,Verbose(1, Caller ${CALLERID(all)} is entering the directory)
         same => n,Directory(default) ; Send the caller to the directory.
                                                        ; Use InternalSets as the dialing context
         exten => 0,1,Verbose(1, Caller ${CALLERID(all)} is calling the operator)
         same => n,Dial(SIP/operator) ; Operator extension/queue
         exten => i,1,Verbose(1, Caller ${CALLERID(all)} has entered an invalid selection)
         same => n,Playback(invalid)
         same => n,Goto(s,menuprompt)
         exten => t,1,Verbose(1, Caller ${CALLERID(all)} has timed out)
         same => n,Goto(0,1)
                     ; You will want to have a pattern match for the various extensions
                     ; that you’ll allow external callers to dial
                     ; BUT DON’T JUST INCLUDE THE LocalSets CONTEXT
                     ; OR EXTERNAL CALLERS WILL BE ABLE TO MAKE CALLS OUT OF YOUR SYSTEM
                     ; WHATEVER YOU DO HERE, TEST IT CAREFULLY TO ENSURE EXTERNAL CALLERS
                     ; WILL NOT BE ABLE TO DO ANYTHING BUT DIAL INTERNAL EXTENSIONS
       exten => _1XX,1,Verbose(1,Call to an extension starting with ‘1’
       same => n,Goto(InternalSets,${EXTEN},1)

Delivering Incoming Calls to the Auto Attendant

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:
[from-pstn] ; an analog line that has context=from-pstn
                   ; (typically a DAHDI channel)
exten => s,1,Goto(main_menu,s,1)
[incoming] ; a DID coming in on a channel with
                   ; context=incoming (PRI, SIP, or IAX)
exten => 4169671111,1,Goto(main_menu,s,1)
Depending on how you configure your incoming channels, you will generally want to use the Goto() application if you want to send the call to an auto attendant. This is far neater than just coding your whole auto attendant in the incoming context.


“An automated attendant can provide a very useful service to callers. However, if it is not designed and implemented well, it can also be a barrier to your callers that may well drive them away. Take the time to carefully plan out your auto attendant, and keep it simple.”