Creating Centralized Scheduling CCX Script

[asafayan1]

We run CCX 11.x.  We have numerous medical departments that are currently handling their own scheduling.  My goal it to have a small group of staff dedicated to centralized scheduling and the cut departments over one by one to the new Centralized Scheduling CSQ. 

Take Internal Medicine for example - the current script will be modified to provide an menu option "Press 3 to schedule an appointment" and I will use the call redirect to route the calling party to the Centralized Scheduling trigger which will route the call to the Centralized Scheduling agents.

My question is - if I have one department and I cut them over - the Centralized Scheduling agents know the call is coming from the Internal Medicine department - but  when I start to scale this and have cut over a bunch of departments - how will the Centralized Scheduling agents know which department the call is coming from?

TIA,

Amir

[Anthony Holloway · Accepted solution]

There is a feature of Finesse which allows you to present data to the Agent at the time of the call ringing. This data is called Call Variables, and is controlled by the Finesse Administration Call Variable Layouts.

Here's the section of the Admin Guide on the topic:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_6_2/maintain_and_operate/guide/uccx_b_ccx-admin-and-operations-guide/uccx_b_ccx-admin-and-operations-guide_chapter_010111.html#CFIN_TP_MD4E76AF_00

At a high level, it works like this:

1) When the caller calls your department, like Internal Medicine, and choosing the scheduling option, you would use the Set Enterprise Info step to store a value like "Internal Medicine Scheduling" in a field like "user.call_type".

2) In Finesse Administration, you can use the default layout, to add "user.call_type" to the layout, so that when the Agent sees the call come in, they see "Internal Medicine Scheduling".

Note that there is a difference between storing the value in "user.call_type", which you wont be able to see in any historical reports, and using --Call.PreripheralVariable1--, which would be recorded for historical reporting purposes. Which you choose is up to whether or not you need to report on that data later or not. However, from a display to your Agent point of view, there is no difference.

[asafayan1]

Hi Anthony,

It worked - the problem is I don't understand how......... : (

My first script is the departmental level script which provides callers with a series of menu options - one of which is "To schedule a call, press 1".  With that selection, I use the call redirect step to send the call to the trigger of the second script which is the default "Simple Queuing Template" with a couple of centralized scheduling agents / resources.

Here is the screen shot of the Set Enterprise Call Info object in my first (departmental level) script:

Here is second script which is called from Call Redirect step above:

Here is a screenshot of my default Call Variable Layout:

When making a test call into the Endocrinology department script, my finesse agent is presented with "Endo":

What I don't understand is how the value of "Endo", which exists in my first script as a variable named "Department" - is presenting to the Finesse client.  It appears to be as follows:

1. First script creates variable named "Department" with value "Endo"
2. First script uses Set Enterprise Call Info object with --Call.PeripheralVariable1-- value set to "Department"

3. First script calls second script 

4. Second script sends call to CSQ which delivers call to Finesse agent

5. Finesse presents default Call Variable Layout to agent which contains the callVariable1 Call  Header Layout

What is fuzzy to me is how "Endo" is glued from step 1 to step 2 and how this value of "Endo" is passed from Script 1 to Script 2 and eventually presented to the Finesse agent. 

[Anthony Holloway · Accepted solution]

I don't know why, but I find your confusion to be endearing. :)

Ok, so think about it like this. A caller who calls into UCCX can have data "attached" to them, and it remain attached to them, for so long as they never leave UCCX. By leave UCCX, I simply mean, get transferred out to something other than a UCCX Trigger or UCCX Agent. If you keep the call within UCCX, that data attached to the caller, will persist for the duration of the call. We call this Enterprise Data.

Contrast that with data you want to attach to a caller, which persists after leaving UCCX, which we call Session Data.

[asafayan1]

Got it!  The glue is that it is attached to the caller and the caller never left UCCX.  Thank you sir!

[Anthony Holloway]

Exactly! You're welcome.