Patent Application
20100031095
Problem ticket generation usually is the first step in today's IT process services management. This step is responsible for describing problem symptoms reported by customers. The problem ticket is the link between customer and the services infrastructure. Once a problem ticket is generated, it will be queued in the ticketing system and routed to an appropriate center or person for resolution. In practice, such a ticket can be generated either manually by call center personnel, or automatically via monitoring systems. In both cases, there are several fields to be documented in the ticket body from the party reporting the problem.
Quite often it has been the case that either the information found in the problem ticket is not adequate for resolution personnel or sometime the information is inaccurate. This is because: (I) fields in each ticket category are predetermined and hence fail to exploit any situational issues, (II) experience from previous tickets are not used in the preparation of similar future tickets, (III) there is no mechanism for the front-desk personnel to collect additional information beyond those available from the reporting party.
This invention provides a method and apparatus for enhancing ticket generation process by collecting more relevant information at the creation of a ticket for reporting a problem. Instead of using a fixed set of questions (which is typical), information for the ticket is dynamically generated. The dynamic information can appear in the form of questions which may account for (I) situational information (i.e., currently seen problems, current state of the user system etc), (II) knowledge gathered from previous tickets (i.e., what information are more useful for this type of symptoms etc.), and (III) information gathered proactively based on his/her experience by the agent. However the invention is not limited to these above mentioned factors. The core of the invention is that by making use of situational information both from current situation, and past scenarios, one can collect more useful information as opposed to using only predetermined questions or content.
In connection with one aspect the invention provides a method of preparing a problem ticket comprising:
receiving a problem report,
accessing a data collection based on said problem report to retrieve dynamic information related to said problem, and
forwarding said problem report and said dynamic information to comprise a problem ticket for resolution.
In connection with another aspect the invention provides a method of preparing a problem ticket comprising:
receiving a problem report, and at least one problem symptom;
accessing a data collection based on said problem symptom to retrieve dynamic information related to said at least one problem symptom, and
forwarding as a problem ticket said report and said dynamic information for resolution.
The invention also comprehends a system useful in enhancing a problem ticket comprising
a data collection comprising status of user system components and relationship between target system components
means responsive to data comprising a problem report for identifying components which are either identified in said problem report or are related components
means for extracting information respecting current status of said related components, and
means for forwarding said information respecting current status for inclusion in said problem ticket.
To describe the foregoing and other exemplary purposes, aspects, and advantages, we use the following detailed description of exemplary embodiments of the invention with reference to the drawings in which:
While the invention as claimed can be modified into alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the scope of the present invention.
The problem ID section 20 has regions wherein information can be provided for identification of the problem, identification of the problem history, problem type, whether new, transferred or resumed, entry date and time, user ID, the date and time in which the problem ticket was modified and a problem code.
The severity region 30 has a place where information can be provided for the original severity of the problem and a description section in which there is provision for a problem abstract, a problem resolution, the problem occurrence (date and time), and when the problem ticket was opened (date and time).
Finally, the customer code region 40 has information about the customer such as, when opened (date and time) the duration, the first call identification, the first contact identification, the first location identification, the location named and a group identification.
In some cases, the information for the problem ticket can be provided by a clerk conversing with the user or customer and receiving a problem report about a specific system which provides services to a user or users (herein after ‘user system’). Alternatively, an automated clerk can input the required information from the customer's verbalization of the problem report and a speech-to-text converter.
Regardless of how the information for the problem ticket is recorded, a major difficulty that we have discovered is that, while information input into a problem ticket will vary from ticket to ticket, the type of information which is input is the same for all tickets. In particular, the problem ticket records the observations and experience of the person making the report. It follows that the type of information which is now used to complete a problem ticket is limited to that provided by the customer or user concerning the user system.
As will be described, we believe that different problems requite different categories of information for an adequate description. Thus, in accordance with our invention the types of information that are recorded on one problem ticket will differ from the types of information that are recorded on another problem ticket.
The present invention attempts to both simplify the processing of the problem ticket and make that processing more powerful.
The mechanism to implement the advance provided by the invention is illustrated in
In many embodiments of the invention, the service request 105 will identify a trouble component. Starting with a trouble component we can identify a set of related components. The situational information 116 will identify the status of any related components which have failed, are not operating properly or are in an abnormal state. Those skilled in the art will realize that the status of related components is dynamic information in at least two respects. First different problem reports will usually deal with different components. In general the identity of a related component depends on the identification of a component involved in a trouble report. Accordingly, different trouble reports will usually involve different related components. Second different types of problems may suggest a different relationship between components so that even is the second problem deals with the very same component, a different problem with that component will suggest that a different relationship between the component and its related components will be important. In addition, the status of the related components, as a rule, will vary as a function of time. Thus there are at least two different dimensions to the dynamic quality of this information. One dimension is a changing complement of related components and the second dimension is the variation over time of the status of these components. In another embodiment of the invention, the situational information 116 will also relate to components which are related to the trouble component, but in this case, the identification of failed or abnormal related components is used to pose queries which will be provided to the customer or user.
In one specific embodiment, situational information 116 is dynamic information representing the status of components in the system or network. Certain components are connected so their status will affect the trouble component. If any related component is in a status other than normal, those related components in an abnormal status will be the basis for information or queries input to the problem ticket or customer. For example, if the trouble component is a Lotus Notes server, the abnormal status of network component which support the Lotus Notes server is information that will be important in the problem ticket. That information can be provided on the ticket either as a statement of fact, or as a query to elicit a response from the customer.
In still another embodiment, the dynamic information which is added to the problem ticket is derived from experience on previously resolved problem tickets. This may be implemented in several ways. For example, after problem resolution 109 on a first ticket, questions critical to the resolution of the problem are associated with the problem. Once critical questions are identified, key words in describing the problem symptoms are isolated. These key words are then correlated with a subsequent related problem or ticket, either as information or as a basis for questions.
More particularly, a set of key words are identified using this procedure for the resolution of problems associated with a particular trouble component. These key words are then correlated with new problems for the same or similar trouble components. The key words are then used either as information associated with the problem ticket, or as a basis for questions that appear in the problem ticket.
Instead of having a static set of questionnaires for the front-desk personnel to fill in, the questions for each problem ticket are dynamically changed based on the experience and feedback that are obtained from the problem resolution process. This method can be realized in the following steps.
In a first problem resolution process, mark questions critical to the resolution of the problem and associate them with the problem.
Once a problem is successfully resolved, identify the key words in describing the problem symptoms.
When a new problem arises, correlate the new problem to previous problems and select critical questions used in solving previous problems.
Once a trouble ticket is initially prepared at function 106, function 501 is executed to access dynamic information. The first step, 502 is to determine if the trouble component collected at function 106 has related data in the apparatus 115. If it does then function 504 is performed to extract the dynamic information related to the trouble component. This information is then used at function 507 for ticket resolution purposes. The dynamic information can be used in one or two ways, either the dynamic information can be added to the trouble ticket for assistance in the resolution of the trouble ticket. Continuing with the example, the dynamic information added to the trouble report for component a, will identify the related components b(a) and q(a) since they are in an abnormal state. Alternatively, the dynamic information can be used to pose additional questions to the customer reporting the trouble. In this case the customer or user can be asked if there are any observations about the operation of components b(a) or q(a).
On the other hand, assuming that function 502 does not determine that there is a common component information in the database, then processing steps to function 503 which determines if there is common symptom information in the apparatus 115. In the event there is, then function 504 is performed to extract the dynamic information from the apparatus 115. In this case, the dynamic information is information respecting resolved trouble tickets with one or more symptoms in common with the current trouble ticket. The dynamic information is then used in the resolution function 507. Once resolved critical questions in the resolved ticket are selected. Function 509 determines if any critical questions have been found. If critical questions have been found, then processing loops through function 506 to enhance the dynamic information in the database.
Information respecting the questions is collected by front-desk personnel from the reporting party.
While specific embodiments of the invention have been described it should be understood that this description is exemplary and not limiting. The scope of the invention is defined in the attached claims.
