U.S. patent application number 13/111472 was filed with the patent office on 2012-10-11 for methods and systems for workforce management.
This patent application is currently assigned to INFOSYS TECHNOLOGIES LIMITED. Invention is credited to Pradeep Kishore, Visvanathan Lakshmi Narayan.
Application Number | 20120259540 13/111472 |
Document ID | / |
Family ID | 46966737 |
Filed Date | 2012-10-11 |
United States Patent
Application |
20120259540 |
Kind Code |
A1 |
Kishore; Pradeep ; et
al. |
October 11, 2012 |
METHODS AND SYSTEMS FOR WORKFORCE MANAGEMENT
Abstract
Systems and computer-implemented methods for managing a
workforce include receiving a request for support including a
location of the request for support, converting the request for
support into a work ticket, classifying the work ticket, allocating
the work ticket to a field operative out of a set of at least one
field operatives, transmitting a request for a map including data
from the work ticket, receiving a map image including data relating
to the work ticket, and transmitting the map image including data
relating to the work ticket to the field operative.
Inventors: |
Kishore; Pradeep;
(Pallikaranai, IN) ; Narayan; Visvanathan Lakshmi;
(Mylapore, IN) |
Assignee: |
INFOSYS TECHNOLOGIES
LIMITED
Bangalore
IN
|
Family ID: |
46966737 |
Appl. No.: |
13/111472 |
Filed: |
May 19, 2011 |
Current U.S.
Class: |
701/410 ;
701/465; 705/7.13; 705/7.14; 705/7.16 |
Current CPC
Class: |
G06Q 10/105 20130101;
G06Q 10/06 20130101; G06Q 10/103 20130101 |
Class at
Publication: |
701/410 ;
705/7.13; 705/7.14; 705/7.16; 701/465 |
International
Class: |
G06Q 10/00 20060101
G06Q010/00; G01C 21/00 20060101 G01C021/00 |
Foreign Application Data
Date |
Code |
Application Number |
Apr 7, 2011 |
IN |
1189/CHE/2011 |
Claims
1. A computer implemented method for managing a workforce, said
method comprising: receiving, by a computing device, a request for
support including a location of the request for support; converting
the request for support into a work ticket; classifying the work
ticket; scheduling allocation of the work ticket to a field
operative out of a set of at least one field operatives;
transmitting, by a computing device, a request for a map including
data from the work ticket; receiving, by a computing device, a map
image including data relating to the work ticket; and transmitting,
by a computing device, the map image including data relating to the
work ticket to the field operative.
2. The method of claim 1, wherein the step of scheduling allocation
of the work ticket is dynamic and occurs substantially in real
time.
3. The method of claim 1, wherein the step of classifying the work
ticket includes at least one of: determining a service area for the
work ticket; determining a service type for the work ticket; and
determining a priority of the work ticket.
4. The method of claim 3, wherein the step of allocating the work
ticket includes: receiving an indication of a geographic location
of each field operative in the set of field operatives; receiving
an indication of qualifications of each field operative in the set
of field technicians; and assigning the work ticket to one of the
field operatives in the set of field operatives in the service area
having qualifications matching the service type.
5. The method of claim 4, wherein the geographic location of each
field operative is a geographic region that the field operative can
travel to within a determined time period.
6. The method of claim 5, wherein if the priority of the work
ticket is above a threshold, the method further comprises expanding
the service area for the work ticket.
7. The method of claim 5, wherein the priority of the work ticket
increases after a threshold is met.
8. The method of claim 1, further comprising: receiving, by a
computing device, a location of the field operative; transmitting,
by a computing device, a request for routing from the location of
the field operative to the location of the service request;
receiving, by a computing device, a route between the location of
the field operative and the location of the service request;
transmitting, by a computing device, the route to the field
operative.
9. The method of claim 1, further comprising: receiving an
indication of the geographic location of a field operative in the
set of field operatives periodically; storing each received
geographic location indication for the field operative;
transmitting a map configured to display a route corresponding to
the periodic geographic location indications for the field
operative.
10. The method of claim 1, further comprising: receiving, by a
computing device, a second request for support including a location
of the request for support; converting the second request for
support into a second work ticket; classifying the second work
ticket; allocating the second work ticket to a field operative out
of the set of at least one field operatives; and reallocating the
work ticket if the second work ticket is allocated to the field
operative that the work ticket was allocated to and the second work
ticket has a higher priority than the work ticket.
11. The method of claim 10, further comprising: reallocating the
work tickets assigned to plural field operatives in the set of
field operatives in response to receipt of a subsequent work
ticket.
12. Computer-readable code stored on a non-transitory
computer-readable medium that, when executed by one or more
computing device, implements a method for managing a workforce,
said method comprising: receiving, by a computing device, a request
for support including a location of the request for support;
converting the request for support into a work ticket; classifying
the work ticket; allocating the work ticket to a field operative
out of a set of at least one field operatives; transmitting, by a
computing device, a request for a map including data from the work
ticket; receiving, by a computing device, a map image including
data relating to the work ticket; and transmitting, by a computing
device, the map image including data relating to the work ticket to
the field operative.
13. The method of claim 12, further comprising: receiving an
indication of the geographic location of a field operative in the
set of field operatives periodically; storing each received
geographic location indication for the field operative;
transmitting a map configured to display a route corresponding to
the periodic geographic location indications for the field
operative.
14. The method of claim 13, further comprising: receiving, by a
computing device, a second request for support including a location
of the request for support; converting the second request for
support into a second work ticket; classifying the second work
ticket; allocating the second work ticket to a field operative out
of the set of at least one field operatives; and reallocating the
work ticket if the second work ticket is allocated to the field
operative that the work ticket was allocated to and the second work
ticket has a higher priority than the work ticket.
15. The method of claim 14, further comprising: reallocating the
work tickets assigned to plural field operatives in the set of
field operatives in response to receipt of a subsequent work
ticket.
16. The method of claim 15, wherein the step of classifying the
work ticket includes at least one of: determining a service area
for the work ticket; determining a service type for the work
ticket; and determining a priority of the work ticket.
17. A system for managing a workforce, said system comprising: a
memory device; and a processing device coupled to the memory
device, the processing device executing: a module configured to
receive a request for support including a location of the request
for support; a module configured to convert the request for support
into a work ticket; a module configured to classify the work
ticket; a module configured to allocated the work ticket to a field
operative out of a set of at least one field operatives; a module
configured to transmit a request for a map including data from the
work ticket; a module configured to receive a map image including
data relating to the work ticket; and a module configured to
transmit the map image including data relating to the work ticket
to the field operative.
18. The system of claim 17, wherein the processing device further
executes: a module configured to receive an indication of the
geographic location of a field operative in the set of field
operatives periodically; a module configured to store each received
geographic location indication for the field operative; a module
configured to transmit a map configured to display a route
corresponding to the periodic geographic location indications for
the field operative.
19. The system of claim 17, wherein the processing device further
executes: a module configured to receive a second request for
support including a location of the request for support; a module
configured to convert the second request for support into a second
work ticket; a module configured to classify the second work
ticket; a module configured to allocate the second work ticket to a
field operative out of the set of at least one field operatives;
and a module configured to reallocate the work ticket if the second
work ticket is allocated to the field operative that the work
ticket was allocated to and the second work ticket has a higher
priority than the work ticket.
20. The system of claim 19, wherein the processing device further
executes: a module configured to reallocate the work tickets
assigned to plural field operatives in the set of field operatives
in response to receipt of a subsequent work ticket.
21. The system of claim 17, wherein the processing device further
executes: a module configured to generate dynamic reports, wherein
the dynamic reports are one or more of map based and chart based.
Description
RELATED APPLICATION DATA
[0001] This application claims priority to Indian Patent
Application No. 1189/CHE/2011, filed Apr. 7, 2011, which is hereby
incorporated by reference in its entirety.
BACKGROUND
[0002] Workforce management strives to get the right number of
technicians in the right places at the right times to maximize
service and minimize cost. Optimization is difficult since it
involves intelligent scheduling and dispatching of multiple
technicians to different locations, while minimizing cost and
maintaining good customer service. Workforce management may be
useful, for example, for companies that need to manage a field
force of technicians for installations or servicing existing
systems. Typical workforce management systems may interface with
ticket management systems to schedule and assign jobs to
technicians. Optimal workforce management, however, requires more
than an optimal schedule for technicians. Immediate and unexpected
changes, such as changes in technician status or unforeseen changes
in the workload, may require spontaneous adjustments.
[0003] Some current workforce management systems provide map
centric tools, such as the systems provided by CLICKSOFTWARE.TM..
These systems attempt to optimize efficiency by scheduling and
dispatching a qualified technician to a location near the
technician. However, these workforce management systems generally
come bundled with land base data (e.g., maps or other
cartographical data). The bundled land base data may quickly become
out-of-date and result in less than optimal scheduling and
dispatch. This may also lead to inaccurate driving instructions
being provided to a technician, thus further reducing
efficiency.
[0004] Further, typical workforce management systems may contribute
to inefficiencies due to lack of real time location data. For
example, a typical system may see that a technician was scheduled
to do a job at a first location and, thus, ad hoc schedule this
same technician to assist with an emergency repair at a location
near the first location. However, if technician finished the first
job they may no longer be near the first location. Typical
workforce management systems fail to adopt dynamic scheduling and
real-time dispatch using real-time location data to increase
efficient allocation.
[0005] Finally, typical standalone workforce management systems are
resource intensive, expensive to operate, and difficult to
integrate with other enterprise level systems. For example, a
company may purchase a custom made workforce management system to
manage field technicians. These systems may be cost preclusive for
small companies. Additionally, these systems may be difficult to
integrate with allied systems, for example technician time entry
systems, ticket management systems, vehicle tracking systems,
payroll and benefits systems, human resources systems, and the
like.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 shows a functional block diagram of a workforce
management system.
[0007] FIG. 2 shows an exemplary workforce management system
architecture having a workforce management subsystem operatively
coupled to a maps API.
[0008] FIG. 3A-B show exemplary user interfaces for interacting
with a workforce management system.
[0009] FIG. 4A-D show additional exemplary user interfaces for
interacting with a workforce management system.
[0010] FIG. 5 shows an exemplary computing device useful for
implementing systems and performing methods disclosed herein.
[0011] While systems and methods are described herein by way of
example and embodiments, those skilled in the art recognize that
systems and methods for workforce management are not limited to the
embodiments or drawings described. It should be understood that the
drawings and description are not intended to be limiting to the
particular form disclosed. Rather, the intention is to cover all
modifications, equivalents and alternatives falling within the
spirit and scope of the appended claims. Any headings used herein
are for organizational purposes only and are not meant to limit the
scope of the description or the claims. As used herein, the word
"may" is used in a permissive sense (i.e., meaning having the
potential to), rather than the mandatory sense (i.e., meaning
must). Similarly, the words "include", "including", and "includes"
mean including, but not limited to.
DETAILED DESCRIPTION
[0012] Disclosed embodiments provide computer-implemented methods
and systems for managing a workforce. Embodiments may be configured
to reduce operational costs through managing unplanned and ad hoc
jobs generated due to emergency, short service level agreement
("SLA") times, missed appointments, and the like. Embodiments may
implement Geographic Information System ("GIS") based location
intelligence and location based services to optimize work force
allocation and management. Embodiments may also integrate with
existing and allied systems, such as trouble ticket systems, field
force tracking systems, and the like.
[0013] FIG. 1 shows a functional block diagram of a workforce
management system ("WFMS") 101. WFMS 101 may include one or more
workforce management computing device(s) 102 configured to
effectively plan and dispatch field service technicians (or other
field operatives). In addition to scheduling planned work tickets,
workforce management computing device 102 may be configured to
dispatch technicians substantially in real-time in response to ad
hoc work tickets (e.g., in the case of an emergency). Workforce
management computing device 102 may be operatively coupled to an
integration computing device 105 for integrating with allied and
existing systems 118.
[0014] Integration computing device 105 may be a computing device
configured to integrate existing and allied computing systems 118
with workforce management computing device 102. For example,
integration computing device 105 may include one or more data
stores configured to convert data from allied and existing systems
118 into a format useful for workforce management computing device
102. For example, integration computing device 105 may be
configured to receive trouble tickets from a ticketing system, for
example REMEDY.TM., that may need to be assigned to a technician
from an existing system 108 and convert the trouble tickets into a
format required by workforce management computing device 102.
Integration computing device 105 may, alternatively or in addition,
perform services to assist in integration, for example caching
services to speed data access for workforce management computing
device 102. Integration computing device 105 may be configured to
convert data from legacy systems to formats useful for the
workforce management system 101 and then replace the functionality
of the legacy systems. For example, integration computing device
105 may convert existing trouble tickets to a required format then,
going forward, receive all new trouble tickets and, thus, replace
the legacy system.
[0015] While integration computing device 105 is described above as
integrating workforce management computing device 102 with a
trouble ticket system, integration computing device 105 may
integrate with any allied and existing systems, for example
inventory systems, human resource systems, reporting systems,
scheduling systems, customer relation systems, and the like.
Alternatively, integration computing device 105 may be omitted,
thereby allowing existing and allied systems 118 to be operatively
coupled directly to workforce management computing device 102.
Further, integration computing device 105 may be configured to
provide various systems, such as trouble ticket systems, if no such
systems previously existed or to simply replace such existing
systems.
[0016] System 100 also includes a technician interface computing
device 103 operatively coupled to workforce management computing
device 102. Technician interface computing device 103 may be
operatively coupled to one or more technician computing device, for
example over a network 119 such as the Internet, a local area
network ("LAN"), a wide area network ("WAN"), mobile service
provider network (e.g., from VERIZON.TM. WIRELESS), and the like.
Technician interface computing device 103 may be coupled to
technician computing devices such as a laptop 114, a tablet 112
(e.g., an IPAD.TM.), a smartphone 111 (e.g., an IPHONE.TM., a
BLACKBERRY.TM., or an ANDROID.TM. based phone). Of course, these
devices are exemplary only, and technician interface computing
device 103 may also be coupled to custom-made computing devices,
conventional cell phones (i.e., dumbphones), personal computers,
set top boxes, or any other communication device. Technician
computing devices may be useful for providing an interface for
technicians to view and interact with work tickets assigned to the
technician, for example accept a work ticket, decline a work
ticket, update the status of a work ticket, and the like. Exemplary
user interfaces are discussed below with reference to FIGS. 3A-B
and 4A-D. Technician computing devices may also provide routing
instructions relating to a work ticket (e.g., by showing directions
on a map), provide a technician with access to allied and existing
systems (e.g., provide access to a payroll or time entry system),
and the like. In some embodiments, network 119 may be a private
network. For example, for a WFMS 101 configured to manage a
workforce of security personnel it may be desirable to transmit
classified data only over a secure, private network.
[0017] WFMS 101 also may include a vehicle tracking computing
device 104 configured to track one or more vehicles 116, such as
work trucks driven by technicians. Each vehicle 116 may be equipped
with one or more sensors configured to determine the vehicle's
location and transmit the location to vehicle tracking computing
device 104. For example, vehicle 116 may be equipped with a Global
Positioning System ("GPS") sensor configured to receive signals
from plural GPS satellites 117 to determine its position. Vehicle
116 may be operatively coupled to vehicle tracking computing device
104, for example over a radio frequency connection, such as over a
mobile service provider network or other network connection.
Vehicle 116 may transmit various data to vehicle tracking computing
device 104, for example the location of the vehicle. Of course, the
vehicle may transmit any additional information, such as diagnostic
information about the vehicle 116 (e.g., a check engine
indication), inventory information regarding inventory available in
the vehicle 116 (e.g., inventory of replacement parts), and the
like. Vehicle tracking computing device 104 may store vehicle
tracking information for a determined period of time. Of course,
alternatively WFMS 101 may be operatively coupled to an existing or
allied vehicle tacking computing device via integration computing
device 105 rather than, or in addition to, including vehicle
tracking computing device 104.
[0018] WFMS 101 may also include a mapping integration computing
device 106 configured to integrate map information from one or more
map services 114 with workforce management computing device 102.
Mapping integration computing device 106 may be coupled to one or
more map services 114, such as GOOGLE.TM. MAPS services, ESRI.TM.
ARCGIS.TM. online services, YAHOO!.TM. MAPS services, MICROSOFT.TM.
BING.TM. MAPS services, and the like, for example over an
Application Programming Interface ("API") via network 115. Mapping
integration computing device 106 may include mapping information in
a GIS, for example using ESRI.TM. ARCSDE.TM.. Mapping integration
computing device 106 may include a Feature Manipulation Engine
("FME"), an integrated collection of spatial extract, transform,
and load ("ETL") tools for spatial data transformation and
translation. Mapping integration computing device 106 may use an
FME to convert spatial data from a Spatial Database Engine ("SDE")
format to Keyhole Mark-up Language ("KML"), an eXtensible Markup
Language ("XML") schema for expressing geographic annotation and
visualization within Internet-based, two-dimensional maps and
three-dimensional Earth browsers, such as the services provided by
GOOGLE.TM. MAPS. KML may be useful for inserting objects, such as
overlays, images, icons, and the like, into a map. The objects may
correspond to service requests, the current location of
technicians, warehouses or other locations for technicians to
resupply, and the like. Of course, alternative embodiments may
utilize alternative engines or systems other than FTE.
[0019] For example, an embodiment may integrate a map into a
webpage or application via the mapping services like GOOGLE.TM.
MAPS API, BING.TM. MAPS API, and the like. Such embodiments may
overlay various data points and objects on the map corresponding to
technician locations, truck locations, technician service areas,
work locations, warehouses, offices, and the like. The various data
points and objects may be selectable so that a user, such as a
technician, may determine which should be displayed on a user
interface. Data points and objects may be displayed depending on a
profile of each user. For example, a technician's profile may
provide that only work tickets assigned to that technician should
be displayed on the technician's user interface while a
dispatcher's profile may provide that all technicians' locations
should be displayed on the dispatcher's user interface.
[0020] Of course, while FIG. 1 shows WFMS 101 comprising several
independent computing devices, alternative embodiments may include
one or more computing devices implementing WFMS 101. Such
embodiments may execute modules corresponding to the various
computing device shown in WFMS 101.
[0021] FIG. 2 shows an exemplary WFMS architecture 200 having a
WFMS subsystem 210 operatively coupled to a maps API 230. In
operation, a user 205 may place a request for customer service with
a customer care subsystem 215. For example, a user 205 having
problems with their internet service provider may call a service
number to place a service request. A call center operator may then
enter the service request into the customer care system 215.
Alternatively, a user 205 may enter a service request directly into
the customer care subsystem, for example through a web interface.
Of course, these methods are exemplary only, and customer care
subsystem 215 may receive service requests from a user 205 in any
fashion.
[0022] Upon receiving a service request, customer care subsystem
215 may classify the service request, convert the service request
into a service ticket (i.e., a trouble ticket or a work ticket) in
an appropriate format for WFMS subsystem 210, and forward the
service ticket to WFMS subsystem 210. Once a service ticket is
received by WFMS subsystem 210, the service ticket may be
reclassified according to the service area, the ticket type, and
the priority and then allocated to one or more field operatives. A
local WFMS database 212 may store all service tickets. The service
tickets may, for example, be stored in a job assignment table with
a ticket status field initially being updated to "open" to indicate
that the ticket is awaiting allocation to a technician.
[0023] A geocoder 213 within WFMS subsystem 210 may identify the
service area corresponding to the service ticket. Geocoder 213 may
then send a request to a maps API 230, for example GOOGLE.TM. MAPS
API or ArcGIS.TM. online services, to request information regarding
technicians in or near the service area. A mapping engine 231 may
have access to local spatial data (e.g., showing service areas,
real time technician locations from a technician tracking system,
and the like) from a local spatial database 225 mapped to or
overlaid on the mapping service's spatial data from a spatial data
database 232. Mapping engine 231 may return through maps API 230
the identity, location, and additional information regarding
technicians in or near the service area.
[0024] A scheduler 214 within WFMS subsystem 210 may receive the
information from maps API 230 and filter the information to
determine which technicians in the service area have the required
skills and/or supplies to handle the ticket. Next, with the
technicians filtered to identify the technicians in or near the
service area and having the skill set and/or supplies to respond to
the type of service request, the WFMS subsystem 210 may check the
priority of the ticket. If a service ticket has the highest
priority, then an available technician in the service area having
the requisite skill set may be assigned to the service ticket by
subsystem 210. If no available technicians in or near the service
area have the requisite qualifications, then the technician in the
service area with the requisite qualifications assigned to a job
that is most likely to finish first may be assigned to the service
ticket by subsystem 210. Further, if no technicians in the service
area have the requisite qualifications, the nearest available
technician outside the service area having the skill set, or the
nearest available technician outside the service area having the
skill set and most likely to complete their current task shortly
may be assigned to the service ticket by subsystem 210.
[0025] Through scheduler 214, lower priority service tickets may be
assigned dynamically to technicians in similar fashion to high
priority service tickets. However, if higher priority service
tickets exist in a service area, lower priority service tickets may
be queued behind higher priority service tickets. Additionally, if
a technician is assigned to a lower priority service ticket and has
not yet arrived at the service location to do the work, the
technician may be reassigned to the higher priority service ticket.
In some instances, a ticket may have such high priority that one or
more technicians may be reassigned even while they are working on a
service ticket. For example, WFMS subsystem 210 may receive an
emergency ticket and immediately (dynamically) reassign technicians
to the emergency ticket. Thus, the technician assignment can be in
either of two modes. For example, at the start of each work day,
scheduler 214 may run to automatically assign tickets that are open
(i.e., unassigned). Once the tickets start flowing in for the day
(i.e., being received), dynamic scheduling may kick in and reassign
technicians to tickets different from the ones already assigned.
This dynamic scheduling may be based on current location of
technicians and distance from the location of higher priority in
addition to various parameters considered during the original
scheduling.
[0026] Service tickets may have many different priority levels for
example priority levels one to ten, with one being the highest
priority and ten being the lowest. WFMS subsystem 210 may be
configured to increase the priority of tickets the longer they
remain unassigned. Priority level increases may be tied, for
example, to SLA times or to the estimated time of arrival ("ETA")
of a technician that was initially given a user 205 when they
placed a service request. In other words, priority may be increased
after a threshold is met, for example an SLA threshold or an ETA
threshold.
[0027] As scheduler 214 in WFMS subsystem 210 assigns technicians
to service tickets and as the technicians service the service
tickets, WFMS subsystem 210 may update records in the local WFMS
database 212 to reflect the same. For example, an assignment table
with a ticket status field initially may be updated to "assigned",
"in progress", "closed", and the like to indicate the status of the
ticket. Additionally, a service ticket table in WFMS database 212
may be updated over time, for example to adjust the priority of a
ticket as time passes, to remove, or otherwise flag, completed
tickets, and the like.
[0028] WFMS application server 211 may provide a user interface
("UI") to WFMS subsystem 211. For example, WFMS application server
211 may provide a UI 300 as shown in FIG. 3A. UI 300 may include a
view details tab 301 displaying an employee table 310 and a ticket
table 320. Employee table 310 may show each technician, their
location, and their allocation status. Employee table 310 may
provide UI controls to allow a user to filter the data shown, for
example a location filter 311 may be used by a user to display
technicians only in or near a certain service area and an allocated
filter 312 may be used by a user to display only technicians having
certain allocated attributes (e.g., "available", "allocated",
etc.). Ticket table 320 may show each service ticket, the ticket
type, the location, and the priority of the ticket. Ticket table
320 may also include UI controls to allow a user to filter the data
shown, for example a location filter 322 may be used by a user to
display tickets only in a certain service area and a priority
filter 323 may be used by a user to display tickets having a
certain priority. Of course, while the UI controls are shown as
drop-down menus, any UI controls may be used. Also, additional or
different UI controls may be implemented to allow a user to filter
data in various other ways.
[0029] UI 300 may also include an assign employee control 324. UI
300 may be configured to allow a user to select (e.g., highlight or
click on) a technician in employee table 310, select a ticket in
ticket table 320, and select assign employee control 324 to assign
the technician to the ticket. Alternatively, when a user selects
assign employee control 324, an additional user interface control
may allow a user to select a technician to assign to a ticket.
[0030] UI 300 may also include a map 330. Map 330 may be a map
retrieved from maps API 320 showing real time technician and
service ticket indicators overlaid on an up-to-date map.
Additionally, indicators on map 330 (not shown) may be displayed or
hidden depending on a user's selection of various UI controls, for
example location filter 311, allocated filter 312, location filter
322, and priority filter 323. Map 330 may additionally be overlaid
with additional data from local spatial database 225, for example
various service areas, locations of warehouses for supplies, and
the like. Map 330 may additionally include various user controls
331 to allow a user to navigate (e.g., pan in various directions,
zoom in or out, toggle on and off information such as traffic,
satellite view, and the like, view a GOOGLE.TM. STREETVIEW,
etc.).
[0031] FIG. 3B shows an exemplary add details tab 302 of UI 300
including an add employee area 340 and an add ticket area 350. Add
details tab 302 may be useful, for example, for a user, such as a
call center employee, to enter new work tickets and new technicians
into the WFMS subsystem 210. Add employee area 340 may include
multiple fields 341 for a user to input data about a technician and
a UI control 342 for the user to enter the data about the
technician into the WFMS subsystem 210. Add ticket area 350 may
likewise include multiple fields 351 for use to input data about a
work ticket and a UI control 352 for the user to enter the data
about the work ticket into the WFMS subsystem 210. Once a new
technician or work ticket is entered into the WFMS subsystem 210,
an object may appear overlaid on map 330 indicating the technician
or work ticket. Of course, different or additional data may be
entered for each technician and/or work ticket.
[0032] WFMS subsystem 210 may additionally provide UIs
corresponding to other features. For example, FIG. 4A shows an
exemplary vehicle tracking UI 410. UI 410 may include a track
vehicles control area 411 configured to provide a user with
controls to indicate one or more vehicles to track, toggle on and
off vehicle tracking, clear the map of vehicle tracking, and the
like. For example, a user may select to track a vehicle 412. As
vehicle 412 moves, a GPS sensor in vehicle 412 may track the
location of vehicle 412 and a system within vehicle 412 may be
configured to substantially continuously or periodically (e.g.,
every minute) transmit the vehicle's location to WFMS 200 of FIG.
2. In this fashion, WFMS 200 may update the data to overlay a map
provided by a map service provider 230 to display up-to-date
location information of vehicle 412. UI 410 may additionally
display a vehicle trail 415 showing turn by turn path vehicle 412
travels. For example, UI 410 shows vehicle trail 415 showing the
route vehicle 412 traveled after leaving a work ticket location
413. UI 410 may be useful for ensuring that a technician travels
directly from one work location 413 to another work location 414,
thereby saving both time and gas and optimizing the response of the
workforce. Vehicle trail 415 in UI 410 shows that vehicle 412 is
traveling in the opposite direction of a work location 414, thus a
dispatcher may contact the technician to inform them of the
error.
[0033] FIG. 4B shows an exemplary WFMS statistics UI 420. WFMS
statistics UI 420 may include a statistics charts control area 421
configured to provide a user with controls 422 to select one or
more areas 423 of the map and statistics 424 related to the areas
423 of the map. For example, a user may select a tool 422 that
allows the user to click and drag a cursor to define a rectangular
area 423 on the map. Statistics 424, such as a pie chart, may show
statistics related to the selected area 432. The exemplary
statistics 424 pie chart shown in FIG. 4B shows that the vast
majority of the work orders in the selected area 432 are low
priority, a smaller amount are medium priority, and a small percent
are high priority. Statistics charts control area 421 may
additional display text 425 or other indicators with statistics,
such as showing that 2.7% of the work orders are high priority. Of
course, UI 420 may show real time statistics in alternative
formats, such as by displaying other or additional graphs or
charts. By enabling a user to quickly see real time statistics, the
WFMS may be substantially continuously adjusted to maintain a
sufficient workforce where demand exists while limiting a workforce
when the need for a large workforce does not exist.
[0034] FIG. 4C shows an exemplary technician service area UI 430.
Technician service area UI 430 may include technician service area
control 431 configured to allow a user to select the technician
whose service area they would like to see overlaid on the map as
well as various other options related to display of the
technician's service area. For example, a user may select a
technician 435 and indicate that they would like to see a first
service area 432, a second service area 433, and a third service
area 434 for technician 435. In the technician service area 431 a
user may indicate how they would like the service areas determined,
for example the first service area 432 may encompass locations the
technician can drive to within 3 minutes, the second service area
433 may encompass locations the technician can drive to within 10
minutes, and the third service area may encompass locations the
technician can drive to within 15 minutes.
[0035] The location of the technician 435 may be retrieved in real
time from a vehicle tracking subsystem in or coupled to WFMS 200. A
map API 230 may then be queried for locations that the technician
435 would be able to travel to within the time constraints set for
the first service area 432, the second service area 433, and the
third service area 434. By maps API 230 providing ranges based on
driving time rather than merely based on physical distance, WFMS
200 may optimize scheduling of technicians. For example, as shown
in FIG. 4C, service areas may follow highways or roads, therefore
allowing a technician proximate a major highway reach a work order
location faster than another technician who may be physically
closer to the work order location.
[0036] FIG. 4D shows an exemplary landscape UI 440 showing a
GOOGLE.TM. STREETVIEW of a location. For example, a user of any of
the UIs shown in FIGS. 4A, 4B, and 4C may select a user control to
see landscape UI 440 of a particular location on the map. This may
be useful, for example, for a technician traveling to a location to
confirm that the location he arrives at corresponds to the work
location. This may also be useful for a technician en route to
determine if they are on the right path.
[0037] Of course, additional UIs may be displayed. For example, a
directions UI may be useful for providing directions to a work
location to a technician. For example, WFMS 200 may request
directions from a technician's real-time location to a work order
location by transmitting a request for directions to a maps API
230. Maps API 230 may then return a map including the directions
overlaid thereon, thereby providing a technician with turn-by-turn
directions to a work order location.
[0038] Independent of the particular method used to transmit
directions to a technician, WFMS system 200 may be useful for
optimizing a technician's response route, thereby both decreasing
the technician's response time as well as potentially decreasing
the technician's fuel expenses. Thus, by providing a map based
system a workforce of technicians may be optimized to provide
technicians with requisite skill sets in various work areas to
respond to user demand.
[0039] These embodiments may be implemented with software, for
example modules executed on computing devices such as computing
device 510 of FIG. 5. Embodiments may, for example, execute modules
to implement the systems and methods disclosed herein. Of course, a
single step may be performed by more than one module, a single
module may perform more than one step, or any other logical
division of various steps disclosed herein may be used to implement
the processes as software executed on a computing device.
[0040] Computing device 510 has one or more processing device 511
designed to process instructions, for example computer readable
instructions (i.e., code) stored on a storage device 513. Storage
device 513 may be any type of storage device (e.g., an optical
storage device, a magnetic storage device, a solid state storage
device, etc.), for example a non-transitory storage device.
Alternatively, instructions may be stored in remote storage
devices, for example storage devices accessed over a network or the
internet. Computing device 510 additionally has memory 512, an
input controller 516, and an output controller 515. A bus 514
operatively couples components of computing device 510, including
processor 511, memory 512, storage device 513, input controller
516, output controller 515, and any other devices (e.g., network
controllers, sound controllers, etc.). Output controller 515 may be
operatively coupled (e.g., via a wired or wireless connection) to a
display device 520 (e.g., a monitor, television, mobile device
screen, touch-display, etc.) in such a fashion that output
controller 515 can transform the display on display device 520
(e.g., in response to modules executed). Input controller 516 may
be operatively coupled (e.g., via a wired or wireless connection)
to input device 530 (e.g., mouse, keyboard, touch-pad, scroll-ball,
touch-display, etc.) in such a fashion that input can be received
from a user.
[0041] Of course, FIG. 5 illustrates computing device 510, display
device 520, and input device 530 as separate devices for ease of
identification only. Computing device 510, display device 520, and
input device 530 may be separate devices (e.g., a personal computer
connected by wires to a monitor and mouse), may be integrated in a
single device (e.g., a mobile device with a touch-display, such as
a smartphone or a tablet), or any combination of devices (e.g., a
computing device operatively coupled to a touch-screen display
device, a plurality of computing devices attached to a single
display device and input device, etc.). Computing device 510 may be
one or more servers, for example a farm of networked servers, a
clustered server environment, or a cloud network of computing
devices.
[0042] Thus, embodiments disclosed herein may be useful for
dynamically dispatching a workforce to provide optimal services
while minimizing cost. By integrating real-time workforce location
information with consistently up-to-date maps, workforce management
systems disclosed herein may fluidly and substantially continuously
reroute members of the workforce as needs change. By integrating
with existing services, such as GOOGLE.TM. MAPS or one or more
other mapping services, cost in creating and maintaining such a
workforce management system may be substantially reduced while
reliability of such a system (e.g., vintage of map information)
improved.
[0043] Workforce management systems disclosed herein may
additionally be scalable. For example, a central workforce
management system may manage separate work forces (e.g., workforces
for non-related companies and/or relating to non-related services).
For example, both work tickets and technicians may be identified as
corresponding to a certain business to ensure the correct
technicians are assigned to the correct work tickets. Further, such
combined systems may be optimized for various business rules. For
example, such services may include referral services or substitute
services so that if the company that received a work ticket does
not have the bandwidth or expertise to respond to the work ticket,
they may refer the work ticket to a company who can.
[0044] Workforce management systems disclosed herein may be hosted
by an entity in similar fashion to conventional workforce
management systems, for example by having one or more computing
device hosting the workforce management system located at an
entity's office. Alternatively, workforce management systems
disclosed herein may be implemented according to a hosted services
model. For example, a workforce management system may be offered as
a service (i.e., as Software as a Service ("SaaS")). This may allow
a company to simply provide its technician, vehicle tracking, and
similar data to the workforce management system over an internet
connection and the workforce management system can be completely
hosted and provided by a third party entity. In this fashion, even
companies with meager means may be able to afford sophist acted
workforce management systems.
[0045] Embodiments have been disclosed herein. However, various
modifications can be made without departing from the scope of the
embodiments as defined by the appended claims and legal
equivalents.
* * * * *