Symposium, CallPilot and Redundancy 1

[81Cadmin]

CP 4.0; Succession 3.0; Symposium 5.0

I looking for insight on best practice to program some level of redundancy into my call centre applications (CP/Symposium).

I have a call centre menu which enters on CallPilot first (phantom ACD). After the caller makes their selections from the menu the call is then offered to Symposium and treated. As long as CallPilot is running, then the call is picked up by the CP Menu Service. However should CallPilot be down then I don't believe the call would be picked up at all. If CallPilot is running and Symposium is down the call would revert based on DFDN configured for the Symposium CDN.

Is there a way for the PBX to offer the call elsewhere should CallPilot be down? I find it odd that Nortel has built a single point of failure on such a business critical application.

Since I also have Symposium, should I even be offering the call to CallPilot first? Are there any benefits (other than reporting) in offering the call first to Symposium then passing it to the CP menu?

What I'm hoping to do if create logic that would route the call directly to a determined Symposium or basic ACD queue should either be down.

Thanks in advance for your comments and suggestions.

 

[pronei]

If the pilot does actually die, which is very rare, you'll most likely only need to modify IDC tables to send the DNIS directly to the corresponding Symposium CDN.

As for front ending your calls, CP is very useful if you plan on several layers of menus with different recordings.

However, You can script the same in symposium, but your voice recordings will still most likely rely on the CallPilots Voice Access & IVR Ports, unless you have several RANs/MIRANs available.

 

[81Cadmin]

So from what I understand there is no 'automatic' revert that can be programmed, it will always require user intervention to redirect the CDN to an alternate ACD/CDN?

Thanks...

 

[BkMesser]

You could program the acdn or cdn of the symposiom queue as the dfdn on the main call pilot cdn.

If call pilot went down all of the calls to voice mail would go to that dfdn.

A lot of alphabet soup there...

 

[Milesprower]

I prefer the setup you have: upfront menus on Call Pilot. You have laid out the issues succinctly in your post.

As menus run by SCCS scripting require both Call Pilot and SCCS to be up (and synchronized), it is less reliable than putting the menus on Call Pilot.

There are indications that Call Pilot High Availability will some day work in a call center environment. That would give you additional backup in case of a Call Pilot failure.

 

[Utreg]

I use Symposium scripting only (Call Pilot is 'just for playing messages'). Since our access link had some troubles I implemented the following scripting:

/* First command in script */
EVENT HANDLER
EVENT IVR RESPONSE FAIL: EXECUTE RouteTo_IVR_Down
EVENT BROADCAST ANNOUNCEMENT RESPONSE FAIL: EXECUTE RouteTo_Broadcast_Down
END HANDLER
Open Voice Session ACC_DN
Play Prompt Voice Segment ShortSilenceToTestAccesLink_txt
End Voice Session


/* Anywhere in script */
SECTION RouteTo_Broadcast_Down
Give IVR IVR_DN with treatment Problem_txt
ROUTE CALL CP_Broadcastdown_DN

SECTION RouteTo_IVR_Down
ROUTE CALL CP_All_Down_DN

Works fine; if Call Pilot has a failure alternative routing becomes active.

 

[81Cadmin]

Utreg, this is something i haven't seen before but potentially a solution that I would like to implement.

I will program some tests script and let you know the results. I may need more info on your setup at some point.

Thanks again (all).

 

[Utreg]

My scripting is done on a CC6 and CP5 site where they use IVR and Access announcements.
I also implemented it on a Symposium 4 with CP4 site where they use Access announcements only (scripting is the same just dont implement the IVR event test and routing).
Testing is easy; just shutdown CallPilot (outside office hours ;-) and dial test number..

 

[Milesprower]

The Event Handler can provide a backup capability in very narrowly defined situations. It is a powerful tool when properly configured.

It does keep a process running in the background and will take up more system resources. In most call centers (except those that are extremely busy), this should not be a concern with today's high powered servers.

 

[Pir8Radio]

the way i do it here is, all of my skillsets are based on DNIS or CLID and not CDN. so we have group 1 that handels all the money calls from all of our offices across the US. group 2 takes all of the complaints. so what you do is make an acd group in the switch and give it a dn of say 3333 for group 1 and build annother 4444 for group 2. Then build group 1 and group 2 as CDN's in symposium 3333 and 4444. Now set up all of your DNIS and CLID routing to skillsets. set up all of you agents who will be dealing with money or group 1 calls so that key 0 is 3333 acd group. as for your announcements you can make your fist wait on the skillsets your (press one for money press two for complaints.)

sounds messy so far hu? But what this does is if call pilot fails, they are already in a skillset group that sort of expects this type of call, as well as if symposium fails all of the agents can still login under the default switch ACD 3333 and 4444, so they will still get the calls for money or complaints.

Makes sense in my head, i probably confused the hell out of everyone else. Uhm wait im confused too..

 

[81Cadmin]

No you didn't confuse me, it's pretty much what I am already doing.

I had an outage of CallPilot last Friday where I lost a raid channel (I think I may be clairvoyant - LOL). The way I currently have things setup is to first accept the call in Symposium, then route to CallPilot. If Symposium can't hand the call off to callpilot the call reverts to the DCFW of the ACD queue. This worked well during the outage but I didn't have any RAN announcements so callers didn't get any greeting. I installed a RAN this week, so that problem is now solved.

The intent of my original question was to see if I could automate a failover in the event of a CP or Symposium failure. The answer so far is no, at some point a failure may require manual intervention to rebound calls.