Patent Application
20180032971
This application claims the benefit of Indian Patent Application Serial No. 201641026094 filed Jul. 29, 2016 which is hereby incorporated by reference in its entirety.
This disclosure relates generally to incident ticket management, and more particularly to system and method for predicting relevant resolution for an incident ticket.
Advancements in the field of Information Technology (IT) have enabled digitization of various processes and activities in an industry or an enterprise. However, to derive the benefits of digitization the IT infrastructures need to run smoothly. Additionally, an efficient incident ticket management system is required to provide a quick resolution to any user queries or any incident ticket with respect to the IT infrastructures. The incident ticket may include an issue or a problem that a user face at the hardware and/or software level, or may also include a request for information on the hardware and/or software.
The incident ticket management system takes user queries as input (i.e., incident tickets), categorizes the tickets into various classes, and routes the tickets to the concerned team for resolution based on the classification. Typically, there are separate teams (e.g., L1 or L2 service team) to co-ordinate with end users and to resolve the incident tickets. Once the resolution is done, the ticket is closed. In current techniques, upon submitting the ticket, the system may pick the keywords or error symptoms from the ticket description so as to route the ticket to the concerned team and may also suggest similar type of past tickets (that are already resolved). This enables the resolution team to resolve the tickets at a faster rate.
However, the current system is limited in that it may not capture the error symptoms accurately such as when the same type of error symptoms is across multiple applications. For example, “browser issue” can be across different browsers such as Internet Explorer, Mozilla, Chrome, Opera, etc. Additionally, the current system is limited if the information provided by the user is unclear or incomplete. Further, the similar past resolved tickets suggested by the system may be off the mark in certain cases. For example, the suggestions for “Outlook not working” may be ‘Outlook configuration error’ or ‘Outlook memory error’. These recommendations may not provide any correct response for the exact issue the user may be facing. In all such cased, the resolution team has to come back to the user and clarify the problem. Thus, despite much advancement the resolutions provided by the support team are at times delayed and/or not accurate. These limitations, in turn, affect the overall functioning of the organization or the enterprise.
In one embodiment, a method for predicting a relevant resolution for an incident ticket is disclosed. In one example, the method comprises receiving the incident ticket. The method further comprises analyzing the incident ticket to determine at least one query Ngram and at least one category. The method further comprises determining a similar past incident ticket based on a comparison of the at least one query Ngram and at least one Ngram derived from each of a plurality of past incident tickets belonging to the at least one category. The method further comprises predicting the relevant resolution based on one or more resolution mapped to the similar past incident ticket.
In one embodiment, a system for predicting a relevant resolution for an incident ticket is disclosed. In one example, the system comprises at least one processor and a memory communicatively coupled to the at least one processor. The memory stores processor-executable instructions, which, on execution, cause the processor to receive the incident ticket. The processor-executable instructions, on execution, further cause the processor to analyze the incident ticket to determine at least one query Ngram and at least one category. The processor-executable instructions, on execution, further cause the processor to determine a similar past incident ticket based on a comparison of the at least one query Ngram and at least one Ngram derived from each of a plurality of past incident tickets belonging to the at least one category. The processor-executable instructions, on execution, further cause the processor to predict the relevant resolution based on one or more resolution mapped to the similar past incident ticket.
In one embodiment, a non-transitory computer-readable medium storing computer-executable instructions for predicting a relevant resolution for an incident ticket is disclosed. In one example, the stored instructions, when executed by a processor, cause the processor to perform operations comprising receiving the incident ticket. The operations further comprise analyzing the incident ticket to determine at least one query Ngram and at least one category. The operations further comprise determining a similar past incident ticket based on a comparison of the at least one query Ngram and at least one Ngram derived from each of a plurality of past incident tickets belonging to the at least one category. The operations further comprise predicting the relevant resolution based on one or more resolution mapped to the similar past incident ticket.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
Referring now to
The system 100 comprises one or more processors 101, a computer-readable medium (e.g., a memory) 102, and a display 103. The computer-readable storage medium 102 stores instructions that, when executed by the one or more processors 101, cause the one or more processors 101 to perform prediction of relevant resolutions for incident tickets in accordance with aspects of the present disclosure. The computer-readable storage medium 102 may also store various data (e.g., past ticket repository, keywords, Ngrams, clusters or categories, relationship mapping, user queries, resolutions, etc.) that may be captured, processed, and/or required by the system 100. The system 100 interacts with a user via a user interface 104 accessible via the display 103. The system 100 may also interact with one or more external devices 105 over a communication network 106 for sending or receiving various data. The external devices 105 may include, but are not limited to, a remote server, a digital device, or another computing system.
Referring now to
The input module 201 receives input from one or more sources that enables the engine 200 to build a prediction model for predicting an appropriate resolution for an incident ticket. The input may include ticket repository 209, input from data sources 210, and input from a user or user data 211. The ticket repository or ticket dump 209 comprises data related to past incident tickets and corresponding resolutions. In some embodiments, it may be in the form of comma-separated values (CSV) file or Microsoft excel file and may include a number of fields or parameters such as a ticket ID or ticket number, a primary application, a title, a ticket description or a problem description, a resolution category, a resolution description, and so forth. The data sources 210 may include one or more personnel from a L1 and/or a L2 service team who resolves the assigned incident tickets. They are typically within the functions of the organization but may also be from outside service provider. The input from data sources 210 may include various other parameters such as resolution date and time, etc. The user data 211 may be the input from the user i.e. user query in the form of incident tickets. The summary of the user's problem may be provided in the description of the ticket.
The analytics module 202 may typically include a pre-processing submodule 212, an Ngrams submodule 213, and a clustering submodule 214. The pre-processing submodule 212 extracts the structured description from the ticket repository 209 in order to generate the prediction model. In particular, the pre-processing submodule 212 processes the problem descriptions and the resolution descriptions from the ticket repository to generate corresponding structured descriptions. In some embodiments, the pre-processing may include, but is not limited to, removing URLs, removing numbers, removing generic stop words, removing custom stop words, removing Emails, removing special characters, removing date and time values, and so forth as they have little or no contribution to content, context, and meaning of the ticket. Further, in some embodiments, the pre-processing may involve extracting the specific information needed from form based or Email based patterns using regex. Similarly, the pre-processing module 212 processes the problem description from the user query (i.e., the incident ticket) to generate the corresponding structured description.
The Ngrams submodule 213 generates the Ngrams from the structured description that effectively enable the identification of error symptoms in past incident tickets as well as in the user query. The term Ngrams refers to continuous sequence of N words in a given structured description. In some embodiments, the Ngrams submodule 213 may determine at least one of unigrams (1 word sequence), bigrams (2 words sequence), and trigrams (3 words sequence). The clustering submodule 214 clusters tickets into multiple categories such that each category comprises a set of tickets having at least one common characteristic. In other words, the clustering submodule 214 forms clusters or groups of tickets that belong to same application or the tickets having similar problem query.
The relationship mapping module 203 maps each of the past incident tickets with the one or more existing resolutions by analyzing the corresponding Ngrams. The mapping module 203 iteratively matches the Ngrams for each of the existing resolutions with the Ngrams for each of the past incident tickets. The mapping module 203 then scores each of the existing resolutions for a given past incident ticket based on a number of matches and selects the one or more resolutions from the plurality of resolutions based on scoring. In case of a conflict between the one or more resolutions having an identical score, the mapping module 203 may request clarification from a service user (i.e., resolution team) via the clarification module 204.
Additionally, the clarification module 204 may request an end user for any clarifications or for some other details (if required) so as to process the user tickets. For example, the clarification module 204 may request clarification from an end user (i.e., user raising the incident ticket or query) when the query is unclear or improper. The clarification module 204 may also request additional information from the end user so as to provide the appropriate solution.
The prediction module 205 builds a prediction model based on the Ngrams and the clusters. It performs mapping of the clusters and the Ngrams of tickets repository comprising of past tickets and existing solutions such that the resulting prediction model may be employed for predicting resolution for future tickets. In some embodiments, the prediction model may analyze the incident ticket to determine query Ngrams and one or more categories to which the incident ticket may fall into. The prediction model may then determine a similar past incident ticket based on a comparison of the query Ngrams and Ngrams derived from the past incident tickets belonging to the each of the one or more identified categories. The prediction model may then predict the relevant resolution based on one or more resolution mapped to the similar past incident ticket.
The validation module or the model trainer 206 in conjunction with the learning module 207 performs continuous validation and improvement of the predictive model. The learning module 207 employs a learning agent based on machine learning techniques to enable incremental learning. Thus, in some embodiments, upon receiving a user query (a new incident ticket), the prediction module 205 predicts a relevant resolution via the prediction model while the validation module 206 validates the relevant resolution provided by the prediction model with the help of a service level user. For a negative validation (i.e., the predicted resolution not being relevant or accurate), the learning module 207 initiates a learning process based on intelligence gathered manual resolution of the incident ticket. The new incident ticket and the corresponding manual resolution is updated in the repository for subsequent use. It should be noted that the incident ticket resulting in the negative validation is typically a new incident ticket unrelated to a plurality of past incident tickets and/or an incident ticket not having a mapped resolution. However, for a positive validation, the output module 208 presents the relevant resolution to the end user.
It should be noted that the incident ticket prediction engine 200 may be implemented in programmable hardware devices such as programmable gate arrays, programmable array logic, programmable logic devices, and so forth. Alternatively, the incident ticket prediction engine 200 may be implemented in software for execution by various types of processors. An identified engine of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, function, module, or other construct. Nevertheless, the executables of an identified engine need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the engine and achieve the stated purpose of the engine. Indeed, an engine of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
Referring now to
At step 301, the system is initialized with the ticket repository or ticket dumps. In some embodiments, the ticket repository may include tickets from past two, three, or six months and corresponding resolutions. In some embodiments, the system may be initialized with additional parameters such as resolution date, resolution time, and assigned service personnel and so forth. Further, the system may be provided with a user query mentioning issues being faced by the user in the form of an incident ticket as input.
At step 302, the pre-processing submodule in conjunction with the Ngrams submodule and the clustering submodule identifies the error symptoms that the user is facing from the user query. The pre-processing submodule has built-in natural language processing (NLP) and text analyzer components. These components analyze the user data by removing the junks, spam, and stop words and by identifying the co-reference relationship between the sentences. The output from these components may be the keywords and named entities that may be subsequently clustered into various categories.
The NLP component receives the user query as input. The NLP component further captures the user utterances in the ticket logs and processes it. The processing of the text include identification of the individual sentences, tokenization of the sentence in the text, identification of the named entities like name of the places, organization, currency, time, date, and so forth. Also, NLP component may be employed to identify the noun and verb phrases in the sentence. Thus, the NLP component determines the relationship between the sentences in the service ticket and identifies the nouns and pronouns that describe the problem. The text analyzer component removes the unwanted junks from the user query. The text analyzer helps in the identification of keywords from the user query. The NLP component and the text analyzer component combines to form the necessary named entities and keywords that enable the identification of the clusters for the particular query or the incident ticket.
Thus, in some embodiments, by passing the user utterance to NLP and text analyzer component, the output will be the keywords from the user utterances. The output from the pre-processing submodule may then be provided to the Ngrams submodule and the clustering submodule to identify the groups the user utterance may be mapped to. In other words, the user query is processed to get the clusters and error symptoms as Ngrams.
At step 303, relationship mapping between the incident ticket and resolutions is generated based on clusters and Ngrams. The problem description in the ticket dumps is pre-processed and Ngrams are generated. Similarly the resolution description in the ticket dumps is pre-processed and Ngrams are generated. The relationship mapping module then maps the one or more resolutions to each incident ticket by iteratively matching the Ngrams of problem description with the Ngrams of resolution descriptions and the scoring the resolutions based on the number of matches. Thus, given an Ngrams (question), the relationship mapping module analyzes the possible Ngrams (solutions) to match the Ngrams (question). For example, Ngrams (question) may be {browser, browser issue, internet browser issue} for an input user query “I am facing internet browser issue”. However, if multiple solutions are coming out with the same score, then the relationship mapping module requests the clarification module to request the user for clarification.
At step 304, a prediction model is built based on the existing issue for handling the future issues and rendering the solution at real-time. The output from step 302 and 303 may be keywords, Ngrams, clusters, and mappings. The prediction model may therefore be built in such a way that the clusters may group the tickets based on common characteristics. It should be noted that the clusters simplify the role of relationship mapping and makes it efficient and effective. The relationship mapping may then provide a mapping of the Ngrams of ticket description and the resolution description within each cluster.
Thus, in some embodiments, given a ticket dump with problem description and the corresponding resolution description, the process of building prediction model involves clustering the tickets into groups based on the application names. The process of building prediction model further involves generating Ngrams for problem description and the corresponding resolution description. The process of building prediction model further involves generating a mapping of Ngrams for the problem and the corresponding resolution in a given cluster. The process of building prediction model further involves checking whether the Ngrams in problem description (any ticket) matches with Ngrams in problem description (rest of tickets) in any iteration. Similar Ngrams of the problem description are grouped and mapped with the resolution description to understand the error symptoms and the resolution mapping. The resultant prediction model may then be trained and validated by the validation module or the model trainer such that the prediction model provides most relevant and appropriate resolution for the user query.
At step 305, an incremental intelligence may be implemented using machine learning techniques for future data analysis. The entire system may be monitored by the intelligent agent and the system learns from the user's behavior and with the existing data. From the user query entering the system till the user gets the response output, the intelligent agent captures the data and learns incrementally to aid the actual learning of the system.
As will be appreciated by one skilled in the art, a variety of processes may be employed for predicting relevant resolution for an incident ticket. For example, the exemplary system 100 and the associated incident ticket prediction engine 200 may predict relevant resolution for an incident ticket by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 and the associated incident ticket prediction engine 200, either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some or all of the processes described herein may be included in the one or more processors on the system 100.
For example, referring now to
In some embodiments, the control logic 400 may further include the steps of validating the relevant resolution from a user, and for a negative validation, initiating a learning process based on intelligence gathered manual resolution of the incident tick. It should be noted that the incident ticket resulting in the negative validation is a new incident ticket unrelated to a plurality of past incident tickets and not having a mapped resolution. The control logic 400 may further include the step of updating a ticket repository based on the learning process.
In some embodiments, the control logic 400 may further include the steps of receiving a past ticket repository comprising a plurality of past incident tickets and a plurality of resolutions, and clustering the plurality of past incident tickets and the plurality of resolutions into a plurality of categories. It should be noted that each category comprises a set of past incident tickets from the plurality of past incident tickets having at least one common characteristic. The control logic 400 may further include the steps of determining at least one Ngram for each of the plurality of past incident tickets and for each of the plurality of resolutions, and mapping each of the plurality of past incident tickets with the one or more resolutions from the plurality of resolutions by analyzing the at least one Ngram for each of the plurality of past incident tickets with the at least one Ngram for each of the plurality of resolutions. In some embodiments, the control logic 400 may further include the step of pre-processing the plurality of past incident tickets and the plurality of resolutions. In some embodiments analyzing Ngrams comprises iteratively matching the at least one Ngram for each of the plurality of resolutions with the at least one Ngram for each of the plurality of past incident tickets, and for a given past incident ticket from the plurality of past incident tickets, scoring each of the plurality of resolutions based on a number of matches, and selecting the one or more resolutions from the plurality of resolutions based on scoring. In some embodiments, the control logic 400 may further include the step of requesting clarification from a user in case of a conflict between the one or more resolutions having an identical score.
Referring now to
Additionally, the control logic 500 includes the steps of receiving an incident ticket from a user at step 509, pre-processing the incident ticket at step 510, analyzing the incident ticket to determine query Ngrams as well as one or more categories to which the incident ticket may belong to at step 511. For each of the one or more determined categories, the control logic 500 further includes the step of determining a similar past incident ticket based on a comparison of query Ngrams and Ngrams for past incident tickets at step 512. It should be noted that, in some embodiments, the determination at step 512 involves referring to the clusters and Ngrams derived from the ticket repository at steps 503 and 504. Alternatively, it should be noted that, in some embodiments, the clusters and Ngrams derived from a repository of past incident tickets and resolutions may be separately received from an external source and therefore need not be derived by the control logic 500. The control logic 500 further includes the step of predicting relevant resolution for the incident ticket based on one or more resolution mapped to the similar past incident ticket at step 513. Again, it should be noted that, in some embodiments, the prediction at step 513 involves referring to the mapping derived at step 508. Alternatively, it should be noted that, in some embodiments, the mapping may be separately derived and thereupon fed from an external source.
Moreover, the control logic 500 includes the steps of validating the relevant resolution at step 514, and determining if the validation is a positive validation or not at step 515. If the resolution provided is accurate and relevant then it is a positive validation and the control logic 500 concludes by recording as such. However, if the resolution provided is not accurate and/or not relevant then it is a negative validation. In such cases, the incident ticket is taken for manual resolution. Further, in such cases, the control logic 500 includes the steps of initiating a learning process based on the manual resolution of the incident ticket at step 516, and updating the ticket repository with the incident ticket as well as its resolution at step 517.
As will be also appreciated, the above described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to
Processor 602 may be disposed in communication with one or more input/output (I/O) devices via I/O interface 603. The I/O interface 603 may employ communication protocols/methods such as, without limitation, audio, analog, digital, monoaural, RCA, stereo, IEEE-1394, serial bus, universal serial bus (USB), infrared, PS/2, BNC, coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (HDMI), RF antennas, S-Video, VGA, IEEE 802.n/b/g/n/x, Bluetooth, cellular (e.g., code-division multiple access (CDMA), high-speed packet access (HSPA+), global system for mobile communications (GSM), long-term evolution (LTE), WiMax, or the like), etc.
Using the I/O interface 603, the computer system 601 may communicate with one or more I/O devices. For example, the input device 604 may be an antenna, keyboard, mouse, joystick, (infrared) remote control, camera, card reader, fax machine, dongle, biometric reader, microphone, touch screen, touchpad, trackball, sensor (e.g., accelerometer, light sensor, GPS, gyroscope, proximity sensor, or the like), stylus, scanner, storage device, transceiver, video device/source, visors, etc. Output device 605 may be a printer, fax machine, video display (e.g., cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED), plasma, or the like), audio speaker, etc. In some embodiments, a transceiver 606 may be disposed in connection with the processor 602. The transceiver may facilitate various types of wireless transmission or reception. For example, the transceiver may include an antenna operatively connected to a transceiver chip (e.g., Texas Instruments WiLink WL1283, Broadcom BCM4750IUB8, Infineon Technologies X-Gold 618-PMB9800, or the like), providing IEEE 802.11a/b/g/n, Bluetooth, FM, global positioning system (GPS), 2G/3G HSDPA/HSUPA communications, etc.
In some embodiments, the processor 602 may be disposed in communication with a communication network 608 via a network interface 607. The network interface 607 may communicate with the communication network 608. The network interface may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), transmission control protocol/internet protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. The communication network 608 may include, without limitation, a direct interconnection, local area network (LAN), wide area network (WAN), wireless network (e.g., using Wireless Application Protocol), the Internet, etc. Using the network interface 607 and the communication network 608, the computer system 601 may communicate with devices 609, 610, and 611. These devices may include, without limitation, personal computer(s), server(s), fax machines, printers, scanners, various mobile devices such as cellular telephones, smartphones (e.g., Apple iPhone, Blackberry, Android-based phones, etc.), tablet computers, eBook readers (Amazon Kindle, Nook, etc.), laptop computers, notebooks, gaming consoles (Microsoft Xbox, Nintendo DS, Sony PlayStation, etc.), or the like. In some embodiments, the computer system 601 may itself embody one or more of these devices.
In some embodiments, the processor 602 may be disposed in communication with one or more memory devices (e.g., RAM 613, ROM 614, etc.) via a storage interface 612. The storage interface may connect to memory devices including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as serial advanced technology attachment (SATA), integrated drive electronics (IDE), IEEE-1394, universal serial bus (USB), fiber channel, small computer systems interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, redundant array of independent discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory devices may store a collection of program or database components, including, without limitation, an operating system 616, user interface application 617, web browser 618, mail server 619, mail client 620, user/application data 621 (e.g., any data variables or data records discussed in this disclosure), etc. The operating system 616 may facilitate resource management and operation of the computer system 601. Examples of operating systems include, without limitation, Apple Macintosh OS X, Unix, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), IBM OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry OS, or the like. User interface 617 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 601, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical user interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems' Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like.
In some embodiments, the computer system 601 may implement a web browser 618 stored program component. The web browser may be a hypertext viewing application, such as Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, etc. Secure web browsing may be provided using HTTPS (secure hypertext transport protocol), secure sockets layer (SSL), Transport Layer Security (TLS), etc. Web browsers may utilize facilities such as AJAX, DHTML, Adobe Flash, JavaScript, Java, application programming interfaces (APIs), etc. In some embodiments, the computer system 601 may implement a mail server 619 stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as ASP, ActiveX, ANSI C++/C#, Microsoft .NET, CGI scripts, Java, JavaScript, PERL, PHP, Python, WebObjects, etc. The mail server may utilize communication protocols such as internet message access protocol (IMAP), messaging application programming interface (MAPI), Microsoft Exchange, post office protocol (POP), simple mail transfer protocol (SMTP), or the like. In some embodiments, the computer system 601 may implement a mail client 620 stored program component. The mail client may be a mail viewing application, such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Mozilla Thunderbird, etc.
In some embodiments, computer system 601 may store user/application data 621, such as the data, variables, records, etc. (e.g., past ticket repository, keywords, Ngrams, clusters or categories, relationship mapping, user queries, resolutions, and so forth) as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. Alternatively, such databases may be implemented using standardized data structures, such as an array, hash, linked list, struct, structured text file (e.g., XML), table, or as object-oriented databases (e.g., using ObjectStore, Poet, Zope, etc.). Such databases may be consolidated or distributed, sometimes among the various computer systems discussed above in this disclosure. It is to be understood that the structure and operation of the any computer or database component may be combined, consolidated, or distributed in any working combination.
As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above result in automated, efficient, and speedy resolution of incident tickets. The techniques provide for a prediction model derived from past tickets repository that can predict the most appropriate or relevant resolution for an incident ticket in real-time, thereby reducing the manual effort and the time delay in providing accurate resolution. Further, the techniques described in the various embodiments discussed above increase the productivity of the user as well as the resolution team handling those tickets. The user can have quick resolution to his query while the resolution team may focus on new issues for which there are no mapped resolutions.
Additionally, as will be appreciated by those skilled in the art, the prediction model learns new errors and tries to map the resolutions for the new errors. The prediction model understands the relationship between the error and the cluster/group in which the error would belong to by continuous learning. Further, the prediction model may analyze a number of times same error is being faced by the users in a given period of time and other such information. Such information may be very useful in not only improving the prediction model but also the overall IT infrastructure.
The specification has described system and method for predicting relevant resolution for an incident ticket. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.
Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201641026094 | Jul 2016 | IN | national |
