US20100049576A1

US20100049576A1 - Dispatch and service support system

Info

Publication number: US20100049576A1
Application number: US12/261,684
Authority: US
Inventors: Christopher R. Wilson; Jeffrey R. Robbins
Original assignee: AT&T Intellectual Property I LP
Current assignee: AT&T Intellectual Property I LP
Priority date: 2003-07-15
Filing date: 2008-10-30
Publication date: 2010-02-25
Also published as: US20050015292A1; WO2005010656A2; WO2005010656A3; US7464046B2

Abstract

A service support system includes a service request interface, a dispatch system interface, a service assignment module, and a request verification module. The service request interface is configured to communicate with a service request system. The dispatch system interface is configured to communicate with a dispatch system. The service assignment module is configured to assign a service request to a technician from a pool of available technicians based at least in part on a historical technician performance statistic. The service request is received via the service request interface. The service assignment module notifies the technician of the service request via the dispatch system interface. The request verification module is configured to acquire the service request through at least one of the service request interface and a service order provisioning and billing system.

Description

CLAIM OF PRIORITY

This application is a continuation application of, and claims priority to, U.S. patent application Ser. No. 10/619,944, filed Jul. 15, 2003, which is expressly incorporated herein by reference in its entirely.

FIELD OF THE DISCLOSURE

This disclosure, in general, relates to dispatch and service support systems.

BACKGROUND

Various industries utilize mobile technicians to install, repair, and maintain remote equipment. Such industries include phone companies, cable companies, gas companies, general service repair companies, and other dispatch oriented service companies. One particular example is a phone company that manages a large fleet of service personnel and a large inventory of circuit loops, telephone numbers, switching equipment, and telecommunications equipment.
Difficulties arise in efficiently dispatching technicians with the appropriate skills to a specific job location. This problem is exacerbated by the continual influx of service requests. In addition, each service request may involve changes in multiple locations requiring multiple technical skills and interfacing with multiple support systems. Therefore, an improved dispatch and service support system would be desirable.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary service support system architecture.

FIG. 2 depicts an exemplary service support system.

FIG. 3 depicts one specific embodiment of service support system architecture.

FIG. 4 illustrates an exemplary method to facilitate service dispatch.

FIG. 5 illustrates an exemplary method of monitoring order status.

The use of the same reference symbols in different drawings indicates similar or identical items.

DETAILED DESCRIPTION

