05-23-2007 04:43 PM - edited 03-14-2019 12:53 AM
Is there an acknowledged best practice, or known pros and cons for scheduling a closed treatment by either:
a. Using an administrative script to modify the value of a Global Variable based on time of day/day of week
b. Using Call Type Manager to change the script associated with a call type based on time of day/day of week
I currently use method a. exclusively, but I can see some decided advantages to scheduling using Call Type Manager.
I have a customer service script which is associated with a number of different call types, associated with different business units, many of which have different hours of operation. Changing the scheduled script using Call Type Manager allows me to keep the script more generic, and not have to check a large number of call types and global variables.
What are the disadvantages/advantages to either of these methods?
05-24-2007 07:37 AM
I typically use method a also. Along those lines I have a scenario now where I need to maintain hours of operation for a UK call center while the system time is Central Time. So I am trying to determine the best way to set the hours in an Admin script and also maintain DST changes 4 times a year. Anyone have any good ideas for that?
05-27-2007 04:10 PM
I use method a. also, but I use heaps of call types for IPCC reporting, so I'm not bothered by having many call types. The Admin script seems tailor-made for this. I also use it to set closure due to holidays or emergency, give special announcements etc. I don't want the admins editing the routing script, but don't have a problem with them changing a dedicated admin script where it's hard to screw up (but not impossible).
I now have a similar situation to dchumbley. ICM in Switzerland, logically independent CVP-based call centres in Europe, the UK, and the USA. I plan to have all the servers/routers on GMT, but still have to deal with DST in local times - holidays and opening hours are going to be tricky.
When this is extended to Asia across the International Date Line, it will be even more bizarre.
I know how to do it - but there may be a really clever trick that I have not thought of. So echoing dchumbley's request for good ideas.
05-27-2007 06:38 PM
I am a fan of option A, basically because I find it hard to track down different schedules across multiple call types.
06-29-2007 02:38 PM
Would you mind sharing a copy of this "administrative script" for scheduling a closed treatment in the event of a holiday or emergency? I have a customer that wants to add this to their main script and was searching around for a sample. Thanks in Advance!
07-03-2007 01:31 PM
I've attached a generic Hours of Operation script that includes a set node to divert calls in case of emergency, several date nodes to handle holidays, and a M-F, Sat, Sun section. You could set the Global variable to 0 for closed, 1 for open, 2 for holiday for example. This would allow you to implement different call treatment for holiday. I generally deploy this script for opening/closing all sites, specific peripherals, business units, etc. Ultimately for whatever logically makes sense. If you create your Global variable before importing the script it makes things a lot easier, ICM will update the variable instances in the script rather than requiring this action be performed manually.
07-03-2007 01:50 PM
Would you mind converting it to an .aef, as I am using IPCC Express CRS Editor..
07-03-2007 08:30 PM
Sorry, this is for use with IPCC Enterprise only. Isn't applicable for Express.
07-06-2007 05:16 AM
I use method A mostly.
With regard to the timezone question I helped develop a solution for a multi time zone customer. The solution we adopted was to give the customers users access to a web front end to enter opening/closing times in local time. The code behind this changed to times to US (New York) time and they were stored in a db. The admin script then ran, pulling data from the db and setting the global variables as required.
Hope this idea helps.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: