Jump to: navigation, search

Scheduling Breaks and Meals

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. The options are described in this section.

This is an optional setting that controls whether or not a paid break is scheduled even when the time interval 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 interval 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:

Example 1:
There is a shift with an 8-hour duration but which is 7.5 paid hours. The user grants a paid exception that is 7.5 hours, right in the middle of the shift, leaving 15 minutes on either side of the exception in which to schedule any breaks. If there is a 30-minute unpaid break to schedule, it cannot be scheduled unless the user wants to allow breaks to be scheduled “during the exception” (see below for more information about that optional setting).

Example 2:
There is an 8-hour shift from 8:00 a.m. to 4:00 p.m. The configuration of Break 1 (15-min) allows the break to be scheduled in a time window between 9:00 A.M -10:30 a.m. The configuration of Break 2 (15-min) allows the break to be scheduled within a time window between 2:00 p.m. - 4:00 p.m. The user grants an exception in the Calendar from 8:00 a.m. - 3:45 p.m. Unless the user wants to allow break(s) to be scheduled “during the exception,” one of the breaks cannot be scheduled, because there are only 15 minutes within the shift that is not already covered by the exception, and two 15-minute breaks to schedule.

Example 3:
There is an 8-hour shift from 8:00 a.m. - 4:00 p.m. The user grants an exception in the Calendar from 8:00 a.m. - 11:45 a.m. and another exception from 12:00 p.m. - 4:00 p.m. This leaves only 15 minutes between the two exceptions in which to schedule any breaks. Unless the user wishes to allow break(s) to be scheduled “during the exception,” it is likely that one or more breaks would not be scheduled.

Example 4:
Assume a shift from 8:00 a.m. - 1:00 p.m., one exception from 8:30 a.m. - 11:30 a.m., and two 1-hour breaks (the first one with configured window from 9:00 a.m. - 11:00 a.m., and the second one from 12:00 p.m. - 1:00 p.m.). Because the exception covers the first break, the break should be placed after the exception (because there is no room before it), from 11:30 a.m. - 12:30 p.m. Because of the scheduling of the first break, there is no room for the second break at all (but not because of the exception). In this case, one of the breaks would not be scheduled.

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).

Other Considerations

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.

Example 1:
There is a 15-minute break that could be scheduled between 9:00 a.m. - 1:00 p.m., and a second 15-minute break that could be scheduled between 10:00 a.m. - 2:00 p.m. The user has configured that the minimum distance between these breaks must be 3 hours. The user has granted an exception that goes from 11:00 a.m. - 3:00 p.m. It is impossible to meet the minimum distance constraint and also schedule these two breaks within their configured time windows. Therefore, WFM could relax the break constraints, in order to meet the minimum distance constraint and one break would be scheduled prior to the exception, and the other break would be scheduled after the exception.

As described above, when relaxing break constraints to accommodate planned exceptions, WFM attempts to schedule the break immediately adjacent to the exception. However, it is not always possible to do this, and sometimes there will be a small duration of activity work scheduled between the break and the exception.

Example 2:
The user has granted an exception from 12:00 p.m. - 1:05 p.m., and the configured time window for a particular 15-minute break specifies that the break must be scheduled somewhere between 1:15 p.m. - 2:15 p.m. Based on schedule coverage, WFM could place that break at 1:15 p.m., leaving just 10 minutes of activity work in between the exception and the break.

Example 3:
The user has granted an exception from 12:00 p.m. - 2:00 p.m., and the configured time window for a particular 15-minute break specifies that the break must be scheduled somewhere between 1:00 p.m. - 2:16 p.m. WFM would only have between 2:00 p.m. - 2:16 p.m. in which to schedule the break. WFM could schedule the break from 2:01 p.m. - 2:16 p.m., leaving 1 minute of work between the exception and the break.

Also note that the features described in this section only address partial-day exceptions, not full-day exceptions. Therefore, if the user needs to schedule an exception that covers a worker's entire shift, they should consider using a full-day exception type.

Example 4:
The user wants to grant an exception (type: meeting) after the Schedule has been built. In the Calendar, the user creates the Calendar Item and rebuilds the schedule. The meeting is reflected in the updated schedule and, in some cases, takes place during a paid break/meal or is adjacent to it.

Tip
If the user attempts to schedule the meeting, by using the Meeting Planner (after the schedule is built), the meeting is not scheduled, nor is the warning messages suppressed—assuming that the system is configured in this way.

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:

  1. Time window
  2. Start step & start offset
  3. Minimum distance between shift items
  4. Maximum distance between shift items
This page was last edited on May 6, 2019, at 11:28.
Comments or questions about this documentation? Contact us for support!