The disclosure is directed to a service support system. The service support system includes a service request interface, a dispatch system interface, and a service assignment module. The service request interface is configured to communicate with a service request system. The dispatch system interface is configured to communicate with a dispatch system. The service assignment module is configured to assign a service request to a technician from a pool of technicians based at least in part on a historical technician performance statistic. The service request is received via the service request interface. The service assignment module notifies the technician of the service request via the dispatch system interface.
The disclosure is also directed to a workforce administration system. The workforce administration system includes a logic interface, a dispatch interface, and a dispatch module. The logic interface is configured to communicate with a statistical dispatch logic module. The dispatch interface is configured to communicate with a technician dispatch system. The dispatch module is configured to accept dispatch instructions associated with a service order via the logical interface to the statistical dispatch logic module and is configured to transfer service instructions associated with a service order via the dispatch interface to the technician dispatch system.
The disclosure is also directed to a dispatch control system. The dispatch control system includes a mobile technician interface, a frame order management system interface, an order status reporting interface, and an order status monitoring module. The mobile technician interface is configured to communicate with a mobile technician monitoring system. The frame order management system interface is configured to communicate with a frame order management system. The order status monitoring module is configured to access the mobile technician monitoring system via the mobile technician interface to receive service order completion data associated with a service order. The order completion monitoring module is configured to access the frame order management system via the frame order management system interface to receive frame order completion data associated with the service order. The order status monitoring module is configured to provide an order status associated with the service order via the order status reporting interface.
The disclosure is directed to a service order status interface. The service order status interface includes at least one web page configured to access an order status monitoring module. The order status monitoring module is configured to access the technician monitoring system via a technician interface to receive service order completion data associated with a service request. The order status monitoring module is configured to access a frame order management system via a frame order management system interface to receive a frame order completion data associated with the service request. The at least one web page is configured to display a service request status associated with the service request. The service request status is provided by the order status monitoring module and is associated with the service order completion data and the frame order completion data.
The disclosure is directed to a method to facilitate service dispatch. The method includes communicating with a service request system via a service request interface to receive a service request, assigning the service request to a technician from a pool of technicians based at least in part on an historical performance statistic, and notifying the technician of the service request via a dispatch system.
The disclosure is also directed to a method of monitoring order status. The method includes accessing a mobile technician monitoring system via a mobile technician interface to receive service order completion data associated with a service request, accessing a frame order management system via a frame order management system interface to receive frame order completion data associated with the service request, and providing an order status associated with the service request via the order status reporting interface.
FIG. 1 depicts an exemplary embodiment of a service support architecture. Such architecture may be useful in dispatching technicians, managing service request mitigation, and reporting the status of service orders and requests. The architecture includes a service support system 102. The service support system 102 may be coupled to a service request system 104, a dispatch system 106, a user interface 108, a frame management system 110, a status interface 112, a geo-location system 114, a technician scoring system 116, a statistical knowledge interface 118, and a service order provisioning and/or billing system 120. However, the service support system 102 may or may not be coupled to some, all or various combinations of these systems.
The service support system 102 may be a computer server system having one or more processors, various memory and storage systems, and program modules. These elements may function together to provide functions such as service request verification, service request assignment, completion logic, and reporting functions, among others. In one exemplary embodiment, the system is a Unix based system using an Oracle® database.
In one exemplary example, the service support system 102 may interface with a service request system 104 to acquire service orders or requests. The service request system 104 may, for example, be a workforce administration system (WFA/C) or service order and provisioning systems having service request capabilities such as Service Order Retrieval and Distribution (SORD) and Ameritech Service Order Negotiation (ASON). The service support system 102 may process these service requests and determine which technician should be assigned the service request. This determination may be made in part based on a technician's capabilities and an historical statistic such as a particular technician's average time to perform such tasks as required by the service request or service order. The service support system may then dispatch the technician using a dispatch system 106. The dispatch system may be a mobile dispatch interface such as a Global Craft Access System (GCAS). Alternately, the dispatch system 106 may be a Workforce Administration Dispatch-Out system (WFA/DO) having a further interface to a mobile technician interface. The dispatch system 106 may also include internal dispatch systems such as the Workforce Administration Dispatch-In system (WFA/DI), Frame Operations Management Systems (FOMS), or other similar systems directing technicians to work on equipment such as central office equipment or regional office equipment.
The dispatch system 106 or a related system may also provide feedback to the service support system 102 associated with completion or status of service order requests. This data may be used in conjunction with other data to determine technician efficiency scores. Technician efficiency scores may be stored in a technician scoring system 116.
A user interface 108 may be provided for the service support system 102 to monitor and track the performance of the service support system, assign technicians, provide workforce and work load statistics, determine appointment clocks and windows, report service order/request status, manage custom reports, manipulate assignment parameters, and manage other data. The user interface 108, in one exemplary embodiment, may be a web-based interface. The user interface 108 may include Java components.
The service support system 102 may also communicate with other systems, such as a frame management system 110, a status interface 112, a geo-location system 114, a technician scoring system 116, a statistical knowledge interface 118, and a service order provisioning/billing system 120. The frame management system 110 may be associated with the management of central office equipment. The frame management system 110 may, for example, be the Frame Operations Management System (FOMS). Aspects of the service orders may require manipulation of central office equipment. The interface with the frame management system 110 provides a method for directing the manipulation of central office equipment management systems and receiving status information associated with the request.
A status interface 112 may also be provided to the service support system 102. In the current regulatory environment, Competitive Local Exchange Carriers (CLECs) desire access to status information associated with the Competitive Local Exchange Carrier (CLEC) service orders that are to be performed by the Incumbent Local Exchange Carrier (ILEC). The status interface 112 may take various forms such as a provisioning order status system (POS) or a statistical reporting system such as a Local Access Service Request (LASR) system. The status interface 112 may, for example, be a web-based interface and may include Java components.
The service support system 102 may also have access to a geo-location system 114. The geo-location system 114 may, for example, supply location data associated with technicians. Such a system 114 may include a Global Positioning System (GPS) locater associated with service delivery vehicles. Location data from the geo-location system 114 may be used in determining efficient assignment of technicians to a particular service request. Such location data may be used in conjunction with technician capabilities, historical technician statistics, and associated costs to determine which technician may be preferably assigned to a particular service request.
A statistical knowledge system 118 may also be coupled with the service support system to gather statistical information associated with mitigation of service requests, trouble tickets (problem service orders), workforce and work load statistics and other statistics useful in decision support. Such systems may include statistical systems for providing CLECs with statistical data associated with service request completion such as an LASR system. Alternately, a statistical knowledge system 118 may include a corporate decision support system or a statistical system for analysis of service performance in the mitigation of trouble tickets and order completion such as the Acquisition of Statistical Knowledge Made Easy System (ASKME).
Service order provisioning (SOP) and billing systems 120 may also be coupled to the service support system 102. These systems may also interface with other billing systems and service request systems. Such systems include SORD, ASON, and SONAR, among others. These systems may interface with billing systems such as CRIS and CABS. In one exemplary embodiment, service orders may be entered into an SOP system 120. The service orders may be transcribed and entered into a service request system 104. The service support system 102 may access the SOP/billing system 120 and compare original service order/request images with those received through the service request system 104. In this manner, the service support system may function to further verify service requests and orders.
The service support system 102 may also take into account the various statistics associated with workforce and work load availability. The service support system 102 may utilize these statistics to determine available windows for appointments. These windows may be provided to various service request scheduling systems, such as the Loop Maintenance Operation System (LMOS FE) or Interactive Voice-Response system (IVR) that permit the scheduling of service calls. The user interface 108 may also permit manipulation of appointment windows and other parameters associated with appointment window determination that may be used in the determination of next available appointment windows.
FIG. 2 depicts an exemplary embodiment of a service support system 200. The service support system 200 includes processors 202, memory 204, interfaces 206, modules 208, and storage 210. The service support system may take the form of various computational devices or a combination of computational devices operating under operating systems such as Windows and Unix. In one exemplary embodiment, the service support system 200 includes server side devices including Unix servers, Oracle® databases, MQ Series queue processes, and Websphere® web server software. The service support system 200 may communicate with other devices such as other server systems or client side personal computers having a web browser.
The interfaces 206 may take various forms such as terminal emulators, screen scrapers, application interfaces, database calls, command line entries, and web-based and/or Java-based interfaces, among others. The interfaces 206 may include a service request interface 212, a dispatch system interface 214, a geo-location interface 216, a status interface 218, a frame system interface 220, a scoring interface 222, a statistical knowledge interface 224, a billing system interface 226, a user interface 228, and an inventory provisioning interface 230. The service request interface 212 may interact with a service request system or a service order provisioning system. In one exemplary embodiment, the service support system 200 acquires service orders and service requests from a service request system such as a WFA/C via the service request interface 212. In an alternate embodiment, service requests and service orders may be acquired from a service order provisioning system via the service request interface 212. The service orders and requests may come as word documents, text documents, delimited text files, fielded files, or data files. In one exemplary embodiment, the service support system 200 may interface with a service order provisioning system and a service request system. The service request image file from the service order processing system may be compared with a service order or request from the service request system such as WFA/C. In this manner, service requests may be further authenticated or verified.
The dispatch system interface 214 may interact with a dispatch system. This interaction may be directed with a mobile technician system such as a Global Craft Access System (GCAS). Alternately, the dispatch system interface 214 may interact with a Workforce Administration System such as a WFA/DO system, which in turn interacts with the mobile technician system. The dispatch system interface 214 may also interact with internal dispatches such as a WFA/DI system. Using the dispatch system interface, the service support system 200 may assign service orders to particular technicians and in some embodiments, acquire completion data or data associated with the service order request.
The service support system 200 may also include a geo-location interface 216. The geo-location interface 216 may interact with a geo-location system such as a Technician Reporting System (TRACE). The technician reporting system may provide location information such as global positioning locations. The service support system 200 may then use this information in conjunction with other technician-associated data to determine which technician should be assigned a particular service order.
The status interface 218 may permit access by outside order status systems, or may provide a web-based interface into the service support system 200. The status interface 218 may also include a Java component. In one exemplary embodiment, CLECs may access order status information through a web interface. In an alternate embodiment, status information may be passed to a service order processing system such as SORD or ASON or a service order reporting system such as Local Access Service Request (LASR).
Mitigating and processing service orders and service requests may involve manipulations to frames and central office equipment. A frame system interface 220 may be provided to access systems such as a Frame Operations Management System (FOMS). Task information associated with a service order may be transmitted to the FOMS system and information about completion of the task or status of the task may be transmitted to the service support system 200 through the frame system interface 220. Other systems involving internal dispatches may also be provided interfaces such as the WFA/DI. Furthermore, inventory tracking systems and assignment systems may be provided similar interfaces.
As tasks associated with service orders are complete, job statistics associated with technicians may be developed and stored. In one exemplary embodiment, a scoring interface 222 is provided which may interact with technician scoring systems such as Techscore that store technician efficiency data. Other statistics associated with job completions, trouble tickets, service order completions, and incorrect service requests may be stored in other systems. In one exemplary embodiment, a statistical knowledge interface 224 is provided, which may access regulatory and corporate management systems such as ASKME and DSS. These systems provide corporate and regulatory access and oversight to the service order and dispatch process.
A billing system and service order processing system interface 226 may be provided for accessing service order processing systems and billing systems. In one exemplary embodiment, billing systems may be accessed directly. Alternately billing systems may be accessed via the service order processing systems. For example, CRIS/CABS systems may be accessed through SORD, ASON, or other systems. The service support system 200 may utilize the billing systems interface 226 to confirm completion of a service order and facilitate the billing associated with that service order.
The system may also provide a user interface 228. The user interface may be used to provide reporting functions, parameter and setting manipulation, job and service request monitoring, workforce and work load monitoring, technician assignment, appointment window or clock parameter manipulation, and report customization. The user interface 228 may, for example, take the form of a web-based user interface such as web pages. The user interface 228 may also include java components. In one exemplary embodiment, the user interface 228 may be used to manipulate appointment window parameters. In another exemplary embodiment, the user interface 228 may be used to manipulate technician assignment. In a further exemplary embodiment, the user interface 228 may be used to provide local and regional reports. These local and regional reports may, for example, be customizable through the selection of search criteria and reported data. In another example, the user interface 228 may be used to assign technicians to areas or regions for specified times. Changing the assignment of a technician affects the workforce and work load determinations in a given area, which may alter appointment clocks and task or service order assignment.
The system may also include an inventory-provisioning interface 230. This inventory-provisioning interface 230 may permit the tracking and manipulation of inventory and assignment data through systems such as Loop Facility Assignment Control System (LFACS) and SWITCH. An inventory-provisioning interface 230 may be provided directly to LFACS and SWITCH, or, in an alternate embodiment, may be provided through other systems such as a Facts Internal Resolution Technology System (FIRST). In one exemplary embodiment, screen scraping techniques may be used to access and manipulate data in the LFACS and SWITCH systems.
The service support system 200 may also include various storage systems 210. These systems may include databases such as an Oracle® database. Databases may be provided for technician data 240, technician capability data 242, workforce statistical data 244, work load statistical data 246 and service request data 248. The technician data 240 may include data such as the assigned regional location of a technician, the geo-location of a technician, personal technician data, schedule data, and availability data. The technician capability data 242 may be separate from or combined with the technician data 240. The technician capability data 242 may include statistical data associated with the past performance of technicians for given tasks and may include default assumptions for task having little associated data. The statistical data may include average time on a task, maximum or minimum times, mean or median times, default assumptions and binary input regarding technician ability. In one exemplary embodiment, the technician capability data 242 and statistics may be used in determining assignments of service requests. For example, a mean or median completion time associated with a specific task associated with a service request may be used in determining whether a particular technician should be assigned to a service request.
The storage 210 may also include workforce statistical data 244. This data may be aggregate workforce data collected over an extended period of time. In addition, work load statistical data 246 may be included, which includes statistical data associated with work load and service orders accumulated over a period of time. The work load statistical data 246 may include information about past service request volume. Similarly, the workforce statistical data 244 may include information about previous workforce availability. Together the workforce and work load statistics may be useful in forecasting work load volume and work force utilization.
The storage 210 may also include service request data 248. The service request data 248 may include service request documents and images, dispatch information associated with service requests, task and job data associated with service orders, and status data associated with service orders. The service request data 248 may be useful in supplying service status, dispatching service orders, and determining billing information.
The modules 208 may take the form of scripts and programs associated with the service order support system 200 function. The modules 208 may be separate programs or may comprise routines within, a program or scripts and queries within a database. The dispatch/assignment module 232 processes a service request received via the service request interface 212 to determine which tasks are associated with the service request. The dispatch/assignment module 232 may determine to which technicians to assign the tasks associated with the service order. In making this assignment, the dispatch/assignment module 232 may take into account technician capabilities, statistical information associated with expected task completion times, and technician location relative to job location. In another embodiment, technician information, location, and the task may have a cost weighting associated with them to aid in determining technician assignment or help in monitoring dispatch/assignment module 232 performance. The dispatch assignment module 232 may access a geo-location system to determine the location of a technician through the geo-location interface 216. In one exemplary embodiment, the dispatch/assignment module 232 may determine expected job completion times associated with a technician based on technician statistics and use that information in conjunction with a geo-location to determine which technician may be assigned to a specific task. For example, based on technician statistics, a technician A may be expected to complete a first task five minutes hence and have an expected travel time to the next task of ten minutes. Technician B may have completed a task but be expected to travel 20 minutes to the next task. In one case, the dispatch/assignment module 232 may assign the task to the technician A while leaving technician B idle or assigning a subsequent task to technician B.
The order status module 234 may acquire information from technicians, Frame Operations Management Systems (FOMS), and other systems such as WFA/DI and WFA/DO to determine the status of an order. In one exemplary embodiment, tasks associated with the service order may include manipulation of frames and central office equipment as well as tasks utilizing a mobile service technician. In theses situations, before a service order should be reported as complete, both the central office equipment tasks and the mobile service order tasks should be complete. The order status module 234 may delay reporting completed status until all the expected completion data is acquired. The service order module may interact with a dispatch system interface 214, a frame system interface 220 or an inventory provisioning interface 230 to acquire the appropriate information. Subsequently, the order status module 234 may communicate through a status interface 218, a billing system interface 226, a statistical knowledge interface 224, or a user interface 228 to communicate order status. In one exemplary embodiment, a web-based status interface 218 may access the order status module 234 to acquire service order status data associated with a CLEC.
Another module is the appointment clock module 236. In determining when incoming service requests are to be processed or in determining what appointment window to apply to incoming service requests, the appointment clock module 236 may monitor workforce statistical data 244, work load statistical data 246, technician data 240 and service request data 248 to determine what clock time to provide. The user interface 228 may also access the appointment clock module 236 to establish appointment window parameters. These parameters may include window size, among others. In addition, the user interface 228 may manipulate regional or area technician assignments, which may affect workforce availability and, thus, affect appointment clocks and windows. The appointment clock module 236 may interact with an LMOS system or an IVR system to automatically update appointment clock times and windows.
The service support system 200 may also include a request verification module 238. The request verification module 238 may, for example, acquire service requests through the service request interface 212 or an SOP/billing system interface 226. In one exemplary embodiment, the service verification module 238 may acquire a service request interface or image from a service order processing system and compare that to the service request acquired through a workforce administration control module (WSA/C). In this manner, errors acquired in the processing of service orders may be mitigated, preventing wasted dispatch time and facilitating quicker service order processing. The comparison may, for example, involve parsing the service order and the service order image to find and compare comparable fields.
FIG. 3 depicts an exemplary dispatch and service support system architecture. This exemplary system includes a centralized dispatch and service support system 302. The service support system 302 may have interfaces to the service order processing system 304, inventory and facility assignment systems (Service Order Analysis and Control (SOAC) 306, SOA 308, LFACS 310, SWITCH 312), interfaces to Frame Operations Management System (FOMS) 314, workforce administration control dispatch in and dispatch out systems 318, 316 and 322, Provisioning Order Status (POS) systems 320, Local Access Service Request (LASR) systems 324, Loop Maintenance Operating Systems (LMOS) 326, Local Service Management Systems 328, Techscore systems 330, Global Craft Access Systems (GCAS) 332, tech reporting systems 334, MARCH 336, Facts Internal Resolution Technology System (FIRST) 338, Decision Support Systems 340, and Acquisition of Statistical Knowledge Made Easy systems (ASKME) 342.
In one exemplary embodiment, the service support system 302 acquires service request document from the WFA/C system 318. This service request document may be compared with a service request image acquired from a service order processing (SOP) system 304. Service order processing system may include systems such as SORD and ASON. Further, these systems may be coupled with billing systems such as CRIS and CABS. Using technician capability data, and in some exemplary embodiments, geo-location data determined from the TRACE 334 system, the service support system 302 may assign tasks associated with the service request to particular technicians. This assignment may be sent directly to a technician system such as the GCAS 332 or may indirectly be provided to a technician through a legacy system such as WFA/DO 322 or WFA/DI 316. In addition, the service request may have tasks utilizing frame and central office equipment. The service support system 302 may transmit and receive information associated with frame tasks through the interface to the FOMS 314 system.
In preparation for the service requests or in reporting inventory and assignment changes, the service support system 302 may access systems such as LFACS 310 and SWITCH 312. This access may be direct or may be provided through systems such as FIRST 338. In one exemplary embodiment, the LFACS 310 and SWITCH 312 are accessed through a screen-scraping methodology. The service support system 302 may also access a Service Order Analysis and Control (SOAC) system 306. The SOAC 306 may act as an interface between the SOP systems 304 and the facility assignment systems such as LFACS 310. The SOAC 306 may translate USOC type information from the service orders into requests for needed facilities.
As tasks are completed, the service support system 302 may receive notification through the GCAS 332 or the FOMS system 314. As service order tasks are complete, the service order system 302 may store the status of completed tasks and the status of the service request as a whole. The status may be reported through a service order processing (SOP) system 304, in which case billing may be generated. The service support system 302 may also report status completes through a provisioning order status system (POS) 320 and a local access service request (LASR) system 324. The POS system 320 may be a web-based interface to provide CLECs with information associated service requests. The LASR system 324 may provide statistical data on service request completions associated with those service requests requested by CLECs.
In some cases, service requests may involve the portability of local telephone numbers. In this case, the service support system may interact with a Local Service Management System (LSMS) 328 to assign and dispense local telephone numbers. Furthermore, the assignment and dispatching of local numbers may be reported through a MARCH system 336. In some cases, status regarding unused telephone number pools may be reported to a CLEC through the LASR system 324.
As service orders are received and processed and technicians work on the service orders, statistical data may be gathered and associated with the service orders and the technician performance. Some of this data may be stored in the service support system 302. Technician related efficiency data may be stored in systems such as a Techscore system 330. Data associated with trouble tickets and order completion may be recorded through a corporate statistical system such as ASKME 342 or regulatory accessed systems such as DSS 340. Those service orders having problems or difficulties requiring manual assistance may be reported to a FIRST system or the MARCH system 338.
In addition, the service support system 302 may perform workforce and work load calculations to determine appointment windows in which service may be provided. These appointment windows may be sent to a loop maintenance operating system (LMOS) 326 or directly to an interactive voice response (IVR) system through which customers and requesters of service orders may be provided with an expected appointment window for handling a service request. In one exemplary embodiment, a requester of service may be provided with options based on anticipated workforce and work load calculations.
FIG. 4 illustrates an exemplary method to facilitate service dispatch. At step 402, the service support system communicates with a service request system. The service request system may be an SOP system or a WFA/C system. The service request is assigned to a technician, as shown in step 404. The technician may be one in a pool of available technicians. The pool of technicians may be further subdivided into service areas or regions with boundaries that may be hard or soft geographic boundaries. Further, technicians may be assigned to differing regions at different times. The assignment of a task to a particular technician may be determined through a business logic that considers factors such as current technician location, technician skill sets, statistic data associated with the technician, and workforce and work load projections. The statistical data may, for example, be average, maximum, or minimum completion times associated with tasks associated with the service request. In one exemplary embodiment, the system may check travel time and expected completion times to determine which technician to assign. For example, technician A may be idle and located 20 minutes from the service location. Technician B may be 10 minutes from the job and be expected to finish a current task in 5 minutes based on statistical job completion date. Depending on the weighting of travel time, the service support system may assign the task to technician B and assign another service request to technician A.
The service support system may notify the technician of the service request, as shown in step 406. This notification may be through a mobile technician system. Alternately, the service support system may send dispatch information to a workforce administration system such as a WFA/DO or DI system, which, in turn, sends the dispatch information to the technician via a mobile technician system.
The service support system may also interface with the mobile technician system to acquire completion data associated with the service request, as shown in step 408. The completion data may be an indication that tasks associated with the service request have been completed. Alternately, data indicating trouble with the service request may be sent via the mobile technician system to the service support system. The service support system may also interface with other systems such as internal dispatch systems and frame order management systems to acquire completion or trouble ticket data.
The service support system may also report the status of the service request, as shown in step 410. This report may be in the form of a web-based interface and may have a Java component. The interface may be accessible by CLECs, for example. Alternately, the service support system may report status to various statistical systems, SOP/billing systems, and regulatory systems.
FIG. 5 illustrates an exemplary method to monitor order status. A mobile technician monitoring system is accessed by the service support system, as shown in step 502. Completion data or trouble ticket information may be transferred to the service support system. In addition, a frame order management system is accessed by the service support system, as shown in step 506. The mobile technician monitoring system and the frame order management system may be accessed in various orders and more than once. The service support system may also provide an order status, as shown in step 508. The order status may be provided through a web-based interface or to various statistical, regulatory, and SOP/billing systems. The order status may be shown as complete upon receipt of both the completion data from the frame order management system and the completion data from the mobile technician monitoring system.
The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments which fall within the true spirit and scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

