The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?

We have very similar problems.

Cloud will regularly roster anywhere up to 20 or 25% of agents off at the same time by default:

even with very flexible break patterns in the workplan

The breaks are also absolutely not best placed - the same period highlighted above, the GOS drops from high 90s to 70%, when at least having a roughly equal amount of people on break at the same time would likely leave it in the mid to high 80s. 

I also feel that having the GOS recover to 89 immediately afterwards on a high AHT line is probably a little optimistic, but that is probably another thread for another day. 

This issue creates a huge workload of manual break smooth and optimise. 

Anyone who has this working, can just press Reschedule and get a good break pattern - please share your secrets with us!!! 

The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?

The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?

Hand/eye optimization tends to be fraught with issues. E.g., tend to unknowingly violate work plan constraints, make decisions that are actually much worse when looking at the improvement of the one interval at the expensive and totality of the impact to many other adjacent intervals, etc. Scheduling and rescheduling are constrained based on configuration and is looking at the entire scheduling period for optimization not one interval in isolation.

I would recommend opening a support ticket as there could be many reasons why there are common break/meal times chosen. @Paul Wood might comment on some items in the work for better activity optimization we are working on currently.

Just a few reasons:

• there really is not much flexibility in the allowed break/meal times; i.e., your min/max contiguous work time eliminates many combinations (a late first break might eliminate many of the possible meal start times).
• you might be looking grossly across all planning groups which hides the fact two people with identical breaks don't actually service the same set of interactions
• the 'weight' of the interval is also taken into consideration - we have protection against 'starving' very low volume planning groups, but if you have one big planning group that represents a big portion of the offered volume then it naturally is going to sway things
• service level versus agents is an s-curve and it is possible at the earlier and later stages that resource adds/subtractions don't result in a significant service level increase/decrease
• you have configuration issues where some of your agents are not really filling any need because they cannot service all route paths in the planning group to which they are associated
• deficiency in the software to outright bug

The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?

Hi Jay

Thank you so much for your lengthy response. I have raised a support case for this, but he wasn't of any help at all. I just want to stress that a fresh build of a new schedule do not result in breaks/meals clumping up. Our customer tested by building a new schedule, then manually moving agents' breaks/meals to be the same, then using Reschedule to check if the system actually optimize them. The use case is there are about 200 agents in the contact centre, working 24/7 shifts, and there are many requests for adhoc leave, or team leaders manually editing agents to do off-queue work, etc, and SLA is suffering. As a result, the Reschedule option is used frequently to optimize staffing. 

I tried looking for articles to find out what Reschedule actually aims to achieve, eg optimized daily SLA, or smoothing out over/under-staffing throughout the day?

Hand/eye optimization tends to be fraught with issues. E.g., tend to unknowingly violate work plan constraints, make decisions that are actually much worse when looking at the improvement of the one interval at the expensive and totality of the impact to many other adjacent intervals, etc. Scheduling and rescheduling are constrained based on configuration and is looking at the entire scheduling period for optimization not one interval in isolation.

I would recommend opening a support ticket as there could be many reasons why there are common break/meal times chosen. @Paul Wood might comment on some items in the work for better activity optimization we are working on currently.

Just a few reasons:

• there really is not much flexibility in the allowed break/meal times; i.e., your min/max contiguous work time eliminates many combinations (a late first break might eliminate many of the possible meal start times).
• you might be looking grossly across all planning groups which hides the fact two people with identical breaks don't actually service the same set of interactions
• the 'weight' of the interval is also taken into consideration - we have protection against 'starving' very low volume planning groups, but if you have one big planning group that represents a big portion of the offered volume then it naturally is going to sway things
• service level versus agents is an s-curve and it is possible at the earlier and later stages that resource adds/subtractions don't result in a significant service level increase/decrease
• you have configuration issues where some of your agents are not really filling any need because they cannot service all route paths in the planning group to which they are associated
• deficiency in the software to outright bug

The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?

Hi Cherith,

As @Jay Langsford mentioned optimised schedules can often lead to these "stacking" events as the scheduling engine balances the overall service goals for the BU over the entire day. This can lead to schedules being created that don't "look right to the human eye"

To help with this, we are looking to add more smoothing options to the scheduling engine, to help spread Activities more evenly across the availability windows. This can be tracked in the Ideas Portal as part of Ensure Fair, Randomly Generated Start Times for Agents please take a look and add your comments and use cases to help us ensure we are covering as many customer needs as possible.

Paul

Hi Jay

Thank you so much for your lengthy response. I have raised a support case for this, but he wasn't of any help at all. I just want to stress that a fresh build of a new schedule do not result in breaks/meals clumping up. Our customer tested by building a new schedule, then manually moving agents' breaks/meals to be the same, then using Reschedule to check if the system actually optimize them. The use case is there are about 200 agents in the contact centre, working 24/7 shifts, and there are many requests for adhoc leave, or team leaders manually editing agents to do off-queue work, etc, and SLA is suffering. As a result, the Reschedule option is used frequently to optimize staffing. 

I tried looking for articles to find out what Reschedule actually aims to achieve, eg optimized daily SLA, or smoothing out over/under-staffing throughout the day?

Hand/eye optimization tends to be fraught with issues. E.g., tend to unknowingly violate work plan constraints, make decisions that are actually much worse when looking at the improvement of the one interval at the expensive and totality of the impact to many other adjacent intervals, etc. Scheduling and rescheduling are constrained based on configuration and is looking at the entire scheduling period for optimization not one interval in isolation.

I would recommend opening a support ticket as there could be many reasons why there are common break/meal times chosen. @Paul Wood might comment on some items in the work for better activity optimization we are working on currently.

Just a few reasons:

• there really is not much flexibility in the allowed break/meal times; i.e., your min/max contiguous work time eliminates many combinations (a late first break might eliminate many of the possible meal start times).
• you might be looking grossly across all planning groups which hides the fact two people with identical breaks don't actually service the same set of interactions
• the 'weight' of the interval is also taken into consideration - we have protection against 'starving' very low volume planning groups, but if you have one big planning group that represents a big portion of the offered volume then it naturally is going to sway things
• service level versus agents is an s-curve and it is possible at the earlier and later stages that resource adds/subtractions don't result in a significant service level increase/decrease
• you have configuration issues where some of your agents are not really filling any need because they cannot service all route paths in the planning group to which they are associated
• deficiency in the software to outright bug

The WFM Reschedule option does not seem to be a reliable tool when it comes to break optimisation. The issue isn't so much that Genesys is lumping all the breaks together during a build, but more-so when using the "reschedule" function as a means to optimise breaks, it does not seem to work. 

In the example below, we intentionally moved the breaks and lunches together on Sat 10^th August for testing purposes, before attempting the reschedule - however the reschedule didn't make any improvements to the breaks.

I have attached a doc with all the screenshots of all the steps in the rescheduling. Any ideas why this is happening?