Embedded voicemail auto attendant dialing extension directly 3

[calcomp2]

Re: new IP500, 4.1(9), embedded voicemail, incoming calls route to an auto attendant. Extensions are 3xx. VM Pro knowledge but embedded newbie.

During the embedded AA menu options greeting (1 for sales, 2 for support), I'd like the caller to simply be able to reach a known extension at any time (e.g 301) by dialing 301.

As I understand available embedded AA actions, the best I can do is assign action DialByNumber with a blank destination to one of the menu digits (say 3) and include instructions in the greeting like "To reach your party's extension directly, press 3 and then the extension." This requires dialing 3301 during the greeting to reach x301.

Can anyone recommend a solution for simply accepting just an extension in the embedded AA?

Additional notes: there is a ip406v2/vm pro box at headquarters, but neither box has VCM and SCN isn't running. That will probably be the next step. This IP500 box will also migrate to 4-digit extensions (34xx) for corporate compatibility. If I did this extension change now, I could tell callers the new extensions are 34xx, use AA menu option 3 to dial by extension, and use extensions 4xx internally (works but a bit untidy.)

Thank you for any thoughts/assistance.

 

[1043]

I use dial *(star) and the extension number.

 

[jconrad0305]

i use the # followed by the ext.

ACA & ACS IPO Implementation
ACA IP Telephony

 

[techmoderick]

i just did this, and could not get it to work correctly. The only way to get it to work right, is if somehow you managed to set it up where when they press the "3" to dial by extensions, it also starts the dialing of the extension. So essentially, you set up the 3 to dial by extension, but it also begins the dialing process for your 3XX extensions. Like I said, I just did this and could not get it to work correclty with the embedded on a IP500 with 4.1

 

[ZebrAYA]

Couldnt it be at least

use the time-out feature to dial directly by extension?

the prompt would say "for sales press one, support press two, to dial by extension wait for the tone"

[Always Close your threads for avoiding other people to entangle]

 

[jconrad0305]

when you use the inactivity timer the call will follow the fallback desintation in the hunt group so no not really

ACA & ACS IPO Implementation
ACA IP Telephony

 

[ShakinEakin]

We do something similar as Rikybogo. Our extensions are in the 2xx range, and I set option 1 to dial by extension.

We tell people to use x1201 for outside callers (which will dial x201 internally).

Seems to work just fine on a 406v2 and 4.1.

Chris.

 

[ZebrAYA]

Any better news with introduction of 4.2 release?

in 4.1 and 4.2 they talk so much about the Embedded VM card.

[Always Close your threads for avoiding other people to entangle]

 

[mforrence]

We did our first embedded VM w/4.2. The trouble we had (and distributor tech duplicated) was that when you pressed X for Dial By Number function, the AA prompt would begin playing again. You could dial thru the prompt (although it would not stop) and successfully transfer to the desired extension. However, callers would think this a bit weird - we're accustomed to the prompt shutting up when we dial.
Mike

 

[ZebrAYA]

mforrence.

may be could do a trick, save an audio prompt with the invitation to dial, but when 5 seconds (more or less) of recorded silence, that would give the impression and naturality of dialing cutting the prompt.


[Always Close your threads for avoiding other people to entangle]

 

[mforrence]

ZebrAYA - good thought, however when a caller presses the key for Dial By Number (* in my case), the prompt restarts - not just continues. So, I'd have to leave the silence at the beginning...
Mike

 

[ZebrAYA]

Well I got two units ip 500 with embedded card and SCN, what would be best practice to let the callers find the most natural way to dial an inward extension?



[Always Close your threads for avoiding other people to entangle]

 

[jamie77]

Embedded and SCN is a no no!!

You should have got Centalised VM Pro then you wouldn't be having this trouble.

Best practice is VM Pro.

Jamie Green

ACA:Implement - IP Office
ACS:Implement - IP Office

Football is not a matter of life and death-It is far more important!!!!

 

[kholladay]

Extension range 200-220. Use option 2. Create the following short codes

0X DialExtn 20N
1X DialExtn 21N
2X DialExtn 22N

The Embedded VM AA will strip off the 2 but the short codes will put it back on.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me

 

[kholladay]

Nope guess that doesn't work.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me

 

[jamie77]

Embedded won't dial an extn directly, you have to select an AA option first.

If this is a requirement, then you have to fit VM Pro.

You could try fudge this to your hearts content but not get to a decent solution without breaking something else.

You need to use * or # or a number before the extn.

Lets face it, embedded is a cheap VM option and doesn;t set the world alight!!!!

Jamie Green

ACA:Implement - IP Office
ACS:Implement - IP Office

Football is not a matter of life and death-It is far more important!!!!

 

[calcomp2]

I'm sure most will agree embedded voicemail isn't particularly robust. Still, embedded has improved and can actually work well in quite a few situations.

Embedded lacks (at least) two major capabilities: dialing an extension directly, and, a names directory.