Claims

1. A service support system comprising:

a service request interface configured to communicate with a service request system;

a dispatch system interface configured to communicate with a dispatch system;

a service assignment module configured to assign a service request to a technician from a pool of available technicians based at least in part on a historical technician performance statistic, the service request received via the service request interface, the service assignment module notifying the technician of the service request via the dispatch system interface; and

a request verification module configured to acquire the service request through at least one of the service request interface and a service order provisioning and billing system.

2. The service support system of claim 1, wherein the request verification module is further configured to compare a service request acquired from a service order processing system with a service request interface acquired through a workforce administration control module.

3. The service support system of claim 1, further comprising a statistical knowledge interface configured to access a statistical knowledge system configured to access regulatory and corporate management systems.

4. The service support system of claim 1, further comprising:

an appointment clock module configured to monitor one or more of workforce statistical data, workload statistical data, technician data, and service request data to determine at least one of a processing time and an appointment window to apply to the service request.

5. The service support system of claim 4, wherein the appointment clock module interacts with a Loop Maintenance Operation System or an Interactive Voice-Response system to automatically update at least one of the processing time and the appointment window.

6. The service support system of claim 4, further comprising:

a user interface configured to access the appointment window to establish appointment window parameters.

7. The service support system of claim 6, wherein the user interface is further configured to access the processing time and the appointment window by manipulating technician assignments.

