Centralized Call Processing design/Operator handle

[sdennis]

We are implementing a Centralized Call Processing design with Unity for a customer and we are having a big problem with calls coming into each remote sites AutoAttendant call handler and ending up at HQ site operator when pressing "0" (currently operator handler). Each site AA call handler has "0" pointed to the site's custom Operator handler. This works fine, however, there are holes where callers end up at the default operator handler. We have a bunch of subscribers where the caller input does not have the ignore keys locked and so could possibly end up at the Opening Greeting there ("invalid key") and press "0". We also may be encountering CSCae03157 where "Ignore key" caller input not truely ignored. The newest one is that there does not appear to be a way to do anything with "0" pressed while in directory handler. It always goes to default operator handler. We are going to try and work around this by changing AA greeting to add "to get to corporate directory, press #, to exit directory and return to operator, press "#" followed by "0". Customer still wants directory handler "0" to be site specific or return to calling handler like the "#" key does. Can this be remapped in DOH? The same applies to the Opening Greeting handler. Also, if anyone knows of any other instances that need to be plugged to keep callers at a specific remote site prompts, it would be appreciated. Note that customer does not want to just lose calls by making the Operator handler just play greeting and say goodbye. Any suggestions?<br><br><br><br>

[#2]

Unity doesn't really have true multi-tenant services, and there are going to be a few areas where the operator transfers are tricky. The directory is probably the biggest grey area in terms of sharing the system -- there is only 1 spell by name directory handler, and therefore only 1 exit path from that handler. You're going to have to just pick a greeting handler or operator on the Caller Input page. Make sure to request multiple directory handlers in Unity as a feature next time you talk to your account team.

As far as controlling where the caller gets sent on invalid input from the auto-attendant, that's not something that can be configured from the 2.4.x Admin pages, but Jeff does have a utility that allows you to adjust this. It's called the Bulk Edit Utility, available at www.answermonkey.net. You can select the site's call handler and modify the after greeting destination for the 'Error Greeting' so that it points back to the site's handler instead of the default box. It's much safer than trying to hack this in the DOH.

Good Luck,
Scott Morgan
Cisco Systems

[sdennis]

For the first paragraph, yes, I understand all of this concerning directory handler. Of course that is not stopping us from selling it in a centralized call processing environment :( Also, the "If caller exits, sent to:" under caller input is not the problem (well maybe a little), it's the things such as "0" which are not listed in the directory handler caller input screen but still do things. I'll play with Bulk Edit but we may have to open a case and get some definite things worked out about this.

[#4]

By default, 0 is the defined extension for the Operator Handler. So if you don't have Caller Input defined for zero in a particular handler, it's going to follow the programming of whatever handler you have defined as extension 0.

[#5]

I also have the same problem at a customer site.
The bulk utility may solve my issue of an incorrect
extension being selected, but can it solve their
other issue: "when users at SiteB (remote) hit *
to get out of VM - they go to the SiteA call handler".
Where do we define where users go when they * out of
VoiceMail?

[#6]

This is one of the many reasons we've stated out here repeatedly that Unity is not configured for a tenant services setup... there is no way to dictate where callers go when they back out of the subscriber conversation, this is hard coded to go to the opening greeting call handler created by setup, end of story.

You can dictate where callers go when they fat-finger an option using the error greeting (you can get at this with bulk edit) but subscribers backing out of their conversation and into auto attendnat land is hard coded.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#7]

That's the odd thing....we would be happy if an error
or someone hitting "*" in VM went to either the Opening
or Operator greetings....but it goes to a
specific greeting that we set up for another site.

[#8]

Hmmm.... I SHOULD be handing the call back to the arbiter (the guy that does the routing rules evaluations) and passing in information that will cause it to fall through to the backstop rule which is the opening greeting (i.e. is fires up the PHGreeting conversation and passes in the handler with an alias of "OpeningGreetingCH" as a destination). You may have a rule that's firing further upstream and over riding this...

You can use the StatusMonitor.exe (found under \commserver\TechTools) to see what's happening to the call routing-wise when you bail out of the subscriber's message box using *. My best guess is you have a routing rule that's triggering and over riding the opening greeting route. I'm not entirely sure why that would be happening but I can dig around further to see what happens here.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)