The disclosure below relates to troubleshooting tools for networks.
Users of network systems invariably run across difficulties with connectivity or the availability of certain services for their account. Service providers of networks expect to receive a number of service calls and questions relating to connectivity or responsiveness available at certain user accounts and these networks and service providers need to provide troubleshooting solutions in an efficient manner. With larger networks or service providers, the challenge is not only to quickly and correctly answer questions and provide solutions to problems, but also to proficiently handle the dissemination of trouble tickets to the appropriate technician in the system and manage the administrative overhead. The administrative overhead may include the assignment of particular trouble tickets or tasks among departments at the network or service provider, and the record and audit trail of which customers have been assisted or still require follow up assistance.
Even with a single diagnostic tool available to network and service provider technicians, there is the possibility of inefficiency or error in handling trouble tickets. When multiple diagnostic tools are available, the possibility of user error and efficiency problems can increase. This is particularly true when there are a number of network technicians located in various geographical regions who may each have their particular preference as to which diagnostic tool to use and in what order. In such an environment, the burden to networks or service providers for updating troubleshooting procedures, whether on the use or introduction of particular diagnostic tools or the communication format that should be used internally to efficiently transfer trouble tickets or tasks, can be tremendous.
Accordingly, there is a need to provide improved workflow management to network and service provider troubleshooting.
In order to address the need for improved management of network and service provided troubleshooting, a telecommunication diagnostic system for troubleshooting telecommunication user accounts is disclosed. In one aspect, the system may include a workflow processor configured for communication with an account database containing telecommunication user account information and for communication with a plurality of telecommunications diagnostic applications. An interface application in communication with the workflow processor may be configured to provide instructions for generating a graphic user interface at a client device accessing the workflow processor. A workflow procedure database in communication with the workflow processor may also be included. The workflow procedure database may have procedures for troubleshooting each of a number of predetermined trouble report categories typically received for telecommunication user accounts. In one embodiment, each of the procedures includes instructions and workflow integrated links to at least one of collection of telecommunications diagnostic applications relating to the instructions, where each step of the selected workflow may be sent to the client device for display on the graphic user interface.
In another aspect, a method for troubleshooting telecommunication user accounts is described. In response to receipt of a technician login query from a client device, a workload is retrieved from a telecommunications user account database, where the workload comprises telecommunication user account information for telecommunication user account trouble tickets assigned to the technician. Initial testing of telecommunication user accounts retrieved in the workload is then automatically executed and the telecommunication user account information and results of the initial testing for a selected one of the plurality of telecommunication user accounts may be sent to the technician at the client. A troubleshooting workflow, from a predetermined collection of workflow options, is suggested to the technician based on the telecommunication user account information and the initial testing results. In one embodiment, step-by-step instructions associated with the suggested workflow are transmitted to the client. The instructions may include one of more links to pre-selected diagnostic testing applications relating to the instructions.
According to another aspect, an article of manufacture, such as a computer readable medium, may be provided containing instructions for executing the steps of the method noted above. Additional features may include, instructions for automatically prioritizing an order of the plurality of telecommunications user accounts assigned to the technician based on at least one priority parameter, such as a length of time that a trouble ticket for the telecommunications account has waited for attention. The computer readable medium may also include instructions for automatically updating an activity log associated with the telecommunications user account with diagnostic test activity and results from the workflow. Also, the instructions may include an option for exempting the technician from following the automatically suggested workflow upon receipt of an exemption request from the technician.
In order to provide for improved efficiency and uniformity in network troubleshooting, and to permit rapid and transparent process upgrades to preferred troubleshooting workflows, a system 10 is disclosed in
The workflow server 12 receives updates on WFA reporting applications from a workflow process reporting module 16. Suitable reporting applications may include Open Query System (OQS), Symposium ACD or other known Web-based reporting tools. A test system server 18, which may include a number of discrete, imbedded test systems or Internet links to remotely stored testing programs, communicates with the workflow server 12 over one or more communication lines. The test systems may include tests for network circuit integrity and responsiveness. Examples of testing applications that may be included in the test systems 18 may be Circuit Manager, COPPERMAX, BROADBAND TOOLS, MLT, and REDBACK TOOLS. The system 10 includes one or more remotely located clients 20 in communication with the workflow server 12. In one embodiment, the client may be a personal computing device such as a personal computer with standard Internet web browser, which may communicate with the workflow server 12 at a standard IP address. In this embodiment, the client device would not need any customer data or testing applications stored locally. A network center technician (NCT) or other user at the client 20 would access all customer information and testing procedures via the workflow server 12.
One embodiment of a workflow server 12 as shown in
In one embodiment, the external reporting module 24 parses through the work requests, commonly known as trouble tickets, obtained from the customer database 14 and prioritizes the workload for each respective NCT so that NCTs accessing their workload information from a client 20 will automatically receive that workload prioritized with the highest priority trouble ticket coming first. The prioritization and distribution of workload among NCTs may be modified by the service provider controlling the workflow server 12. Examples of prioritization methods for prioritizing the trouble tickets assigned to an NCT include ranking the trouble tickets by the time a customer account has waited for attention, the number of inquiries received for a customer account, the type of account (e.g., business or residential), or any other field available in the customer account database.
The communications module 22 also receives information from an internal reporting module 26 at the workflow server 12 that monitors and provides overall statistics of the progress of NCTs and the status of individual trouble tickets. For example, the internal reporting module 26 may be configured to collate and distribute statistics such as how many trouble tickets were handled on any given day by all NCTs, a specific NCT, NCTs of a particular geographical region or business unit and so on. Administrators for the troubleshooting system 10 may then adjust methods and procedures if trends in NCT activity indicate possibilities for improvement.
The testing interface 28 of workflow server 12 may be provisioned to communicate with diagnostic tools stored at the test systems server or accessible through the test systems server 18 in communication with the network 10. The testing interface module 28 facilitates remote testing of circuits, processes, and processing of test results received from the various diagnostic tools in the test systems 18. The testing interface module 28 also retains testing information and provides for consistent interpretation and logging of test results. The testing interface module 28 processes and stores client-based and automated testing results from the customer database log. The customer database log, in one embodiment may be a WFA4/C OSSLOG storing a complete log of customer service and status information in WFA format. The workflow server 12 also stores instructions for generating a graphic user interface 30 for transmission to clients 20 when a user, such as an NCT, wishes to access the various diagnostic tools and reporting information from the workflow server 12.
One advantage of the workflow server applications is the combination of access to all testing tools through one interface. This single interface reduces the workload on an NCT by, for example, removing the need to type in information or copy and paste information between separate systems multiple times during the processing of a particular trouble report. The modules in the workflow server 12 may be implemented via a graphic user interphase that calls JAVA or VB script functions to launch applications at the workflow server 12. The Web-based front-end allows the back-end applications at the workflow server to parse and summarize data in a manner similar to web-based applications. For example, all authentications for users such as NCTs at a client 20 may be handled by scripts transferred through the GUI scripts passed to a client 20 by the communications module 22. A first time user would be queried to enter the various passwords to each of the separate diagnostic tools test systems 18, and to the workflow server 12 itself, when he logs into the workflow server from a client 20. This user profile is then stored in a user profile database 32. The user profile for a particular NCT or other user may then be accessed in subsequent session through a single password to the workflow server 12. In this manner, all security and password handling may be managed at the workflow server based on the single workflow server login. The functionality of the modules of the workflow server level may be implemented in any of a number of programming languages. In one embodiment, the workflow server 12 is programmed in Perl and is configured to work with a customer database provisioned in IMSC65 WFA4-C format such as the WFA system software available from Telcordia Telecommunications, Inc.
Referring to
Once a trouble ticket is selected by the technician, the workflow server automatically suggests to the technician one of a predetermined number of workflows stored in the workflow database 30 based on the information available on the trouble ticket and from the initial testing (at step 42). The initial customer account complaints trigger the automated workflow selection. However, if initial test results do not match the customer account complaint listed in the trouble ticket, the workflow server highlights the difference and suggests that the technician use the workflow that best matches the test results. The automatically selected workflow guides the technician through step-by-step questions and provides instructions for testing and obtaining further information. The workflow also automatically executes diagnostic routines, or presents links to these routine to the NCT, from one or more of the applicable diagnostic applications on the test systems server (at step 44). The customer database 14 is updated with the activity log and data of the troubleshooting efforts as the workflow proceeds (Step 46). Depending on the workflow automatically selected for the particular trouble ticket guidelines for customer, contact with the internet service provider (ISP) or other facility, and final disposition of a trouble ticket are presented to the technician in the step-by-step manner (at step 48). Further disposition alternatives for the trouble ticket may include, but are not limited to, referral to another department for assignment to a field technician to address a line problem, escalation of the trouble ticket if diagnostic applications do not solve the problem, and closing of the trouble ticket if the NCT was able to fully resolve the problem on the customer account identified in the trouble ticket. For each of the disposition options, the workflow server 12 may pre-populate trouble ticket disposition forms designated for the specific type of disposition relevant to the trouble ticket with some or all of the necessary customer account information and test results. The forms may be HTML forms or other types of forms accessible from the external reporting module 24 in the workflow server and retrieved automatically for, or manually by, the workflow server as part of the selected workflow.
User accessible screens of the graphic user interface available at the client 20 may be seen in
Referring to
The initial testing screen 70 includes technician procedure information 72 that advises the technician review the network provisioning and record keeping information maintained on customer accounts (e.g. customer profile including connection speed for a customer's telecommunication user account) and any automated initial testing that is desired, and post a summary of those results. Examples of initial automated tests include loop length, line voltage, grounding and other related circuit characteristics. The automatically selected workflow path 74 that has been selected by the workflow server based on the initial test results and telecommunication user account information is presented in a pull down menu of available workflow paths for NCT use. If a technician wishes to change a workflow from the recommended path, the change workflow button 76 on the graphic user interface allows technician to do so. As shown in
Once the workflow has been automatically selected by the workflow server based on the initial tests run by the workflow server 12, specific guidance instructions will be presented to the technician according to the selected workflow stored in the workflow database 30. The NCT will be directed to answer yes or no to specific questions and portions of the various applications of the test systems 18 will be accessed by the workflow server to provide the technician with test result data as the workflow progresses. The NCT will also be prompted to contact the customer reporting the problem in certain of the workflows.
Referring
In addition to workflows allowing the NCT to work on troubleshooting problems without customer contacts, there may be instances where customer action is necessary in order for the NCT to analyze the problems that may be occurring at the customer's CPE.
For each of the pre-customer contact workflows of
Additionally, the integration of a workflow database, such as WFA, within a single graphic user interface created at client device 20 accessing the workflow server 12 helps to reduce any need for re-keying of information between disparate diagnostic tools and internal administrative forms. For example, when an NCT reaches a phase of his review of a particular customer's DSL problem, there would likely be a hand-off to other offices within an organization, for example field technicians, to dial with the problem that has been diagnose through the workflow. The forms and communication protocols for transmitting this information may be streamlined through the single graphic user interface produced at a client. Furthermore, these centralized forms and procedures for internal communication and trouble ticket handoff may also take advantage of the integration with the customer and workflow database to prepopulate forms and provide centralized updating capabilities so that separate offices do not require separate copies of upgrades or changes to the procedures and forms.
In addition to the example workflows shown in
Examples of embedded diagnostic tools that may be accessed by the workflow server at appropriate points in the predetermined workflows include Broadband Tools (BBT), ATAS, in other applications that perform tasks such as physical layer testing via applications such as COPPERMAX or MLT, logical layer testing using COPPERMAX iCON or with embedded test capabilities in the network equipment (available, for example in REDBACK or JUNIPER router), and configuration testing through such systems as BBT, TOOL BAR or other record-keeping systems. Examples of remotely accessible tools from third parties that may be incorporated into a diagnostic routine such as supported through the work flow server include WFA AX, TOOL BAR, and COPPERMAX. WFA AX and TOOL BAR are applications available from Telcordia Telecommunications. COPPERMAX, and one of its variations with separate interface known as REACT, is available from Spirent Communications of Rockville, Md.
In alternate embodiments, one or more of the specific workflows may access all or only part of a single discrete diagnostic application. Also, it is contemplated that one or more workflows may not require any separate diagnostic tools and may only need to interface with the customer database to update the trouble ticket log to indicate the gathering of information for completion of the workflow steps for that particular workflow. In addition to the centralized ability to transparently update methods and procedures for the workflows through the central workflow server, it is contemplated that the graphic user interface may be updated or altered by allowing the system administrator to change the scripts sent to a client web browser when a client queries the workflow server. Also, while a DSL system is described in the context of the specification, the workflow server and methods may be applied to any one of a number of other telecommunication services requiring customer trouble diagnosis, or even call center management for calls from consumers of any of a number of products including insurance products or other retail products.
Any of a number of computer devices can be used for the workflow server 12, client 20 or other components of the network 10. Referring to
In a networked deployment, the computer system may operate in the capacity of a server or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The computer system 100 can also be implemented as or incorporated into various devices, such as a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. In a particular embodiment, the computer system 100 can be implemented using electronic devices that provide voice, video or data communication. Further, while a single computer system 100 is illustrated, the term “system” shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.
As illustrated in
In a particular embodiment, as depicted in
In an alternative embodiment, dedicated hardware implementations, such as application specific integrated circuits, programmable logic arrays and other hardware devices, can be constructed to implement one or more of the methods described herein. Applications that may include the apparatus and systems of various embodiments can broadly include a variety of electronic and computer systems. One or more embodiments described herein may implement functions using two or more specific interconnected hardware modules or devices with related control and data signals that can be communicated between and through the modules, or as portions of an application-specific integrated circuit. Accordingly, the present system encompasses software, firmware, and hardware implementations.
In accordance with various embodiments of the present disclosure, the methods described herein may be implemented by software programs executable by a computer system. Further, in an exemplary, non-limited embodiment, implementations can include distributed processing, component/object distributed processing, and parallel processing. Alternatively, virtual computer system processing can be constructed to implement one or more of the methods or functionality as described herein.
The present disclosure contemplates a computer-readable medium that includes instructions 124, or receives and executes instructions 124 responsive to a propagated signal, so that a device connected to a network 126 can communicate voice, video or data over the network 126. Further, the instructions 124 may be transmitted or received over the network 126 via the network interface device 120.
While the computer-readable medium is shown to be a single medium, the term “computer-readable medium” includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein.
In a particular non-limiting, exemplary embodiment, the computer-readable medium can include a solid-state memory such as a memory card or other package that houses one or more non-volatile read-only memories. Further, the computer-readable medium can be a random access memory or other volatile re-writable memory. Additionally, the computer-readable medium can include a magneto-optical or optical medium, such as a disk or tapes or other storage device to capture carrier wave signals such as a signal communicated over a transmission medium. A digital file attachment to an e-mail or other self-contained information archive or set of archives may be considered a distribution medium that is equivalent to a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a computer-readable medium or a distribution medium and other equivalents and successor media, in which data or instructions may be stored.
Although the present specification describes components and functions that may be implemented in particular embodiments with reference to particular standards and protocols, the invention is not limited to such standards and protocols. For example, standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions as those disclosed herein are considered equivalents thereof.
The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be minimized. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.
One or more embodiments of the disclosure may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any particular invention or inventive concept. Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b) and is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, various features may be grouped together or described in a single embodiment for the purpose of streamlining the disclosure. This disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may be directed to less than all of the features of any of the disclosed embodiments. Thus, the following claims are incorporated into the Detailed Description, with each claim standing on its own as defining separately claimed subject matter.
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.