Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02567368 2006-11-08
SYSTEMS AND METHODS OF PARTIAL SHIFT SWAPPING
FIELD OF THE DISCLOSURE
The present disclosure relates to customer centers, and more specifically, to
scheduling of a workforce.
DESCRIPTION OF THE RELATED ART
A manager in a customerenter typically uses workforce scheduling software to
create a schedule which assigns workers (agents) to shifts throughout the
workday.
The scheduler chooses an optimal schedule that meets constraints while
optimizing
goals. Inputs such as predicted workload (e.g., call volume in 1 S-minute
intervals,
average call duration) and work rules (e.g., maximum shift length, possible
shift start
time, break requirements) are treated as constraints. Inputs such as expected
level of
service (e.g., call hold time) are treated as goals. The scheduler generates
many
possible schedules, and examines the possibilities to find a schedule that
optimizes
goals while remaining within the constraint boundaries.
In the real world, the generated schedule of agent shifts may be modified, for
various reasons, after initial creation. For example, agents may request time
off, or
wish to move from one workday to another. It is desirable for a shift
modification to
affect only a portion of the shift rather than the entire shift. For example,
an agent
assigned to work Friday 9 AM-5 PM may wish to take only the afternoon off. It
is
also desirable to allow an agent to plan ahead and coordinate the partial
shift
modification with another agent rather than requiring the partial shift
modifications to
be initiated through a supervisor.
SUMMARY
Systems and methods of partial shift swapping are disclosed. An exemplary
method comprises: receiving a partial shift swap request to swap a portion of
a shift;
and updating a schedule to reflect the partial shift swap request. The request
is to
swap a portion of the shift from an offering agent to an accepting agent. The
shift has
a date and at least one time range indicating the portion of the shift time
range to be
re-assigned to the accepting agent.
CA 02567368 2006-11-08
A computer-readable medium having a computer program stored thereon, the
computer program comprising computer-executable instructions for performing a
computer-executed method of requesting a partial shift swap. The computer-
executed
method comprises: receiving a partial shift swap request to swap a portion of
a shift;
and updating a schedule to reflect the partial shift swap request. The request
is to
swap a portion of the shift from an offering agent to an accepting agent. The
shift has
a date and at least one time range indicating the portion of the shift time
range to be
re-assigned to the accepting agent.
Another exemplary method comprises the steps of: receiving a partial shift
swap request from an agent; determining a disposition of the partial shift
swap request
by applying a set of criteria associated with a validation rule to the partial
shift swap
request; and if the disposition indicates the partial shift swap request is
approved,
updating a schedule to reflect the partial shift swap request. An exemplary
computer-
readable medium has a computer program stored thereon. The computer program
comprises computer-executable instructions for performing a computer-executed
method of requesting a partial shift swap. The method comprises the steps of:
receiving a partial shift swap request from an agent; determining a
disposition of the
partial shift swap request by applying a set of criteria associated with a
validation rule
to the partial shift swap request; and if the disposition indicates the
partial shift swap
request is approved, updating a schedule to reflect the partial shift swap
request.
BRIEF DESCRIPTION OF THE DRAWINGS
Many aspects of the disclosure can be better understood with reference to the
following drawings. The components in the drawings are not necessarily to
scale,
emphasis instead being placed upon clearly illustrating the principles of the
present
disclosure.
FIG. 1 is a block diagram of a customer center environment.
FIG. 2 is a block diagram illustrating various objects involved in one
embodiment of a system and method for partial shift swapping.
FIG. 3 is a block diagram illustrating various objects involved in another
embodiment of a system and method for partial shift swapping.
2
CA 02567368 2006-11-08
FIG. 4 is a flowchart describing an exemplary system and method for partial
shift swapping.
FIG. 5 is a flowchart of the schedule update process FIG. 4.
FIGS. 6A-B are a flowchart of a process of applying rules to a request and
disposing of the request based on the rule behaviors in one embodiment of a
system
and method for partial shift swapping
FIG. 7 is a flow chart of one embodiment of a submission process for partial
shift swap requests.
DETAILED DESCRIPTION
FIG. 1 is a block diagram of a customer center environment 100. Customer
center 100 is staffed by agents who handle incoming and/or outgoing contacts.
Although the traditional and most common form of contact is by phone, other
types of
contacts can be used, such as text chat, web collaboration, email, and fax. An
agent
workspace includes an agent phone 110 and a workstation computer 120. A
network
130 connects one or more of the workstations 120.
A contact router 140 distributes or routes contacts (incoming or outgoing) to
an agent position. Voice over Internet Protocol (VoIP) calls and computer-
based
contacts (e.g., chat, email) are routed over one or more data networks, and
distributed
over network 130 to one of the agent workstations 120. Contact router 140 may
include an automatic call distributor (ACD) 150 to route phone contacts. The
embodiments described herein will refer to ACD 150 instead of contact muter
140,
but analogous contact router actions and operations are intended to be
captured by this
disclosure. Note that a predictive dialer (not shown) could be used for
directing
outbound calls to agents for handling.
If an agent is not available to handle a particular call, ACD 150 puts the
call
into a queue, which effectively places the caller on hold. When an agent is
available,
ACD 150 connects the outside trunk line 160 carrying the phone call to one of
the
agents. More specifically, ACD 150 connects the outside trunk line 160 to the
trunk
line 170 of the selected agent.
When an agent is ready to handle contacts, the agent first logs into ACD 150.
This login notifies ACD 150 that the agent is available to take calls. An
agent's ACD
state changes throughout the workday, as the agent performs work activities
such as
3
CA 02567368 2006-11-08
handling calls, performing after-call work, and taking breaks. An example list
of
states includes available, busy, after-call work, and unavailable.
While handling a contact, the agent interacts with one or more applications
running on workstation 120. By way of example, workstation applications could
provide the agent with access to customer records, product information,
ordering
status, and transaction history. The applications may access one or more
business
databases (not shown) via the network 130.
Customer center 100 also includes a workforce management system (WFMS)
180. WFMS 180 performs many functions. One such function is providing a
customer
center supervisor or manager with information about agents and contacts, both
historical and real-time. Another function is supplying the supervisor with
information on how well each agent complies with customer center policies. Yet
another function is calculating staffing levels and creating agent schedules
based on
historical patterns of incoming contacts. The functionality of the entire WFMS
180 is
typically divided among several applications, some of which have a user
interface
component, and WFMS 180 comprises the suite of applications.
In the environment described above, the workers assigned to shifts are
customer center agents. However, the scheduling methods and systems described
herein are also applicable to scheduling other kinds of workers in other types
of work
environments. Therefore, the remaining embodiments will refer to workers
rather than
agents.
A customer center may include, but is not limited to, outsourced contact
centers, outsourced customer relationship management, customer relationship
management, voice of the customer, customer interaction, contact center, mufti-
media
contact center, remote office, distributed enterprise, work-at-home agents,
remote
agents, branch office, back office, performance optimization, workforce
optimization,
hosted contact centers, and speech analytics, for example.
Additionally, included in this disclosure are embodiments of integrated
workforce optimization platforms, as discussed in U.S. Application No.
11/359,356,
filed on February 22, 2006, entitled "Systems and Methods for Workforce
Optimization," which is hereby incorporated by reference in its entirety. At
least one
embodiment of an integrated workforce optimization platform integrates: (1)
Quality
4
CA 02567368 2006-11-08
Monitoring/Call Recording - voice of the customer; the complete customer
experience
across multimedia touch points; (2) Workforce Management - strategic
forecasting
and scheduling that drives efficiency and adherence, aids in planning, and
helps
facilitate optimum staffing and service levels; (3) Performance Management -
key
performance indicators (KPIs) and scorecards that analyze and help identify
synergies, opportunities and improvement areas; (4) e-Learning - training, new
information and protocol disseminated to staff, leveraging best practice
customer
interactions and delivering learning to support development; and/or (5)
Analytics -
deliver insights from customer interactions to drive business performance. By
way of
example, the integrated workforce optimization process and system can include
planning and establishing goals - from both an enterprise and center
perspective - to
ensure alignment and objectives that complement and support one another. Such
planning may be complemented with forecasting and scheduling of the workforce
to
ensure optimum service levels. Recording and measuring performance may also be
utilized, leveraging quality monitoring/call recording to assess service
quality and the
customer experience.
FIG. 2 is a block diagram illustrating various objects involved in one
embodiment of a system and method for partial shift swapping. In this
embodiment,
one agent assigned to a shift containing a work activity offers a portion of
that shift to
another agent who accepts the shift. This embodiment is known as a "one-way
swap"
because the agent offering his shift does not accept the other agent's shift
in return.
Another "two-way swap" embodiment will be described below, in which the agents
exchange shifts: the agent offering his shift also accepts the other agent's
shift in
return.
Shifts (210', 210") include a date (210D), at least one activity (210A), and a
time range (21 OR). In one embodiment, the shift time range 2108 specifies a
start
time and an end time. In another embodiment, the shift time range 2108
specifies a
start time and a duration. Each shift is assigned to one agent 220. A schedule
230
includes shifts 210 within a particular time period.
A partial shift swap request 240 includes an offering shift (2400), an
accepting shift (240A), and a swap time range (240R) which represents a sub
range
within the time range 21 OR of the offering shift 2400. The agent to which an
offering
CA 02567368 2006-11-08
shift (2400) is assigned to is referred to as an "offeror agent", and the
agent to whom
an accepting shift (240A) is assigned to is referred to as an "acceptor
agent".
When put into effect, the partial shift swap request 240 removes a portion of
the offering shift (2400) from the associated agent, and allocates the shift
portion to
the agent associated with the accepting shift (240A240R). The portion is
specified by
swap time range 2408. That is, a swap request specifying an offering shift
(2400) on
9/20/06 from 9 AM to 5 PM and a swap time range 2408 of 10 AM-1 PM is a
request
for an offeror donor agent to give away, to an acceptor agent, the 10 AM-1 PM
portion of the offeror donor agent's 9 AM to 5 PM shift on 9/20/06.
Partial shift swap request 240 also includes a set of hard validation rules
(240H) and a set of soft validation rules (240S). These rules will be applied
to request
240 to determine the disposition of the request (e.g., automatically approved,
automatically denied, or held for manager review). Each of the soft validation
rules
240S includes criteria for comparison with the swap request. Each soft
validation rule
240S also includes a behavior which determines how the result of the criteria
application affects the disposition of the request. Validation rule criteria
and behaviors
will be discussed later in connection with FIGS. 5 and 6. A person of ordinary
skill in
the art should understand how the set of validation rules used with a
particular (one-
way or two-way) swap request can be selected and/or entered via a user
interface
component of WFMS 180. Therefore, this process will not be described in
further
detail.
In the example of FIG. 2, shift 210', which is assigned to John (220J), has a
date (210D') of 9/20/2006, and a time range (210R') of 8 AM to 7 PM. The
activities
in shift 210' include: work activities from 8 AM to 12:00 PM, from 1:00 PM to
3:30
PM, and from 4 PM to 7 PM; and break activities from 12:00 PM to 1:00 PM and
from 3:30 PM to 4 PM. Shift 210", which is assigned to Fred (220F), has a date
(210D") of 9/21/2006 and a time range (2108") of 7 AM to 2 PM. The activities
in
shift 210" include: work activities from 7 AM to 11:00 AM, and from 11:30 PM
to
2:00 PM; and a break activities from 11:00 AM to 11:30 AM.
Partial shift swap request 240 represents a request for John to offer the 4 PM-
7
PM portion of his shift 210' on 9/20/2006 to Fred: the offering shift (2400)
is set to
shift 210' (9/20/2006, assigned to John); the accepting shift 240A is set to
shift 210"
6
CA 02567368 2006-11-08
(9/20/2006, assigned to Fred); and swap time range 2408 specifies "4 PM-7 PM"
in
the accepting shift. Thus, after partial shift swap request 240 is put into
effect,
schedule 230 is updated so that John has a new "Time Off' activity from 4 PM
to 7
PM on 9/20/2006, and Fred has a new work activity from 4 PM to 7 PM on
9/20/2006. In this "one-way swap" embodiment, John did not accept a shift, or
a
partial shift, from Fred.
FIG. 3 is a block diagram illustrating various objects involved in another
embodiment of a system and method for partial shift swapping. In this
embodiment,
one agent assigned to a shift containing a work activity offers a portion of
that shift to
another agent, and also accepts the other agent's shift. This embodiment is
known as a
"two-way swap". A person of ordinary skill in the art should understand that
although
one-way and two-way partial shift swaps are discussed here as separate
objects, a
single data structure could be used instead with a type field to distinguish
between the
two.
Shifts (310', 310") include a date (310D), a time range (310R) and at least
one
activity (310A). Each shift is assigned to one agent 320. A schedule 330
includes
shifts 310 within a particular time period.
A partial shift swap request 340 includes an offering shift (3400), an
accepting shift (340A), and a time range (340R) which represents a sub range
within
the time range 3108 of the offering shift 3400. When the partial shift swap
request
340 is put into effect, schedule 330 is updated so that a portion of the
offering shift
(3400) is exchanged with the corresponding portion of the accepting shift
(340R),
where the portion is specified by time range 3408. Since both shifts are
associated
with agents, the effect is to exchange a portion of one agent's shift with a
corresponding portion of another agent's shift. Partial shift swap request 340
also
includes a set of hard validation rules (340H) and a set of soft validation
rules (340S).
These rules will be applied to request 340 to determine whether the request is
automatically approved, automatically denied, or held for manager review.
In the example of FIG. 3, shift 310', which is assigned to John (320J), has a
date (310D') of 9/20/2006, and a time range (310R') of 8 AM to 5 PM. The
activities
in shift 310' include: work activities from 8 AM to 12:00 PM, from 1:00 PM to
3:30
PM, and from 4 PM to 5 PM; and break activities from 12:00 PM to 1:00 PM and
7
CA 02567368 2006-11-08
from 3:30 PM to 4 PM. Shift 310", which is assigned to Fred (320F), has a date
(310D") of 9/21/2006 and a time range (3108") of 10 AM to 5 PM. The activities
in
shift 310" are analogous to those in shift 310'.
Partial shift swap request 340 represents a request for John to exchange the 8
AM-10 AM portion of his shift 310' on 9/20/2006 with Fred's shift on
9/21/2006: the
accepting shift (3400) is set to shift 310' (9/20/2006, assigned to John); the
accepting
shift 340A is set to shift 310" (9/21/2006, assigned to Fred); and time range
3408
specifies "8 AM-10 AM" in the accepting shift. Thus, after partial shift swap
request
340 is put into effect, schedule 330 is updated so that Fred has a new work
activity
from 8 AM to 10 AM on 9/20/2006, and John has a new work activity from 8 AM to
10 AM on 9/21/2006.
FIG. 4 is a flowchart describing an exemplary system and method for partial
shift swapping. The process 400 begins at block 410, which receives a partial
shift
swap request (240 or 340). Next, at block 420, a set of hard validation rules
(240H or
340H) are applied, where "hard" validation rules are those which cause the
request to
fail if violated. (Hard validation rules are discussed in further detail
below.)
Processing continues at block 430, where results of the application of hard
validation
rules, at block 420, are examined. If the partial shift swap request (240 or
340)
violates the hard validation rules, the process terminates at block 440 with a
failure of
the request.
If the request does not violate the hard validation rules, processing
continues
at block 450, where a set of soft validation rules (240S or 3405) are applied.
The
result of applying "soft" validation rules is approving, denying, or holding
the request,
depending on which of the validation rules are violated or not violated. In
contrast, the
result of applying the hard validation rules is to fail the request or to
continue with
application of soft validation rules. Block 450, which applies soft validation
rules, is
discussed in further detail below, in connection with FIG. 6.
At block 460, the result of applying soft validation rules is examined. If the
result is "Suspend", then processing continues at block 470, where the request
is
submitted to a manager or supervisor for approval or denial. A person of
ordinary
skill in the art should understand how a user interface component of WFMS 180
can
be used by a manager, or other customer center personnel, to process a
submitted
8
CA 02567368 2006-11-08
request. Therefore, this process will not be described in further detail. In
some
embodiments, information about rule violations and/or rule compliance, as
determined during the hard and/or soft rule validation process, is made
available to
manager during the swap request review process.
Next, block 480 examines the result of the manager's decision. If the
manager's decision is "Deny", processing continues at block 485, which will be
discussed below. If the manager's decision is "Approve", processing continues
at
block 490, which will be discussed below.
Returning to the discussion of block 450, if the result of applying the soft
validation rules at block 450 is "Deny", then processing continues at block
485, where
the offeror and acceptor agents are notified that the partial shift swap
request (240 or
340) is denied. In some embodiments, the manager is also notified. Processing
of the
request is then complete.
If the result of applying soft validation rules at block 450 is "Approve",
then
processing continues at block 490, where the schedule (230 or 330) is updated
to
reflect the partial shift swap. The process of updating the schedule will be
discussed
in more detail in connection with FIG. 5. Next, at block 495, the offeror and
acceptor
agents are notified that the partial shift swap request (240 or 340) is
approved. In
some embodiments, the manager is also notified. Processing of the request is
then
complete.
FIG. S is a flowchart of the schedule update process (490) of FIG. 4, which is
performed when a partial shift swap request (240 or 340) is approved. At block
510,
the swap type is determined as one-way or two-way. If two-way, processing
continues
at block 520, which will be discussed later. If one-way, processing continues
at block
530.
Block 530 determines whether the acceptor agent (the one associated with the
accepting shift field 240A) is already assigned a shift starting on the date
(21 OD) in
the offering shift (2400). If the agent does not have a shift already assigned
that day,
processing continues at block 540, where a new shift is created and assigned
to the
acceptor agent. The new shift uses the date in the offering shift (2400), the
activities
(210A) in the offering shift (2400) and the time range (240R) of the one-way
swap
request 240.
9
CA 02567368 2006-11-08
Work activities and shift-related activities (e.g., breaks) that fall within
the
swap range 3408 are copied from the offering shift (3400) to the accepting
shift
(340A). In some embodiments, work rules are taken into account filling the
accepting
shift (340A) with shift-related activities. Thus, breaks are moved into the
add or
remove breaks from the newly constructed shift such that the agent complies
with
work rules. For example, accepting a 1-hour partial shift that is adjacent to
an
already-assigned 9-hour shift results in a 10-hour shift. If work rules
require that four
15-minute breaks are scheduled in a 10-hour shift, then accepting the 1-hour
partial
shift includes placing a new break in the I O-hour shift, regardless of
whether the 1-
hour offering shift portion included a break activity. Similarly, removing
portions
from an offering shift (3400) could result in removal of a break if the
shortened
offering shift (3400) falls below a work-rule minimum.
Calendar-based activities such as Meetings and Training are not copied, but
remain with the original agent. For example, consider an agent assigned to a
meeting
from 10:00-10:30 AM. When this agent offers the 8:00 AM-11:00 AM portion of
this
shift, then the work activities (8:00-10:00 AM and 10:30-11:00) are copied to
the
accepting shift, but the 10:00-10:30 meeting is not. After the swap, the
offeror agent
still has a meeting at 10:00 AM, and the accepting shift (340A) is filled with
work
activities from 8:00-11:00 AM, which includes the 10:30-11:00 slot. Processing
continues at block 550, where the offering shift (2400) is deleted. After work-
related,
shift-related, and calendar-based activities are transferred to the offering
shift (3400),
as described above, processing for the one-way swap request 240 is then
complete.
If block 530 determines that the agent does have a shift already assigned that
day, processing continues at block 560, which creates a new shift object (210)
using
the date in the offering shift (2400), and setting the shift start time
(contained in field
210R) to the start time indicated in the swap request time range (240R). Any
gap
between the new shift start time and the already-assigned shift is filled in
with a gap
activity. The new shift is associated with the accepting agent (the one
associated with
the accepting shift field 240A). Processing continues at block 550, where the
offering
shift (2400) is deleted. Processing for the one-way swap request 240 is then
complete.
CA 02567368 2006-11-08
Returning to block 510, if the swap type is two-way, then the swap is
accomplished by creating two new shift objects (310) at block 520. One shift
object
310 is initialized with the date in the accepting shift (340A) of the swap
request, and
is associated with the offeror agent (also through accepting shift 340A). The
other
shift object is initialized with the date in the offering shift (3400) of the
swap request,
and is associated with the offering agent (also through offering shift 3400).
Any gap
between the start time of a new shift and the start time of an already-
assigned shift is
filled with a gap period, in a manner analogous to gap handling for one-way
swaps.
In creating the two new shift objects 310, block 520 also fills in shift
activities
310A. Calendar-based activities such as Meetings and Training are not swapped,
but
remain with the agent. Work activities and shift-related activities (e.g.,
breaks) that
fall within the swap range 3408 are copied from the accepting shift (340A) to
the
offering shift (3400), and vice versa. For example, consider an agent assigned
to a 9
AM to 5 PM shift, with one break at 9:30-9:45 AM, lunch break at 11:30 AM -12
PM, and another break at 3:00 - 3:15 AM. When this agent offers the 8:00 AM-
11:45
AM portion of this shift, then the following activities are copied to the pick-
up shift:
the 9:00-9:30 work activity; the 9:30-9:45 AM break; the 9:45-11:30 work
activity;
and the first half of the lunch break activity, from 11:30-11:45. Note that
the 11:45
PM-12:00 PM lunch break activity remains with the offeror agent, since that
time
range is outside of the swap range 3408.
After block 520 creates the two replacement shift objects, the original
accepting shift (340A) and offering shift (3400) are deleted at block 570.
Processing
of a two-way swap request 340 continues at block 580, which handles overlap as
follows. If there is an overlap between an agent's original shift and the new
swapped
portion, the activities in the new portion overwrite or replace the activities
in the
original portion. Processing for the two-way swap request 340 is then
complete.
Having discussed the process of shift swapping, including applying validation
rules, and updating the schedule for an approved request, exemplary hard and
soft
validation rules will now be described in more detail. As described.above,
violation of
a hard validation rule causes the partial shift swap request 240 to fail. One
hard
validation rule is violated if one of the agents participating in the shift
swap is not
associated with a valid organization. Another hard violation rule is violated
if an
11
CA 02567368 2006-11-08
already-assigned shift starts during the organization-defined day of the
accepting
shift. Both the published and the unpublished schedule are checked. For two-
way
swaps, both the offering shift and the accepting shift are checked. For one-
way swaps,
the accepting shift is not checked if it has type "time off'.
Yet another hard validation rule ensures that the offering shift and the
accepting shift are both valid (i.e. the shifts themselves still exist in the
schedule for
the agent that the shift belongs to). For one-way swap, this includes
verifying that the
accepting shift has a time off activity, and that the offering shift is valid.
For a two-
way swap, this includes verifying that both the offering shift and the
accepting shift
are valid shifts (in the published and unpublished schedule).
Another hard validation rule checks that swapped shifts still exist in the
schedule (unpublished) and have not been modified in any way (e.g., shift,
time
range). For two-way swap, both shifts are verified. This rule also verifies
that shift
locations in the unpublished schedule before the swap are still empty.
As described above, soft validation rules (240S or 3405) are applied to
determine whether a partial shift swap request (240 or 340) is disposed of by
approval, denial, or suspension for manager review. More specifically, the
criteria for
each rule is applied to the request, resulting in a violation or a pass for
each rule.
Criteria for several exemplary soft validation rules will be described next,
followed by
further details about the process of applying soft validation rules.
Some soft validation rules are related to the duration of the portion of the
shift
being swapped. One such soft validation rule is violated when the duration of
the
swapped portion is less than a specified minimum. Another soft validation rule
is
violated when the duration of the shift portion remaining after the swap is
less than a
specified maximum. Either minimum can be expressed as an absolute time period
or
as a percentage of the duration.
A partial shift swap request (240 or 340) is associated (directly or
indirectly)
with one agent (220) in the case of a one-way swap or two agents in the case
of a two-
way swap. Several soft validation rules are related to the associated agent or
agents
(220). One agent-related soft validation rule, which applies to a two-way
swap, is
violated if the two agents are not associated with the same organization
during their
respective shifts before and after the swap. Another agent-related soft
validation rule
12
CA 02567368 2006-11-08
ensures that the two agents are associated with the same campaign. As applied
to one-
way swaps, this rule is violated if the two agents are not associated with the
same
campaign on the day of the shift being swapped. As applied to two-way swaps,
this
rule is violated if the two agents are not associated with the same campaign
during
their respective shifts before the swap and after the swap.
Yet another agent-related soft validation rule is violated when the two agents
do not have the same skills for the active campaign queue during the time
period of
the shift involved. Yet another agent-related soft validation rule is violated
when the
two agents do not have the same skill proficiency level for the active
campaign queue
during the time period of the shift involved.
Each campaign is associated with a set of work rules which specify how many
hours an agent can work or be paid for in a time period. Some soft validation
rules
check for compliance with these work rules. One validation rule is violated
when a
weekly maximum of hours worked is exceeded, or a weekly minimum is not met,
for
the shift portion being offered and for the shift portion being accepted.
Another soft
validation rule is violated when the total paid shift duration exceeds the
daily
maximum as a result of the swap. One variation of this rule calculates the
shift
duration using the organization's day boundaries (e.g. 6:00 AM to 5:59 A1V17.
Another
variation calculates the shift duration using a rolling 24-hour period before
and after
the shift. Yet another validation rule is violated when both shifts, or shift
portions, in a
two-way swap do not include the same number of paid hours. Another soft
validation
rule is violated if the swapped shift portions do not fall within the same
organization-
defined week.
Shifts may contain various non-work activities (e.g., agent is unavailable),
or
related-to-work activities (e.g., training). One soft validation rule is
violated when the
swap includes any of a list of prohibited activities. Some soft validation
rules relate to
handling activities assigned to specific calendar days during a swap. One such
soft
validation rule is violated when the swap results in a particular calendar-
assigned
activity falling outside of the agent's shifts as the result of the swap, if
that activity is
required to take place during an agent's assigned shift.
Another soft validation rule is violated under either of two conditions. The
first condition occurs when a swap would result in any overlap between the
accepting
13
CA 02567368 2006-11-08
shift and an unavailable activity. For example, suppose a shift assigned from
9 AM-3
PM was offered for swap. An acceptor agent with an unavailable activity that
includes
any time between 9 AM-3 PM meets the first condition, and the rule is
violated. Note
that no overlap at all is allowed: unavailability from 8:30-9:15 violates the
rule, as
does unavailability from 2:45-3:1 S PM.
T'he second condition occurs when a swap would result in the loss of a
calendar-assigned activity or a time-off activity which overlaps a shift. Put
another
way, swapped shifts should overlap the exact same portion with calendar-
assigned
and time-off activities, otherwise the rule is violated.
An example involving the second condition is as follows. Suppose an offeror
agent has an assigned shift 9 AM-12 PM with a calendar-assigned activity from
10
AM-11 AM. The first condition would be met if the accepting shift starts at
10:30 or
11:30, since the accepting shift overlaps with the calendar-assigned activity.
The rule
would be violated, and the swap request may be denied, depending on the rule
behavior. However, an accepting shift from 9:30 AM-12:00 does not overlap the
calendar-assigned activity from 10 AM-11 AM, but rather completely includes
the
calendar-assigned activity. Therefore, the first condition is not met, and the
rule is not
violated.
Some partial shift swaps result in either an overlap with an already-assigned
shift, or a gap between an already-assigned shift and the newly assigned
shift. One
soft validation rule is violated when the duration of the resulting overlap is
more than
a specified maximum. Another soft validation rule is violated when the
duration of the
resulting gap is less than a specified minimum or is outside a specified range
(e.g., 1-5
hours). In one embodiment, if both the gap range and minimum are specified, a
violation occurs only if both the conditions are violated.
Now that example criteria have been discussed, application of the rules to the
swap request and disposition based on the result will now be discussed. Each
of the
set of rules (2405 or 340S) is applied to a partial shift swap request (240 or
340).
Behavior associated with each rule, and/or the set of rules, then determines
how the
request is disposed of approved, denied, or held for manager review. Rule
behavior
works as follows. Two types of rule behavior are specific to a particular
rule: one
automatically denies the request when that rule is violated; and the other
14
CA 02567368 2006-11-08
automatically grants the request when that rule passes. Other types of rule
behavior
are global to the set of soft validation rules. One of these global behaviors
automatically denies the request when any rule in the set is violated. Another
global
behavior automatically grants the request when any rule in the set passes. Two
other
global behaviors force a manager review of the request: one suspends the
request for
manager review even when application of the rule would otherwise indicate an
automatic approval; the other suspends the request for manager review even
when
application of the rule would otherwise indicate an automatic denial.
The process of applying rules to a request and disposing of the request based
on the rule behaviors will be discussed in connection with the flowchart in
FIGS. 6A-B. The process (450) of applying a set of soft validation rules
begins at
block 605 with an iteration loop that is applied for each rule in the set of
soft
validation rules associated with the partial shift swap request (240 or 340).
Block 610
applies the current rule to the partial shift swap request (240 or 340) to
determine
whether or not the request violates the rule. Next, block 615 records whether
the
request violated the rule or the request passed the rule. Processing returns
to block
6I0 with the next loop iteration.
After applying all rules in the set, processing continues at block 620, which
determines (using information maintained in block 615) whether any of the soft
validation rules have been violated. If any rule is violated, then processing
continues
at block 625, which will be discussed later. If no rule is violated,
processing continues
at block 630, where the global rule set behavior is examined. If the global
behavior
type is ApproveIfNoViolations, then the process returns, with a disposition of
Approve, at block 635. If the global behavior type is NoAutomaticApprove, then
the
process continues at block 640, where the process returns with a disposition
of Hold.
Otherwise, processing continues at block 645, which will be discussed later.
Returning now to block 625, when at least one soft validation rule was
violated, block 625 examines the global rule set behavior. If the global
behavior type
is DenyIfAnyViolations, then the process returns, with a disposition of Deny,
at block
650. If the global behavior type is NoAutomaticDeny, then the process
continues at
block 655. Otherwise, processing continues at block 660.
CA 02567368 2006-11-08
Block 660 starts an iteration loop that is applied for each violated rule (as
determined by block 615). Next, at block 665, the behavior of each violated
rule is
examined. If the rule behavior type is DenyIfViolated, then the process
returns, with a
disposition of Deny, at block 670. Otherwise, processing returns to block 665
for the
next loop iteration, until the loop ends with all violated rules processed. At
that point,
the process returns, with a disposition of Suspend, at block 67~.
Returning now to block 645, when no soft validation rule was violated and the
global behavior block is not ApproveIfNoViolations or NoAutomaticApprove,
block
645 starts an iteration loop that is applied for each non-violated rule (as
determined by
block 615). Next, at block 680, the behavior of each non-violated rule is
examined. If
the rule behavior type is ApproveIfNotViolated, then the process returns, with
a
disposition of Approve, at block 685. Otherwise, processing returns to block
645 for
the next loop iteration, until the loop ends with all violated rules
processed. At that
point, the process returns, with a disposition of Approve, at block 690.
In this manner, the partial shift swap request (240 or 340) is automatically
approved if either no rule violations were found and the global rule set
behavior is
ApproveIfNoViolations, or if at least one passing rule (non-violation) is
found with a
corresponding rule behavior of ApproveIfNotViolated. The partial shift swap
request
(240 or 340) is automatically denied if either at least one rule violation was
found and
the global rule set behavior is DenyIfAnyViolations, or if at least one rule
violation is
found with a corresponding rule behavior of DenyIfViolated. The request
partial shift
swap request (240 or 340) is held for manager review if no rule violations
were found
and the global rule set behavior is NoAutomaticApproval, or if at least one
rule
violation was found and the global rule set behavior is NoAutomaticDenial.
Some embodiments of partial shift swapping include a feature which allows
agents to submit partial shift swap requests (240 or 340), which are then
validated by
the hard and soft validation rules. Two types of submission are described. In
the first
type of swap request submission, the request specifies both the offering shift
(2400)
and the accepting shift (240A). This type is appropriate when the offering
agent has
coordinated in advance with the accepting agent. That is, John and Fred have
already
worked out the swap details by which Fred will accept John's shift (one-way),
or John
will accept Fred's shift while Fred accepts John's shift (two-way).
16
CA 02567368 2006-11-08
In the second type of swap request submission, the offering agent "posts" his
offered shift. The posted offerings can be viewed by other agents. A second
agent can
pick up a posted shift offering, at which point the swap request details have
been
determined, and the swap request is created. In either case, the partial shift
swap
request goes through hard and soft validation rule processing.
FIG. 7 is a flow chart of one embodiment of a submission process for partial
shift swap requests. The process 700 can be entered from multiple entry
points. When
entered at point 705, the offering agent submits at block 710 a partial shift
swap
request including details of the offering shift (3400), the accepting shift
(340A), and
the swap time range (340R). When entered at point 715, the offering agent
posts (720)
a portion of his shift, including details of the offering shift (3400) and the
swap time
range (340R). The accepting shift (340A) is not yet known, so its details are
not
included. At block 725, the posting is made available for viewing by other
agents.
Next, at block 730, an accepting agent chooses to accept the offered partial
shift. A
person of ordinary skill in the art should understand that a variety of
posting/viewing/submitting mechanisms are available, so further details of
such a
mechanism are not included here.
Both entry pathways converge at block 735, where the submission information
is used to create a partial shift swap request 340, with an offering shift
(3400), an
accepting shift (340A), and the swap time range (340R). In block 740 a
determination
is made as to whether the newly created swap request passes the hard
validation rules
(340H). Applying hard validation rules was described akeady in connection with
FIG. 4. If the request failed hard validation, the swap request is marked as
failed or
invalid (block 745), and process 700 returns. If the request passed hard
validation, the
request is marked valid (block 750) and processing continues at block 755.
At block 755, an option in the partial shift swap request 340 is examined. A
valid partial shift swap request 340 begins in a "Negotiation" state. Through
an option
associated with the swap request, the offering agent can choose to allow the
other
agent involved in the swap to submit the request to the manager, or to require
feedback from the other agent before submission. When feedback is required,
the
request remains in the "Negotiation" state until both agents agree on the swap
details,
17
CA 02567368 2006-11-08
and one of them submits the request to the manager. In one embodiment, the
manager
cannot view swap requests that are in the "Negotiation" state.
If block 755 determines that the option is set to "Submit Without Feedback",
then processing moves to block 760. Otherwise, then block 765 waits until the
one of
the agents has submitted the request after receiving feedback, then moves to
block
760.
At block 760, process 700 determines whether any soft validation rules are
associated with the organization. If soft validation rules exist, the
submitted request is
passed on, in block 770, to the soft validation rule engine. Processing of
soft
validation rules was described earlier in connection with FIG. 6. If no soft
validation
rules exist, then block 775 places the partial shift swap request 340 in a
"Suspend"
state and notifies the manager that the request should be reviewed. The
manager
reviews the partial shift swap request 340 and approves or denies the request.
In case of a denial, the two agents involved in the swap are notified of the
decision (block 780). In the case of an approval, the two agents involved in
the
decision are notified of the decision (block 780), and the schedule 330 is
updated
(block 785) and then published. Process 700 is then complete.
Any process descriptions or blocks in flowcharts should be understood as
representing modules, segments, or portions of code which include one or more
executable instructions for implementing specific logical functions or steps
in the
process. As would be understood by those of ordinary skill in the art of the
software
development, alternate implementations are also included within the scope of
the
disclosure. In these alternate implementations, functions may be executed out
of order
from that shown or discussed, including substantially concurrently or in
reverse order,
depending on the functionality involved.'
The systems and methods disclosed herein can be embodied in any computer-
readable medium for use by or in connection with an instruction execution
system,
apparatus, or device. Such instruction execution systems include any computer-
based
system, processor-containing system, or other system that can fetch and
execute the
instructions from the instruction execution system. In the context of this
disclosure, a
"computer-readable medium" can be any means that can contain, store,
communicate;
propagate, or transport the program for use by, or in connection with, the
instruction
18
CA 02567368 2006-11-08
execution system. The computer readable medium can be, for example but not
limited
to, a system or propagation medium that is based on electronic, magnetic,
optical,
electromagnetic, infrared, or semiconductor technology.
Specific examples of a computer-readable medium using electronic
technology would include (but are not limited to) the following: an electrical
connection (electronic) having one or more wires; a random access memory
(RAM); a
read-only memory (ROM); an erasable programmable read-only memory (EPROM or
Flash memory). A specific example using magnetic technology includes (but is
not
limited to) a portable computer diskette. Specific examples using optical
technology
include (but are not limited to) an optical fiber and a portable compact disk
read-only
memory (CD-ROM).
The foregoing description has been presented for purposes of illustration and
description. It is not intended to be exhaustive or to limit the disclosure to
the precise
forms disclosed. Obvious modifications or variations are possible in light of
the above
I S teachings. The implementations discussed, however, were chosen and
described to
illustrate the principles of the disclosure and its practical application to
thereby enable
one of ordinary skill in the art to utilize the disclosure in various
implementations and
with various modifications as are suited to the particular use contemplated.
All such
modifications and variation are within the scope of the disclosure as
determined by
the appended claims when interpreted in accordance with the breadth to which
they
are fairly and legally entitled.
19