8. The service support system of claim 1, further comprising:

a geo-location interface configured to access a geo-location system, the geo-location system indicating a location of the technician and wherein the service request is assigned based at least in part on the location of the technician and further comprising a service request status interface to access status data associated with the service request.

9. The service support system of claim 1, further comprising a service request status interface implemented as a web-based interface.

10. The service support system of claim 9, wherein the service request status interface is accessible by a competitive local exchange carrier.

11. The service support system of claim 1, further comprising:

a frame system interface configured to access a frame operation management system wherein the service assignment module is configured to transfer frame related service requests to the frame operation management system via the frame system interface.

12. The service support system of claim 1, further comprising:

a scoring interface configured to access a technician scoring system, the technician scoring system storing an efficiency score associated with the technician.

13. The service support system of claim 1, further comprising:

a billing system interface configured to communicate with a billing system, the billing system to receive completion data associated with the service request.

14. A method comprising:

acquiring a service request document from a work force administration control system, the service request document having associated therewith one or more tasks;

comparing the service request document with a service request image acquired from a service order processing system to verify the service request document;

assigning each of the one or more tasks to a corresponding technician based upon technician capability data and geo-location data received from a geo-location system;

providing assignment data to a dispatch system, the dispatch system having a dispatch system interface; and

notifying each of the corresponding technicians of an assignment via the dispatch system interface.

15. The method of claim 14, wherein the service order processing system is one of a Service Order Retrieval and Distribution system and a Service Order Negotiation system.

16. The method of claim 14, wherein the dispatch system interface is a mobile dispatch interface.

17. The method of claim 16, wherein the mobile dispatch interface is a Global Craft Access System

18. The method of claim 14, further comprising acquiring completion data via the dispatch system interface.

19. The method of claim 14, further comprising accessing inventory and assignment data via an inventory-provisioning interface.

20. The method of claim 19, wherein the inventory and assignment data is accessed through a Loop Facility Assignment Control System via a screen-scraping technique.