Question
US Bank
US
Last activity: 3 Jan 2017 10:30 EST
"Get Next Case" optimized for time zones
I have a call center that makes calls on accounts from 7AM to 11PM CT. The customers live in many time zones and can only be contacted between 8AM and 9PM local time. Ex: Customer in ET, can be called between 7AM and 8PM CT. Customer in PT can be called between 9AM and 11PM CT.
There can be tens of thousands of accounts available to call on any given day and are assigned to just a few workbaskets.
The OOTB "Get Next" relies on the assignment and urgency to return a result set of available cases. Post-query filtering is then used to determine if any of the cases in the result set are usable at that moment. With the volume of cases in the workbaskets, the query could return a group of cases where nothing is callable at that time of day.
We currently have a very customized version of "Get Next" that uses very complicated joins to return a result set that is more likely usable. By doing this we have lost a lot of flexibility in how "Get Next" works. We are looking to get back to something that is closer to OOTB functions.
I assume that this is an issue with many call centers, especially marketing and collections environments. Is there a suggested approach to optimize Get Next to handle calling windows?
(Note: currently all our users are in CT, but we want a solution that works no matter what the local time is for the user and the customer.)
Pegasystems Inc.
US
I think using skills to identify hours the operator normally covers could be one way to segregate the work. IE break the workday into two hour blocks, then assign the skills of working a particular blocks to the operators?
Pegasystems
US
I haven't looked at how the get-next-work functions in detail, but I assume it uses a db query to return a set of candidate records.
I suggest you expose enough properties so that you can design the query to return only candidates that are appropriate. The "where" expression would look something like this:
thisRecord.wakeTime .lessThan. currentTime AND
currentTime .lessThan thisRecord.sleepTime
In the above example, we're assuming each record has a wakeTime that indicates the earliest acceptable time to contact that customer, and that currentTime is the time at which the call center operator is performing the get-next-work function, and that sleepTime is the latest acceptable time to contact that customer.
/Eric
US Bank
US
Eric's concept is the direction I was thinking of as well. Just gets messy when trying to provide a solution that handles any customer time zone for users in any time zone. Everything has to be converted to a common time zone for comparison. My plan is to try to make this work by converting everything to GMT.
For instance, 9AM CST is 8AM MST, but both would be 3PM GMT. During Daylight Savings time, users in Arizona appear to be in Pacific Time, so 9AM CDT is now 7AM in Arizona but both would still be 2PM GMT. Gets pretty complicated to work through but you have to be sure to pass the current user time as GMT to the DB query to make it all work.