I have 3 legacy call centers that I'm trying to collapse into an existing 4th IPCC Express Call Center.
Each of these legacy call center managers want to retain their existing phone numbers.
How can I identify the dialed number and use that logic to place the contact into the correct CSQ in my existing IPCC script?
Or should I create 3 new IPCC scripts and somehow use a subflow to take the contact to the existing IPCC?
Any help would be greatly appreciated!
Are those for the same customer? It might be a good idea to sell an enterprise and use the parent child PG to distribute the calls and interconnect the centers.
Yes - I work for a hospital and I'm basically migrating all legacy call centers to IPCC Express.
This is for our new centralized scheduling call center. The legacy model has a bunch of independant Siemens ACD based Call Centers and I'm trying to roll them up into a bright, shiny new IPCC Express Call center.
But our call center manager doesn't want to lose all the public awareness of the various DID phone numbers associated with the legacy call centers.
Hopefully that clears it up.
the only official way to interconnect them that I could think of is to deploy an IPCC Enterprise, the DNIS would be preserved and the internal configuration and scripts too, you will only gain the possibility to overflow, interconnect and have them act all together like a super ACD.
Which is quite something and gain also some more general reporting capabalities.
Are you attempting to keep the three Siemens ACD systems in place or transition the agents to UCCX?
If you want to keep the legacy ACD systems, you'll need to discuss ICM or UCCE to interconnect and distribute calls across the systems as Riccardo is referencing.
If you want to transition these other call center groups on to UCCX, then you can transition the DIDs or DNIS numbers to a gateway connected to UCM. If they don't match your internal dial plan, you can use a translation pattern to translate to the JTAPI triggers.
After that, it depends if you want to accomplish this within a single script or break it up.
With a single script you have the Get Call Contact Info and the Match steps. Using these, you can determine what trigger [number] the call arrived on and change the logic of the script using the Match statement. Otherwise you can break the triggers across independent applications and keep the logic completely separate.
UCCE could be used to interconnect the UCCX systems by the mean of a parent and several childs, allowing a better allocation of calls based on the available resources, offering major scalability.
I sincerely appreciate the response. I'm a wireless and security engineer primarily and am very new to IPCC and have no formal training and without TAC support, the scripting is certainly a challenge.
I also find that there are very few Internet script hits other than 300 page reference Cisco documents.
I'm transitioning all Siemens ACD systems to Cisco UCCX. The DID numbers all fit within my Cisco dial plan. No issues there.
I'm looking for the cleanest way to handle these new UCCX call centers and really don't have the expertise to suggest using separate scripts or running them all under 1 script.
My novice approach was to build small scripts to handle the transitioned call centers and then port them to 1 main script via the sub-flow process.
My main script would be something like this -
To schedule a:
1. Radiology appointment press 1
2. Cardiology appointment press 2
3. Pediatric appointment press 3
4. Transitioned legacy call center press 4
5. Transitioned legacy call center press 5
Then my new short scripts to handle the legacy call centers would be something like this:
To schedule a procedure, press 1 (then this script would take the caller to item 4 in the main script above)
I hope my explanation was clear. Also, I'm looking for consulting resources to pay that would be able to assist in such scripting issues. If you are interested, please contact me at 719 365 1741.
I'm transitioning these legacy call centers to UCCX. Are you suggesting that in order to retain the original call center DNIS numbers, I need to utilize UCCE?
no I am saying that if you want to overflow calls from one center to another knowing the agent status and use all those resources as one large site than you would need to deploy UCCE.
I would love to help you out if you have a visio call flow for all 3 call flows I can guide you. UCCX can do good amount of what you are trying. You are better of with 3 scripts load them on 3 routepoints or jtapi and can send them all to same endpoint or agent group but they all had different greetings etc.
You can have one script as well but it gets more complicated so start with 3 seperate.
Attached downlowad the CRS guide or you can even do F1 from CRS editor that will guide you fairly.
Good luck and salam,
Thank you very much for your response! I'm attaching a Visio.
Currently, my Main Scheduling Script contains a primary prompt that announces every available menu option 1 thru 8.
For example, "Press 1 if you would like to schedule a Cardiology appointment" etc.
I'll create 3 new IPCC Express scripts for my legacy call centers. I will retain their well known DID numbers so our patients will continue to call the same numbers when the need to schedule an appointment.
Example 1 - when a patient calls legacy call center 1 to schedule a Disease and Wellness appointment, I want the legacy call center 1 script to take the call to the "Desease and Wellness" prompt of the Main Scheduling Script.
Example 2 - when a patient calls legacy call center 2 to schedule a Maternal Fetal Medicine appointment, I want the legacy call center 2 script to take the call to the "Maternal Fetal Medicine" prompt of the Main Scheduling Script.
Example 3 - when a patient calls legacy call center 3 to schedule a Radiology appointment, I want the legacy call center 3 script to take the call to the "Radiology" prompt of the Main Scheduling Script.
Basically I'm trying to avoid making patients listen to the prompt for the first script and then forcing them to listen the Main Scheduling Script prompt.
Does that make sense?