Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02857140 2014-07-18
SYSTEM AND METHOD FOR EXTERNALLY MAPPING AN INTERACTIVE VOICE
RESPONSE MENU
Field of the Invention
The present invention relates generally to communication call management and,
more particularly, to Interactive Voice Response (IVR) systems.
Background of the Invention
Today, when a user (waiting party) calls a large company or service center
(queuing party), it is very likely that he or she (referred to collectively as
It" in this
disclosure) will be connected to an Interactive Voice Response (IVR) system.
Such
systems present the waiting party with information via a series of audio
prompts and
receive input from the caller via dual tone multi-frequency (DTMF) tones (also
known as
"touch tones") or verbal commands.
An "IVR map" is a structured list of all the possible paths through a given
IVR
system, where each path consists of one or more nodes. Figure 1 (PRIOR ART)
provides an illustrative example of such an IVR map. Each node in the map
includes a
prompt and possibly one or more commands. The prompt is the audio that is
heard by
the waiting party and is represented in the map by the corresponding text. A
command
allows the caller to navigate to another node. Examples of commands are DTMF
tones
and verbal commands. Each command will lead to another node in the IVR system,
or
will put the caller in a queue to speak to a live agent.
The strength of the IVR system is its universality. It works on any phone and
is
usable by even the least technically inclined people. IVR systems are favored
by
companies because they allow live agents to be used more effectively, which in
turn
reduces the costs of running call centers. Recent advances in technology are
making
IVR systems both easier to set up and more elaborate. Customer interactions
that used
to involve an agent ¨ e.g., checking a bank balance, making a payment ¨ are
being
CA 02857140 2014-07-18
2
delegated more and more to the "automated attendant". It's clear that IVRs are
going to
be used for the foreseeable future.
However, IVR systems can be very frustrating to the waiting party. By way of
example:
1. Companies are putting more and more marketing messages into
their IVRs, which provides no value to the waiting party and
increases the time it takes him or her to accomplish desired
objectives.
2. For really long menus, it can be hard for the waiting party to
remember all the options by the time the menu completes.
3. Often the waiting party simply wants to speak to an agent. but the
path to get there is not obvious. In fact, sometimes companies
make reaching an agent deliberately obtuse.
Summarv of the Invention
The present embodiments provide in one aspect an interactive voice response
mapping system (IVRMS) used in a transaction between a waiting party and a
queuing
party, the queuing party having a queuing calling system (QCS), the IVRMS
adapted to
communicate with the QCS and to build an IVR map of the QCS.
In another aspect, the present embodiments provide a method used in a
transaction between a waiting party and a queuing party, the queuing party
having a
queuing calling system (QCS), the method comprising communicating with the QCS
and to build an IVR map of the QCS.
Brief Description of the Drawings
Embodiments of the invention are described by way of example with reference to
the accompanying drawings, in which:
FIG. 1 is an illustration of an IVR map with commands and nodes.
CA 02857140 2014-07-18
3
FIG. 2 is an illustration of an exemplary embodiment of an IVR mapping system
(IVRMS) using a network to communicate with a C1CS system and build an IVR
map.
FIG. 3 is an illustration of an exemplary IVRMS with the option of capability
of
being edited by en editor through a visual map editor interface (MEI).
FIG 4 is an illustration of an exemplary MEI screenshot.
FIG 5 is an illustration of an exemplary IVR database incorporating time-based
IVR maps.
Detailed Description of the Preferred Embodiments
The present invention will now be described more fully hereinafter with
reference
to the accompanying drawings, in which embodiments of the invention are shown.
This
invention may, however, be embodied in many different forms and should not be
construed as limited to the embodiments set forth herein. Rather, these
embodiments
are provided so that this disclosure will be thorough and complete, and will
fully convey
the scope of the invention to those skilled in the art.
The embodiments presented herein provide a system and method which allows
the waiting party to review the IVR map of a queuing party in, e.g. in a
visual way, thus
saving time during the navigation process in a transaction which might be
through a
land phone, mobile phone, web-based phone, softphone, and the like.
Referring initially to Figure 1, the queuing party could have the IVR map as
herein shown by way of example, and the waiting party may want to reach
technical
support for a hardware problem. The illustration of Figure 1 makes it clear
that after
dialing, the waiting party needs to press "1" and then "2". This approach is
faster
compared to dialing the number without the IVR map as a reference and
listening
through the menus. Because this example is simplified, the time savings is
minimal, but
in real-world cases, it can be much more substantial.
One difficulty in creating an IVR map is that, typically, the queuing party
does not
make available the contents of its IVR map in any way other than through
dialing their
phone system. Further, the queuing party may change the content or structure
of its IVR
CA 02857140 2014-07-18
4
map at any time. There is currently no system for notifying a third party of
this change,
hence an IVR map may become out-of-date at any time, without notice.
The embodiments presented herein provide a communications system referred to
as the IVR mapping system (IVRMS) that is independent of the queuing party and
of
any telephone network carriers. Figure 2 illustrates, by way of example,
functions of an
IVRMS 1. The IVRMS 1 connects through the communication network 2 (e.g., PSTN)
with the queuing calling system (QCS) 3 of the queuing party (typically an
IVR). The
IVRMS generates and IVR map 4 for a given QCS which is in turn stored in a
database
called the IVR map Database (IVRMDB) 5.
It should be noted that present embodiments are applicable to landline phones,
mobile and cellular phones, internet/web/IP-based phones or softphones etc.
All the
above devices could be identified with a voice address which could for example
be a
telephone number or an IP address. For instance, just as well as sending voice
cues or
composing numbers with a telephone, one could use data and software command
transfer using intemet/web/IP-based phones or softphones. It is therefore
important to
notice that the present embodiments relate to all these cases.
Functions of one IVRMS according to the teachings of the present invention may
include:
4. Connect to the QCS over a communication network (e.g., PSTN).
5. Process the audio from the QCS and convert it to text or graphical
representation.
6. Compare the audio or text with existing IVR map, if one exists.
7. Extract navigational information.
8. Send commands to the QCS (e.g., DTMF tones, voice cues, software
commands, and the like).
The Editor
In some embodiments, the actions of the IVRMS are assisted by an editor. The
tasks of the editor include at least one of the following:
1. Correcting mistakes in the automated speech-to-text conversion
process;
CA 02857140 2014-07-18
2. Removing text that is not relevant for visual navigation (e.g. "press
star to repeat this menu");
3. Correcting the structure of the IVR map by adding, removing or
changing commands for particular nodes.
5 In some embodiments, the editor is presented with a visual interface,
namely the
map editing interface (MEI), that facilitates the editor's work. Figure 3
shows an
illustrative example involving an MEI and other relevant components.
Figure 4 shows an exemplary representation of an MEI screenshot that allows
the editor to make appropriate changes to a node in the IVRMDB.
It should be noted that editor might be a person, or it might also be a built-
in
software or hardware module inside the IVRMS, or an external software or
hardware
device interoperable with the IVRMS.
Map Validation
In some embodiments, the IVRMS performs a process called map validation,
whereby it connects with the QCS and issues the appropriate commands to reach
every
node in the map. At each node, the IVRMS performs a process called node
Validation
whereby the incoming audio and/or text from a given node is compared with the
stored
audio and/or text for that node in the IVRMDB. If a certain threshold of
matching is not
met, then the node is flagged and, in some embodiments, an Editor is notified
so that
the node can be reviewed. The threshold levels may be set by the Editor on a
per-node
or per-map basis.
In some embodiments, map validation is performed on a regular schedule for
each queuing party.
In some embodiments, some queuing parties may be designated as "frequently
changing", and hence require more frequent map validation.
Regular Time-based Map Changes
Some queuing parties may have regularly scheduled periods during which the
IVR map is switched from the "primary IVR map" (the one heard the majority of
the time)
to a "supplementary IVR map". For example, waiting party may be presented with
a
supplementary IVR map on weekends or outside the office hours of the queuing
party.
In order to avoid unnecessary mapping effort, it is important for the IVRMS to
recognize
CA 02857140 2014-07-18
6
these supplementary IVR maps and not discard the primary IVR map. Some
embodiments presented herein allow for such regular time-based changes by
storing in
the IVRMDB the supplementary IVR maps along with the scheduling information
associated with each map. Indeed a queuing party may have multiple IVR maps
corresponding to different time periods or for any other reason, and the IVRMS
recognizes and builds multiple IVR maps correspondingly. Figure 5 shows an
illustrative
diagram of this relationship in the IVRMDB.
Non-Essential Text
Some queuing parties may have prompts in their IVR map where some of the
text in the prompt changes frequently, even though the node's commands do not
change. This text is referred to as "non-essential text". Some embodiments
presented
herein allow the editor to designate blocks of text as non-essential text in
order to avoid
unnecessary mapping effort.
One benefit of the embodiments presented herein is to provide a system and
method that allows the creation of an IVR map for a queuing party in a way
that requires
no changes to the communication system of the queuing party.
Another benefit of the embodiments presented herein is to provide such a
system
and method in a way that is transparent to the queuing party, requires no
negotiation
with the queuing party and requires no cooperation from the queuing party.
Another benefit of the embodiments presented herein is to provide such a
system
and method in a way that stays synchronized with any changes to the company's
1VR
map.
Many modifications and other embodiments of the invention will come to the
mind of one skilled in the art having the benefit of the teachings presented
in the
foregoing descriptions and associated drawings. Therefore, it is understood
that the
invention is not to be limited to the specific embodiments disclosed, and that
modifications and embodiments are intended to be included within the scope of
the
appended claims.
