Note: Descriptions are shown in the official language in which they were submitted.
CA 02324755 2000-10-30
A SYSTEM AND METHOD FOR MANAGING HELP DESK CALLS
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention is related to Knowledge Management and more particularly
to tracking
and management of problems reported to a customer service organization such as
a Help Desk.
Background Description
Corporations maintain customer service organizations to address customer
problems with
products to insure customer product satisfaction. Typically customers are
given a number to call or
an e-mail address to contact should they have questions or encounter problems
with products. The
customers' contact is known, generally, as the "Help Desk." A typical Help
Desk may receive
thousands of product queries daily, often reporting product problems.
As each problem is reported, it is assigned a problem report reference number.
the reference
number is useful for tracking progress towards problem resolution, both by
customers and by the
customer service organization. Once a problem is reported and a Problem Record
reference number
is reported, one or more Customer Service Representatives) (CSRs) is/are
assigned the
responsibility of finding a solution to the particular problem.
Often several different customers encounter identical problems. Unless every
CSR is aware
of prior solutions, the same solution may need to be rediscovered each time a
problem is
encountered. Thus, problem history and corresponding solutions are made
available to CSRs.
2o However, with the large volume of problem reports having each CSR treat
each problem
individually quickly becomes an impossible situation. Sifting and collating
problem reports to
reduce the number of reported problems to a more manageable number of related
problems is a
YOR9-1999-0544 1
CA 02324755 2000-10-30
daunting task. This problem is further exacerbated by adding problem reports
as the information is
sifted. Furthermore, technology is changing so rapidly today with new or
improved solutions being
found that problem reports may become stale within a week and associated
resolutions obsolete.
Thus, there is a need for improved methods ofproblem tracking and Help Desk
management.
Summary of the Invention
It is a purpose of the invention to improve problem report response time;
It is another purpose of the invention to provide a method and system for
improved product
problem tracking and solving.
The present invention is a Help Desk tracking method and system tracking
problem reports
to and providing solutions to reported problems. The system includes a primary
database, a Problem
Record Database for maintaining all the incoming Problem Reports (PRs) from
customers. The
Problem Records are analyzed in turn, and linked entries are made in a
secondary database, the
Reference Library Database, with any identified solutions being maintained in
a Solutions Database,
also included in the Reference Library Database. Each resulting solution can
be sent back to the
15 requesting customer via e-mail, through any wireless device or, simply
stored in the Reference
Library Database as a reference for the appropriate Customer Service
Representative (CSR) to report
the solution. With each new solution, the Reference Library Database evolves
into a Knowledge
Management system that may also be used to train Customer Service
Representatives. Further, the
date and time stamp of each of the Problem Records is verified periodically,
to insure that links are
2o no more than one week old. Thus, problems and respective matched solutions
are not allowed to
become stale.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows a flow diagram for analyzing reported problems according to the
preferred
embodiment of the present invention;
YOR9-1999-0544 2
CA 02324755 2000-10-30
Figure 2 is an example of the data structure for Problem Records in the
Problem Record
Database;
Figure 3 is an example of the data structure for Problem Records stored with
links to related
Problem Records in the Reference Library Database;
Figure 4 is an example of the data structure for Internet References stored in
the Reference
Library Database;
Figure 5 is an example of the data structure for identified solutions records
stored in the
Solutions Database;
Figure 6 is an example showing the relationship between records in the Problem
Report
1o Database, Reference Library Database and Solutions Database;
Figures 7A-B is a detailed flowchart showing the steps in managing Problem
Records
according to the preferred embodiment of the present invention;
Figure 8 shows how problem areas are refined;
Figure 9 shows how Problem Reports are tracked after entries have been made in
the
Problem Report Database and Reference Library Database;
Figure 10 is an example of the structure of a solution sent to the Customer
identified in the
Problem Record.
Detailed Description of a Preferred Embodiment of the Invention
Turning now to the drawings and more particularly Figure 1 shows a flow
diagram for
analyzing reported problems according to the preferred embodiment of the
present invention.
Customers 100 report problems to the Help Desk by an appropriate medium such
as by phone or
over network, e.g., by using e-mail over what is known as the Internet 102.
Problem reports are
entered in a Problem Record Database 104, which includes a table 106 of
reported Problem Records
(PRs). A search agent 108 analyzes each problem sifting through a secondary
Reference Library
Database 110 and over the Internet to find similar problems. Links of the
search results to other
problems that have previously been resolved in the Reference Library Database
110, which also
contains links to all related previously identified solutions in a Solutions
Database (not shown). The
YOR9-1999-0544 3
CA 02324755 2000-10-30
Reference Library Database 110 may be located either or both internally on a
corporate intranet and
externally on the Internet. An agent 112 generates a solution report for the
corresponding customer
and for any assigned Customer Service Representative (CSR). Typically, the
report may be sent to
the appropriate parties by e-mail.
Figure 2 is an example of the preferred Problem Record data structure 120
maintained in the
Problem Record Database 104. In this example, each Problem Record 120 includes
one or more
problem related fields 120PR, one or more customer identification fields 124C,
at least one product
field 120P and one or more solution fields 1205. The problem related fields
120PR may include an
unique ID field (Problem Record Unique ID) and a problem description field
(Problem Description) for a description of the problem. Also, identified
problem areas are included
in another problem related field (Problem areas) and the time and date are
included in yet another
problem related field (Problem Area Date/Time Stamp). Customer identification
fields may include
name (Name of customer), e-mail address (Email Address of customer) and
telephone number
(Telephone of customer). The customer identification fields 120C may also
include the time
(Date Time Stamp) that the report was made by the customer. The product field
identifies the
product (Product Name) subj ect to the Problem Record. The solution fields
1205 may include a flag
(Solution Found Flag) for indicating when the problem has been solved and
another flag (Email send
to Customer Flag) indicating whether the reporting customer has been notified
of the solution.
Figure 3 is an example of the preferred data structure for related problem
records 122,
wherein an original Problem Record 122PR is linked only to related problem
records 122LPR and
stored in the Reference Library Database 110. In this example, each entry 122
first includes the
identification 122PR of the problem record (Unique Identification Number) 120
in the Problem
Record Database 104. Also, each entry 122 includes fields 122LPR for links to
one or more related
problems, e.g., Related Problem Record unique id 1, Related Problem Record
unique id2, Related
Problem Record unique id3, etc. Each related problem link includes a field
(Date Time Stamp)
corresponding to the time at which the Problem Record link was included in the
linked Problem
YOR9-1999-0544 4
CA 02324755 2000-10-30
Records 122LPR, i.e., the linked Problem Record description (120) has a
selected degree of
commonality with the original Problem Record 122PR.
Figure 4 is an example of the preferred data structure wherein an original
problem record
124PR is linked only to Uniform Resource Locators (URLs) or web locations
124LURL and stored
in the Reference Library Database 110. In this example, again, each entry 124
includes the
identification 124PR of the uniquely identified Problem Record (Unique
Identification Number) 120
in the Problem Record Database 104. However, after identifying potential
problem solution Internet
locations, links 124LURL are included for each identified potential solution,
e.g., HTTP addressl
with related solution, HTTP address2 with related solution, HTTP address3 with
related solution,
1o etc. Each Internet link 124LURL entry includes a field (Date Time Stamp)
identifying the time at
which the corresponding URL was identified.
Figure 5 is an example of the preferred solutions record data structure 126
stored in the
Solutions Database. For each resolved problem in this example, each Problem
Record is identified
by its unique ID (Problem Record Unique ID) which is linked with one or more
identified solutions,
e.g., Solutionl, Solution2, etc. Each identified solution includes a field
(Date-Time Stamp)
indicating its age.
The above record structures 120, 122, 124 and 126 are provided for example
only and not
intended as a limitation. Fields may be deleted or, additional fields may be
included without
departing from the spirit or scope of the invention.
2o Figure 6 shows an example of the relationship between records 120, 122, 124
and 126 in the
Problem Record Database 104, Reference Library Database 110 and Solutions
Database 130. In this
example, records 120 for eight Problem Records (PR1-8) are shown in the
Problem Record Database
104. Problem areas 132, 134, 136 and 138 are shown for four problems, PR1,
PR2, PR3 and PRS,
respectively, and associated therewith as represented by arrows 140. The
Solution Found Flag is
YOR9-1999-0544 5
CA 02324755 2000-10-30
represented as being set for three problems PRI, PRS and PR8 to indicate that
solutions have been
identified for those three problems. As each of the eight Problem Records PR1-
8 is received and
processed according to the preferred embodiment, corresponding entries are
been made in the
Reference Library Database 110, as represented by arrows 142.
So, in this example PR4, which is new, has not been processed and, therefore,
does not have
a corresponding entry in the Reference Library Database 110. Two Problem
Records PR6, 7 have
no related previously recorded problems. Potential solutions locations have
been identified for PR 1
and, accordingly, the corresponding record has a structure 124 wherein only
URL locations are
included. One Problem Record PRS is related only to other Problems (PR8) and
has the structure
l0 122 wherein only related Problem Records are included. The remaining
Problem Records PR1, 2,
3 and 8 have both related Problem Records and URLs identified and, so, are
hybrids of the two
structures 122, 126. Solutions Database 130 includes records 126 for solutions
identified in this
example for three problems, PR 1, PRS and PRB. The identity and location of
these entries PR 1, PRS
and PR8 are e-mailed to the customer.
Figures 7A-B is a detailed flowchart 150 showing the steps in managing problem
reports
according to the preferred embodiment of the present invention. First, in step
152 as a problem is
reported, a Problem Record is generated and Product records are categorized by
product. Initially,
every Problem Record is assigned to potentially related, but relatively broad
problem areas that are
selected by the customer reporting the problem. In step 154, the Problem
Record is entered into the
2o Problem Record Database 104, with both a time/date stamp and an unique
original Problem Record
ID being attached as it is entered into the Problem Record Database 104.
Additionally, when the
record is stored in the Problem Record Database 104, these problem areas may
be further refined to
result in a more detailed internal translation table build. In step 156, the
agent 108 scans all existing
reported problems to determine, if each problem has been previously been
assigned as an entry in
the Reference Library Database 110. If it has, then in step 158 the agent
updates the appropriate
reference links in the Reference Library Database 110, i.e., adding problem
areas from a newly
YOR9-1999-0544 6
CA 02324755 2000-10-30
entered Problem Record, refining previously attributed problem areas or
including hypertext links
to newly identified URLs.
However, if an entry for a particular Problem Record has not been placed in
the Reference
Library Database 110, then, in step 160 the agent 108 begins searching to find
all previous record
entries with similar problem descriptions and their corresponding solutions.
So, first, the problem
areas are retrieved from the Reference Library Database 110 and compared with
the problem area
for the unentered records. The more detailed or precise the problem area, the
easier and quicker it
will be to match previously identified solutions with new Problem Records. The
agent also searches
selected web pages over the Internet for links to any related URLs that could
possibly be describing
l0 similar problems. In step 162 if the comparison results in a number of
matches exceeds a selected
threshold percentage; then, in step 164 any identified links are tagged to the
unique identifier of the
original Problem Record stored in the Reference Library Database 110. Also in
step 164, the
Solutions database 130 is checked for any preexisting solution for the
identified link (based on its
Problem Record Unique ID). If an entry is found in the Solutions database then
the solution
description is provided in a Report to Customer in step 174. In step 166 the
Product Record
Database 104 is checked for any remaining Problem Records that do not have
corresponding entries
in the Reference Library Database 110 and, if another unentered Problem Record
is found, returning
to step 160, problem areas are compared for matches.
If it is determined in step 166 that each Problem Record has a corresponding
entry in the
2o Reference Library Database 110; then, in step 168 of Figure 7B, web pages
previously identified as
being related problem areas are checked for previously solved problems
matching individual
Reference Library Database 110 entries. If solutions are not found in step
168, then in step 170, the
Reference Library Database 110 is checked to determine if all of the
corresponding linked URLs
have been checked in step 170. Should some web pages remain unchecked, then
returning to step
168, the search for solutions continues. Once one or more matching web pages
are identified as
having solutions, a hypertext link to the identified URLs is associated with
the corresponding unique
YOR9-1999-0544 7
CA 02324755 2000-10-30
ID and copied to the Reference Library Database 110 in step 172. If in step
170 all of the link
entries have been compared then, in step 174 a report is generated that
includes all of the compiled
links are stored in a report and the report is sent to the customer. The final
customer report includes
of all links stored in the reference database and any solutions identified in
step 164 from the
Solutions database.
Figure 8 shows how problem areas are refined in step 154. Using internal
mapping each
initially identified problem area is identified as a high level problem area
in a High Level Problem
Areas Table 180. Differences in problem areas are identified and problem areas
are re-mapped to
further refine them in an Internal Mapping Table 182. Finally, the refined
problem areas are
reordered and stored in a table 184 in the Problem Record Database 104 and
made available for
selection when the next customer reports a problem. These granular refined
problem area facilitate
matching newly reported problems with problem area that have previously
identified solutions and
make problem resolution faster and easier. Preferably, the refined problem
areas are also date and
time stamped. To keep problem areas in all Problem Records current,
periodically, the identified
problem areas are checked in each of the problem reports and as the problem
area mapping tables
changes updated with current problem areas. This periodic updates also ensures
that new problem
are being identified with the closest problem area to provide accurate linkage
of related problems
and Internet sites.
Figure 9 shows how Problem Reports are tracked after entries have been made in
the Problem
2o Report Database 104 and the Reference Library Database 110. As time passes,
each Problem Record
is checked in step 190 to determine whether a Customer Service Representative
has found a solution.
If not, then in step 192 the Problem Record remains open. However, if a
solution has been
identified, then, in step 194 the Solution Found Flag is set to indicate YES
in the Problem Record
and the solution is entered in the Solutions Database 130 along with the
unique identifier of the
problem record.
YOR9-1999-0544 8
CA 02324755 2000-10-30
When in step 194 the Solution Found Flag is set, a report 200 having a
structure as in the
example of Figure 10 is sent to the customer identified in the Problem Record.
The report 200
includes Problem Record identification information including the customer's
name (Customer
Name), a description of the problem (Problem description), identified refined
problem areas
(Problem Areas) and a contact telephone number (Customer Service Help
Phonenumber) as well as
solution specific information. The solution specific information may include a
description of
matched related problems (Problem description ofmatched PR1-3) with
corresponding solutions
to those problems (Solution of the PR1-3). Also, links to related URLs (HTTP
addressl-3 with
related solution) may be included with corresponding date/time stamps (Date
Time Stamp).
to Thus, according to the preferred embodiment Help Desk, a primary database,
the Problem
Record Database maintains records of all active problem reports. The Problem
Records are analyzed
to generate linked entries in a secondary database, the Reference Library
Database. Identified
solutions are maintained in a Solutions Database, also included in the
Reference Library Database.
The resulting solution can be sent back to the requesting customer via e-mail,
through any wireless
device or, simply stored in the Reference Library Database as a reference for
the appropriate
Customer Service Representative to report the solution to the customer. With
each new solution,
the Reference Library Database evolves into a Knowledge Management system that
may also be
used to train Customer Service Representatives. Further, the date and time
stamp of each of the
Problem Records is verified periodically, insuring that no link is more than
one week old. Thus,
problems and respective matched solutions are not allowed to become stale.
While the invention has been described in terms of preferred embodiments,
those skilled in
the art will recognize that the invention can be practiced with modification
within the spirit and
scope of the appended claims.
YOR9-1999-0544 9
