Scheduling Breaks and Meals in WFM
This topic describes how to use Workforce Management (WFM) to schedule meals and breaks in conjunction with Exceptions.
Pre-planned Breaks and Meals
Workforce Management enables you to pre-plan the breaks and meals (called shift items) that will be scheduled during a particular shift. You can define several parameters for these shift items, such as the time window during which they should be scheduled and whether they are paid or unpaid.
For example, if you set up a shift called 8-Hour Full-Time, as part of the shift item configuration, you have specified that there should be a 15- minute paid break in the shift. The Min Length from Shift Start parameter is set to 2:00 (2 hours) and the Max Length from Shift Start parameter is set to 4:00.
Additionally, your shift item configuration specifies that there should be an unpaid meal in the middle of the shift, with both the Min Time Before This Meal and Min Time After This Meal parameters set to 3:00.
You have configured a rotating pattern for a particular agent that specifies that the agent should work the 8-hour full-time shift every day, starting at 8:00 a.m.
Due to the shift item configuration, when WFM builds a schedule scenario that includes this agent, it will try to schedule the break and meal in the following time windows:
- It will try to schedule the break in the time window between 10:00 a.m. and 12:00 p.m.
- It will try to schedule the meal in the time window between 11:00 a.m. and 1:30 p.m.
Sometimes the configured time windows for breaks and/or meals conflicts with planned exceptions, such as meetings, training sessions, or administrative time, that were entered through the WFM Calendar. In these cases, the behavior of the Scheduler varies, depending on the particular type of shift item and its properties.
Default Behavior of the Scheduler
This section describes the default behavior of the Scheduler in the following three scenarios.
When Unpaid Breaks Conflict with Exceptions
When the time window of an unpaid break is covered by a planned exception, the Scheduler relaxes the constraints of the break, in order to schedule it. That is, the time window is widened in both directions (if possible) so that the break can be scheduled adjacent to the exception—either immediately before the exception or immediately after the exception.
This relaxation of the break constraints occurs because unpaid breaks are considered mandatory by the Scheduler due to their effect on the paid time of the shift.
There will be instances when one or more unpaid break(s) cannot be scheduled, even though they are considered mandatory. For example, if a shift has a paid duration of 8 hours, and there is a granted exception in the Calendar that also has a paid duration of 8 hours, that would not leave any time remaining for the Scheduler to place an unpaid break. As a result, the unpaid break is not scheduled and a warning is generated when the scenario is built.
When Paid Breaks Conflict with Exceptions
Unlike unpaid breaks, by default, paid breaks are not considered mandatory. Therefore, if there is a conflict between a planned exception and a paid break—so that the time window of the paid break is covered by the exception—by default, the paid break is not scheduled when the scenario is built.
When Meals Conflict with Exceptions
Meals are considered a mandatory part of a shift, if the shift has a meal configured. If there is a conflict between a planned exception and a meal—so that the time window of the meal is covered by the planned time for the exception—one of two things happen when the scenario is built:
- WFM looks for, and finds, another shift that is compatible with the agent’s contract, and allows the exception to be scheduled, or
- When WFM resolves the conflicting items in the Calendar (prior to the schedule being built), it declines the exception unless it can find another shift that is compatible with the agent's contract that allows the exception to be scheduled. In this case, the exception is not scheduled and a warning is generated.
Changing the Behavior of the Scheduler
Configuration options are available that can change the default behavior of the Scheduler when breaks and/or meal time windows conflict with planned exceptions. These options are described in detail in this section.
Paid Breaks are Mandatory
This is an optional setting that controls whether or not a paid break is scheduled even when the time window of the break is covered by an exception. As described above, this is always the behavior of the Scheduler with unpaid breaks. However, if this setting is turned on, the same behavior occurs with paid breaks; if the time window of the paid break is covered by an exception, the paid break will be scheduled adjacent to the exception—either immediately before the exception or immediately after it.
There still might be times when some breaks cannot be scheduled, even if this setting is turned on, because there is not enough room in the shift to accommodate the exception and all the configured breaks. In this case, a warning will be generated when the scenario is built.
See below, some sample scenarios when WFM would not be able to schedule a break (paid or unpaid), regardless of whether the user defines this as being mandatory or not:
Suppress Break-Related Warnings
This is an optional setting to control whether schedule warnings that describe issues with break scheduling are hidden from the user. If you are scheduling a lot of long exceptions that you know will make it impossible for the Scheduler to fit in most of the breaks you have configured, you might want to check this setting so that the break-related warnings are suppressed. This allows you to focus on the other schedule warnings that you want to resolve.
Allow Breaks and Meals During Exception
For each Exception Type, this setting might be turned on. If this option is configured, then if a planned exception of this type is being scheduled and it covers the time window of a break, the Scheduler tries to schedule the break during the exception, preserving the original configured time window. The Scheduler might not always be able to accomplish this, so if it cannot schedule one or more breaks during the exception, it will next try to schedule them adjacent to the exception. This setting always affects the scheduling of unpaid breaks. This setting only affects the scheduling of paid breaks, if paid break scheduling is configured as mandatory.
This setting also controls whether the Scheduler will try to schedule meals during an exception, in cases when the configured time window of the meal is covered by the exception. However, if the Scheduler is unable to schedule the meal during the exception for some reason, it will not be scheduled adjacent to the exception as it will try to do with breaks.
It is important to note that when the user configures an exception type, such that break(s) and meal(s) could be scheduled during the exception, it does not mean that all of these shift items will be scheduled during the exception. For example, the user has configured a 15-minute break with a 5-minute start step. The break configuration permits the break to be scheduled somewhere between 8:45 a.m. and 10:15 a.m. There is an exception from 9:00 a.m. - 10:00 a.m.
The break could be scheduled in many possible places, including:
8:45 a.m. - 9:00 a.m.
9:00 a.m. - 9:15 a.m.
9:05 a.m. - 9:20 a.m.
9:10 a.m. - 9:25 a.m.
. . .
9:45 a.m. - 10:00 a.m.
Also note that although the absolute start and end times of the exception will not be changed. For example, it is possible that the start of the exception could be covered by a break (both the break and the exception start at the same time).
When there is no conflict between an exception and some break(s), but yet the exception makes it impossible for WFM to schedule the breaks according to all of their configured constraints, WFM continues its default software behavior, which is to relax the break constraints so that they can be scheduled.
Hierarchy of Constraints
If breaks cannot be scheduled according to all of their configured constraints, WFM tries to satisfy the constraints in the following order:
- Time window
- Start step & start offset
- Minimum distance between shift items
- Maximum distance between shift items