Design Question

[admin_2]

In all the documentation I have on Unity, I haven't seen anything that indicates the standard for directing incoming calls on a gateway. Would I configure the gateway to direct incoming calls to an attendant DN (or Web Attendant Hunt group)? Or would I configure the gateway to direct incoming calls directly to a Unity VM port?<br><br>I've been working with two designs on our demo system. One where the incoming call is directed to a single extension (an attendant). This would be in a scenario where a live person answers calls during the day. After hours (or when the attendant takes breaks) the phone is manually forwarded to a Unity VM port and Unity plays the appropriate greeting based on the schedule. I've also used Web Attendant Hunt Groups - where as long as someone in the hunt group is logged in the call is routed to an attendant. If everyone in the hunt group were to log out (or be at capacity, or unavailable, etc.) the last member of the Hunt group is Unity.<br><br>I guess what I'm asking is - is this considered standard? Or would I configure the gateway to direct incoming calls directly to Unity, and, based on the Unity schedule, allow it to direct calls back to the Cisco Call Manager, or to a Unity greeting/Call Handler?<br><br>Now for the last scenario I'm considering... If I have a client that always wants the automated attendant (Opening Greeting) would I (again) configure the gateway to point directly to a Unity VM port?<br><br><br><br>Brian Carscadden<br>Sr. System Engineer<br>CCNA, CCDA, CIPT, MCP<br>TransNet Corporation<br>908 253-0500

[#2]

If you want to use auto attendant (i.e. Unity is answering incoming calls) I would think you’d want your calls to go right to the uOne line hunt group head and have it snag the first available in the hunt group and have it spill over to an operator console or something along those lines.

We have not tested the Web Attendant stuff with 3.0(8) however when we looked at it in 3.0(7) it caused some problems with transfers… I would avoid that with Unity for now. The application sounds interesting but we’ll need some time to iron out the kinks. I’d play it safe and go direct.


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

[#3]

So is the rule of thumb...

If a Live person answers calls: Point the gateway to the attendant's DN. After hours the attendant does a forward-all to the Uone Port (unity hunt group)?

If auto-attendant answers all the time: Point the gateway directly to the UOne Port (unity hunt group)?

OR

Would you always point the gateway to the UOne port (Unity) and let Unity route calls based on the schedule? And is there more overhead in doing it this way.

Cisco's Web attendant has been a hot item with our customers and they're planning on us to implement it with Unity.

Any additional guidance would be greatly appreciated.

Brian Carscadden
Sr. System Engineer
CCNA, CCDA, CIPT, MCP
TransNet Corporation
908 253-0500

[#4]

Yeah, the integrations group has the web attendant on it's list of stuff to get tested with the help of the CM test group. We'll get it ironed out in short order I'm sure... it's a pretty cool looking feature.

In general having Unity answer all incoming calls during the day is fine if you want folks to "0 out" to the operator. If you want us to simply turn around and bounce the call right to an operator without "talking" to the incoming caller I don't think that's your best bet (I think this is what you had in mind). Folks using auto attendant usually have Unity answer all incoming calls and let folks decide if they want to try an extension, navigate some audio text options (i.e. directions to the building, get to tech support etc...) or time out/0 out to an operator.

If you're looking to have a haman interface on all incoming calls during the day, I would definitely have the switch stack up the calls for the operator(s) rather than having Unity field them and bounce them back based on schedule. the caller experience there could be odd if you're not real careful (i.e. they'd hear dead air for a period of time).

One thing to look out for when you forward the operator extension(s) to Unity after hours... make sure the ID of the operator number(s) do not correspond to any mail user or call handler IDs in Unity. All calls will be presented as forwarded from extension X in this scenario. We will lookup X and if a match is found, route the caller to that greeting instead of the opening greeting. You can work around this with fancy routing rules up front but in general it's better to avoid it entirely.


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