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.

Description

RELATED APPLICATION DATA

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

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.

Some current workforce management systems provide map centric tools, such as the systems provided by CLICKSOFTWARE™. 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.

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.

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

FIG. 1 shows a functional block diagram of a workforce management system.

FIG. 2 shows an exemplary workforce management system architecture having a workforce management subsystem operatively coupled to a maps API.

FIG. 3A-B show exemplary user interfaces for interacting with a workforce management system.

FIG. 4A-D show additional exemplary user interfaces for interacting with a workforce management system.

FIG. 5 shows an exemplary computing device useful for implementing systems and performing methods disclosed herein.

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

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.

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.

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™, 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.

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.

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™ 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™), a smartphone 111 (e.g., an IPHONE™, a BLACKBERRY™, or an ANDROID™ 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.

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.

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™ MAPS services, ESRI™ ARCGIS™ online services, YAHOO!™ MAPS services, MICROSOFT™ BING™ 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™ ARCSDE™. 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™ 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.

For example, an embodiment may integrate a map into a webpage or application via the mapping services like GOOGLE™ MAPS API, BING™ 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.

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.

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.

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.

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™ MAPS API or ArcGIS™ 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.

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.

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.

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.

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.

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.

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.

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™ STREETVIEW, etc.).

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.

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.

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.

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.

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.

FIG. 4D shows an exemplary landscape UI 440 showing a GOOGLE™ 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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.