Virtually all modern telephony systems include the capability to dial an extension directly from the AA (without a leading digit, # or *.)

To deliver this single feature with IP500 currently requires purchasing an IP500 Professional (from standard) license, VM Pro license, PC hardware, probably Windows Server, then, the ongoing maintenance cost to keep the Pro box running and current (hardware, Windows, and Avaya upgrades.) This is a relatively expensive cost simply to deliver dialing an extension directly when embedded otherwise meets all site needs.

I had hoped Avaya might deliver this feature along with the new features that appeared in 4.0, or a subsequent release.

It seems like adding a new embedded AA action that means "the AA digit pressed is the first digit of my dial plan, transfer when an extension is recognized" is a relatively trivial variation of the current action "DialByNumber".

Please Avaya, kindly add the capability for dialing an extension directly from the embedded voicemail auto-attendant. Requiring the use of VM Pro to deliver this common feature is a big hammer solution.

Note: perhaps you remember if VM Pro needs a Professional IP500 license. My memory hasn't been able to retain the recent spat of licensing changes or the 4.x versions involved.

 

[baldwincl]

I got this to work using multiple AAs
AA1:
1 goto AA2

AA2:
0 goto AA3
1 goto AA4

AA3:
1 transfer to ext 101
2 transfer to ext 102
ect.

works flawlessly.

 

[CarGoSki]

I like that. Star for you.

 

[calcomp2]

To baldwincl - what a simple and creative solution! Star from me too.

To everyone who has participated on this thread looking for a solution to direct dialing of an extension using embedded voicemail auto-attendants, baldwincl's suggestion works well! With some programming effort, you can work around the embedded auto-attendant DialByNumber action and its requirement of a leading digit, * or # to dial an extension directly.

On the IP500 4.1.9 system that I referenced when starting this thread, the extensions are 301 to 324. This is my programming which includes some additional steps to handle callers who make a mistake while dialing an extension.

Main AAOpen: (incoming call route with time profile, call delivered here during working hours)
1 = sales
2 = customer service
3 = transfer to auto-attendant AA3x
.
etc.

AA3x:
0 = transfer to auto-attendant AA30x
1 = transfer to auto-attendant AA31x
2 = transfer to auto-attendant AA32x
3 to 9, * and # = transfer to auto-attendant AAInvalid

AA30x:
0 = transfer to x300
1 = transfer to x301
...
9 = transfer to x309
* and # = transfer to auto-attendant AABadExt

AA31x:
0 = transfer to x310
1 = transfer to x311
...
9 = transfer to x319
* and # = transfer to auto-attendant AABadExt

AA32x:
0 - 4 = transfer to x320 to x324
5 - 9, * and # = transfer to auto-attendant AABadExt

AAInvalid: (for handling 33, 34, ..., 39, 3# and 3* to "eat" the third and last digit of an expected three-digit extension)
all keys = transfer to auto-attendant AABadExt

AABadExt: (for handling any invalid or unused 3xx three-digit extension in your dial plan dialed by the caller)
all keys = transfer back to auto-attendant Main AAOpen

Notes:

This solution is probably superior to the existing embedded voicemail auto-attendant action DialByNumber since there is better handling of extension dialing errors. Before, using DialByNumber, callers accidentally pressing #327 (an invalid extension on my IP500) to direct dial x324 would have an 8 second delay followed by a transfer to the incoming call route fallback extension. On my IP500, and perhaps yours, it's better to tell the caller about the mistake and let them retry.

The auto-attendants have no recordings except for AABadExt which should say something like "Invalid extension entered, please press any key to return to the main menu". Once a caller reaches AABadExt they'll have to press something to go back to a point where they can re-try an extension (see the first caveat about input delays.) An alternative would be to have the recording say “Invalid extension, please try again or press 9 to return the main menu”, and program AABadExt option 3 to transfer to auto-attendant AA3x.

As with DialByNumber, extensions need to be consistent in length. Also, it reduces programming if extensions are within a small range.

Depending on your extension dial plan, it does takes several auto-attendants to accomplish, so baldwincl's solution will generally require 4.0+ since earlier versions will encounter the 4 auto-attendant limit (4.0+ embedded voicemail supports 40 auto-attendants.)

Caveats:

The default embedded timeout for auto-attendants is 8 seconds. If during this auto-attendant daisy-chaining a user pauses for 8+ seconds while dialing an extension, the call will be re-directed to the fallback extension specified on the incoming call route, probably denying the caller another opportunity to dial an extension directly.

There is an added requirement to keep active extensions and these "direct dial" auto-attendants in sync. If for example, ext 321 becomes unused, one needs to remember to change the AA32x auto-attendant key 1 action from transfer x321 to transfer to auto-attendant AABadExt. If the extension dialing plan changes, well, more programming!

There is a lack of flexibility once AABadExt is reached. For example, on my IP500 4.1.9 system, incoming calls are delivered to AAOpen, AAClosed, and AAHoliday using incoming call routing and time profiles. If a user miskeys or enters an invalid extension, you have to pick one auto-attendant to transfer to (after the caller presses any key to acknowledge the invalid extension recording.) In my case, I have to choose AAOpen even though it might be after hours or a holiday. (Anyone: is there a short code that could be used to transfer a call back through an incoming call route group?)

Finally:

Thank you again baldwincl for sharing your solution, and for everyone who contributed. While somewhat cumbersome, for most posters to this thread seeking a solution, there is a method available for direct dialing of an extension using embedded voicemail without using DialByNumber and without breaking anything. Once set up, it works well with a few caveats and doesn't require much ongoing maintenance or attention. No, it’s not VM Pro, but if you don’t need VM Pro for anything else, this is a less expensive solution.

Avaya - a new embedded voicemail auto-attendant action to direct dial an extension (without a leading digit, * or #) is still very much desirable and would certainly be easier to program. It seems like adding a new embedded AA action that means "the AA digit pressed is the first digit of my dial plan, transfer when an extension is recognized" is a relatively trivial variation of DialByNumber.