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 
       [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™. 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™, 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™ 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  4 A-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&#39;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™ 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. 
         [0019]    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&#39;s profile may provide that only work tickets assigned to that technician should be displayed on the technician&#39;s user interface while a dispatcher&#39;s profile may provide that all technicians&#39; locations should be displayed on the dispatcher&#39;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™ 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&#39;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&#39;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.). 
         [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&#39;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&#39;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™ STREETVIEW of a location. For example, a user of any of the UIs shown in  FIGS. 4A ,  4 B, and  4 C 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&#39;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&#39;s response route, thereby both decreasing the technician&#39;s response time as well as potentially decreasing the technician&#39;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™ 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&#39;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.