I am looking for some information as to how other companies handle CTI Failures and possible Scripting Exceptions being thrown within call flows. Our business requires 24/7 365 support availability by phone in our support center, for several departments. Part of our initial requirements laid out before getting cisco was always delivering the phone call from a customer to an agent even if a system issue was present.
A solution was tailored to meet these requirements by the vendor who did our implementation, and was approved via a cisco health check done by Engineers from RTP.
The basic theory of this solution was anytime a failure occured on the CTI side of things (CM, etc) that call would be routed via hunt group configuration to an agents phone on their line 2 (personal extension, which isn't associated in UCCX). Also if a scripting exception was thrown that would other wise stop kill the call, the script would follow the default script which also routed to a hunt group trigger which would end up going to agent phones on line 2.
The problem for us is we have had a number of issues this year and most of our TAC cases were halted due to "unsupported configuration" due to hunt groups being tied to an agent phone. We are basically at a crossroads now, needing to come up with another solution that satisfies our requirements and our customers; even though our initial setup was approved by Cisco and setup by a cisco vendor. Sorry for the rant....but my real intent here is to find out what others are using to deal with CTI Failures and Scripting exceptions.
Are other companies really just routing the calls to a voice mailbox or playing an error message for the customer and then dropping the call? Surely there is a solution out there that can still deliver the call to an agent.
Does the Enterprise version offer any features that express doesnt' have that could help in this situation? Are there any better options for Express that doesn't end in routing the call to an error message or a mailbox?
Any advice or input is appreciated!
Using UCCE and CVP, there is some flexibility for failure scenarios (and they should all be Cisco-supported), in addition to the resiliancy provided by a duplexed server environment...
All that said... I rarely see Default Labels happen, as that only really takes effect if ICM doesn't come up with a destination before the routing client (Call Manager or CVP) times out. SRST mode occurs more if you've got an unreliable connection between your UCCE cluster and a remote site. RONAs are definitely the most common thing I see, and I'm glad to have the control to do something about them.
Thanks for the reply Jameson!
Does anyone else have any advice on this situation as to how it may relate to UCCX? We haven't been able to come up with a solution that satisfies our management team as per their original requirements. I doubt they are going to spend additional money for UCCE when our environment doesn't really call for that big of a setup. I'm not sure if SRST fits with our setup. We have an HA server in a remote location, but no ip phones setup there. It's simply our backup for a failover situation if our Publisher(primary) server goes down.
I still need to take some classes on Call Manager as my knowledge base isn't high with that side of Cisco yet. Sorry if i'm not understanding some of the concepts.
If there is an issue with the config - there will be CVP or ICM message played out accordingly saying sorry but cant connect your call at this time or something - so assuming config is good:
On the ICM scripts I normally point the Wrong arms of all nodes like Run Ext Script or Send to VRU or CED or Q to SG to a Set failure text variable and then Go to a different script - in this new script I check if failure text variable = Helpdesk script or its = CreditCards script for e.g. and Handle it accordingly from there i.e. send it to Heldesk hunt group or CreditCards hunutgroup or a Generic skill group.
The above will handle scnarios like when VRU PG or Agent PG is down
I`ve used call forward no reply , not registered to hunt groups all on CTI RP particular on Switchboards so in one way I`m surprise but in another not specially when TAC are involved. Is the issue that the non-ACD DN is on a ACD phone? You could set up a CTI RP forward to a hunt group as you do now but maybe deploy IP Communicator to to remove the non ACD on the phone?
Correct, they have stated that no line on an ACD phone can be in a hunt list. Even though only the first line is associated to UCCX as the agent extension.
Originally we were led to believe that the 2nd line could work since it was just their personal line, but apparently not. Don't get me wrong, the solution itself does work as designed, however we have run into some other issues that our cases have been halted due to our hunt group configuration - whether or not the configuration is the root cause of the issues I find it hard to believe. (For example, we have had intermittent issues with agents getting put into Ready state after a call instead of Work State. - all settings are correct in uccx. I find it hard to believe this is hunt group related, but the case was stopped due to our hunt group config.)
We had thought about using the IP Communicator but didn't seem like a realistic option to expect our agents to all be logged into 2 separate devices with 2 different logins. I'm also not sure if that would be a valid configuration. Has anyone actually tried something like this?
It sounds like the only option with UCCX is to have any CTI failures or scripting exceptions that are thrown to be directed to a group voicemail - and we could configure the unity email notification to notify on a voicemail being left.
I don't think our management will be content with this solution, but we need to do something to have our TAC cases addressed.
you don't need oto have a separate log for IPC, Just configure with any number which has been assigned to the hunt group. Configure so it is "goes to front" when an active call is ringing the IPC, with the DN being configured to the IPC no need to log on . Configure the DN Partition so no one call it expect via the hunt group, configure the hunt grp so no one can call it either. The combination of the above means that the "thing' to call the IPC is the hunt grp and the only time the hunt calls it is if the CTI RP fails. Also configure the IPC so it starts with windows- all should automatic to the agent?
Just to clarify: the issue that TAC has is with the HUNT GROUP not UCCX, right !?! Recalling from memory you cant have a HUNT GROUP on a ICPP phone??? Remove the Hunt group, and just do a shared line appearance accross a group of phones.
Verify this with TAC
Something that you could do from reading your post. I might think of doing a secondary script, if the Primary script fails, fail over to a secondary BASIC no thrills script - stating "We are in maintenance mode, working on upgrading your calling experience, please make a choice from the abrivated menu........."
Leaving your agents working as they should on the IPCC extension.
What version of UCCX are you on?
Thanks for the additional replies.
We are on UCCX 8.5 (su2). TAC states that NO line on the phones can be apart of a hunt group list.
From the scripting aspect, we do have "default" scripts setup but we aren't doing basic handling within the default scripts. We are also routing to the hunt group pilots using a call redirect inside the default script.
We know we can use alternative solutions to deal with the failures like just giving them a basic menu, or giving them an error message, or even routing to a voicemail. That would not meet our original spec requirements though, which stated we wanted a caller to always get through to an agent if any error occured with the phone system, whether it be scripting issue or CTI failure.
Can you elaborate a little bit on the shared line appearance? From my understanding this would probably accomplish the samething as our hunt group setup, but wonder if it would be approved by TAC.
So if i were to setup a shared line appearance by assigning the DN 9000 to every phone in a department, and then in default script for that department i could redirect to 9000 if there were an exception thrown that would kill the call. It doesn't sound like it's possible to have them ring in sequence like hunt group allows? From my understanding all devices sharing this DN would ring at once.
Thanks again for the input,
Yes all phones would ring at once for that number. You could also Ring a group of phones, Then if those phones are busy ring another group of phones. If it were me, and I had 100 agents make 10 groups of 10.
Make sure that you have modified the allowed amount of calls by each phone number to be just 10 then role to the next phone group. (your own self made hunt group????)
remember it just needs to be functional when your IVR is down, it doesnt need to be pretty......