Unity 3.1(5) # caller input vs. 4.02

[jtvedte]

Q: Users are pressing # when accessing vm - then pressing 0 to reach the operator - which results in being routed to the general operator.

With multiple directory handlers in Unity 4.x, is this a problem that is "solved"?

i.e. Clients inbound calls to a specific site ALWAYS stay at that "local" site, regardless of key input.....

[lindborg]

Are you talking about users exiting off the directory handlers specifically? In 4.0(1) and later there are 4 exit destinations you can define - if they don't input anything, if they input * or #, they input 0 or if they spell a name and then don't pick one from the resulting list.

unfortunately the SA only exposes one - that's the destination where they are sent if the user presses * or # which defaults to the opening greeting. I've updated the Audio Text Manager to expose all 4 of these exit destinations last week and QA finished testing it and I was going to post it to CiscoUnityTools.com a little later today (if you need it pronto, email me at lindborg@cisco.com and I can shoot you a copy).

also in 4.0(1) and later you can have as many directory handlers as you want so you can have a seperate one (or ones) for each site which may be what you want to do here such that folks exiting from the directory handler are sent to the appropriate "area operator" or whatever it is you have configured.

If that's not what you're wanting to do, let me know what it is you're shooting for and we'll see what can be done.

[jtvedte]

I am talking about users connecting to a vm subscriber mailbox.

Let's use the following as an example:

Art at ext. 2530 calls Mark at ext. 3801, but Mark's ext. is "busy" so forward busy to Unity. Art leaves a msg. and when the Unity lady in the box prompts, 1 to send, 3 to review, etc. Art presses #. The msg. is sent to Mark's mailbox and Unity lady in the box prompts Art to enter an ext. Art then presses 0. This results in a transfer to the "main operator".

Art expects to be transfered to the "branch operator" - let's say branch C. But is sent to the main operator instead. This causes headaches.....

[lindborg]

Well, that's something you can work with now, no need to get 4.0(2) since there are no changes in this behavior there. This actually has nothing to do with the subscriber conversation at all, it's just straight up call routing stuff you can fiddle with.

The after message action on Art is set by default to go to the "say goodbye" call handler - the say goodbye call handler has it's "0" key mapped to the defualt "operator" call handler created by setup. You can map all your users in each area to a different after message call handler (i.e. copies of the say goodbye call handler with different 0 key mappings to go to different operator call handlers).

You can use BulkEdit to change the after message actions on subscribers in batch - if you have them defined by membership in a public DL or a COS or an extension range or something here you can pound through such changes in a jiffy. Just create the equivalent of a "say goodbye" call handler and an "operator" call handler for each branch and then update users in each branch to send callers to the right place for the after message action.

4.0(x) certainly gives you more options here with name lookup handlers and a definable subscriber exit destination (i.e. where subscribers go when they bail out of checking their messages) etc... but for what you describe you can do it with 3.1(5).

You may find the "Audio Text Applications in Unity" doc on the Documents page of www.CiscoUnityTools.com helpful here. It actually covers "poor man's tenant service" options in Unity 4.0(1) but much of it is applicable to 3.1(x) as well.

[jtvedte]

So modify the after message action....(in the take a message area) - to use a "custom" call handler per branch?

The after greeting is set to "take a message" -

[lindborg]

yeah, it's the after message action you want to modify here (i.e. where we send the call after the caller has finished recording and/or editing their message).

[jtvedte]

Great - We'll get to work.

[anupamav]

Hi

I have the exact problem with the voicemails from remote sites hitting the main operator.I created a customised "say goodbye" handler for one of the branches but not able to change the after message action for the subscribers.Unity does not allow me to save it.It reverts back to the old one when I try and save it.Is it something that I am overlooking?

Thanks

Anupama

[lindborg]

If it's reverting back on you, that sounds like a bug - you should probably open a TAC case.

In the meantime you can try and use BulkEdit to edit the subcribers/handlers in question or use the Audio Text Manager (you can get the updated version of both off www.CiscoUnityTools.com).

[anupamav]

Thanks for the information.That worked.But there are some calls that ring at the main office operator's phone but when she picks it up,she hears the user's voice mail greeting.Is this a bug or Can we change it somewhere.

Thanks again

Anu

[anupamav]

Hi

Changing the Goodbye handler helped for the "#" for skipping greeting and hitting "0" for the operator.But if a caller presses * by mistake,it takes them to sign-in of the user but when they try to get out of it and press 0,it goes to the main site operator.Can we change this.

Thanks

[lindborg]

No, from the sign in conversation hitting # will always take you to the main opening greeting created by setup - you can't configure that to behave differently I'm afraid.

[anupamav]

Ok.But sometimes it is not a caller who reaches the main site operator,the voice mail greeting of the remote site user that she hears when she answers a call.Is this a totally different problem.

Thanks a ton

Anu