CUC (6) CUCM (28) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Wednesday, 2 October 2013

ICM/Contact Centre Enterprise Public Holiday checks using Admin Scripts

A vital part of any contact Center  is a check that ascertains if today is a public holiday, Saturday or Sunday, or if the call comes in during or outside opening hours (OH). This will determine if a message is being played out to a caller, the caller gets direct to voice mail, or if a call is directed to an available agent etcetera, etcetera. UCCE does this by means of admin scripts.

Admin scripts are scripts that do not deal with call routing. Their purpose is do do a check, follow logic and set the value. This valuable can later be used in a routing script that, where an IF node can make a decision based on that same value.

You will notice a brief explanation when you create a new script:

For example, let say its January 1st, an admin script checks if today is New Years day (or any other public holiday for that matter). If it is, the logic branches off and sets the Global.object. "user_Sys_PH_CC_", to a value of "1". After this, in your actual Routing Script, this value can be used to play the Bank Holiday greeting through the prompt of an IPIVR. These admin scripts typically run once every minute to check Time of day (TOD) and once a day, to check a date. 

Figure 1 shows an example of a New year's Day (1/1) check (note the syntax of the IF condition, on the right of the picture).

Figure 1 - Public Holiday Check example

Of course the routing script is sequential and after a new years day check, the next check, for example Easter can be done until all public holidays are done for that year, followed by the next public holiday etc etc.  At the end, if it has not found a public holiday to match, set your variable to 0 (i.e. "off").
This approach would mean that every year this admin script would need to be updated to change the dates of some of the public holidays). So really all these admin scripts are good for is setting variables based on time of day, day of week or certain date (public holiday).  These admin scripts are run  every minute to check the time of day, and every day to check the day. If a change in either date or time has been  identified, the script will change the appropriate call variable. If a new call comes in that does a check on the changed variable, it will obviously invoke a new branch of the script and will play for instance an out of hours message. So really any TOD checking is done in parrallel to the non-Admin scripts. This mechanism is different from UCCX where TOD checks are normally part of the same aef script as the one where all the other call routing logic is done. 

So lets take the example in figure 1 to the next level. In this example following variable was set:

Global.user_SYS_PH_CC_All="2" , which forms the start of the script in Fig.2.

Figure 2 - Example - reduced opening hours because of public holiday

Figure two is an example of a scenario where an organisation might have reduced opening hours on a bank holiday, saturday, sunday. This sort of time of day checking, can go on an on, but I think I have made my point. Also in this example the check is done for 4 states; NSW, VIC, TAS and ACT, because these are in the same timezone, so a similar check will need to be carried out for WA, QLD and NT.

Australia is a mess in that respect, spanning 3 different time zones, various states with various sets of Public Holidays, some doing daylight savings, some don't.  This is where I will conclude this post, I just wanted to share a brief over view of what admin scripts can do and what the options are, illustrated by some examples.

Another plain example is the date and following TOD check, in Figure 3

Figure 3 - Data and Time of day check
As with any script, you will have to follow the bouncing ball. So in Figure 3, a day of the week check is done.

Fig. 4. Day of week check
Figure 4 shows 3 scenario's; open mon-friday, sunday or monday. These each have their own variable set, for instance X, Y, Z respectively. So this is why the day of week check in Figure 3, branches off in 3 possible option. Under neath it, these three each have their own TOD check(Fig.3.)

Figure 5, shows the 3 TOD options.

Fig. 5 Time of Day (TOD) check

In essence you can have a multitude of non-conflicting admin scripts active the the same time, all setting their own separate variables, which in turn are used to make Call routing decisions in separate script. This is OK as long as the variables that are used in the various admin scripts are UNIQUE.

mucho suerte!  ( I am starting to sound like Dora the explorer; admin script, routing script, service queueeeeeee!!!!)