U.S. patent application number 14/588514 was filed with the patent office on 2015-04-23 for centralized customer contact database.
The applicant listed for this patent is Bank of America Corporation. Invention is credited to Edward Elias Arciniega, Kellie Marie Basher, Dennis Wayne Carwile, JR., Melodee Coleman, Larry Ray Densmore, Adam Anthony DiCaprio, Jeanne Carole Edwards, Ryan Scott Heller, Harold Cooper Keener, Jennifer Leigh McCain, Robert John McLaughlin, Dan R. Miller, Helen Ramsey Noles, Michael John O'Brien, Gregory Vincent Permar, Mathew Timothy Roe, Stephen Mark Schneeweis, Scott Stephen Thomas.
Application Number | 20150112761 14/588514 |
Document ID | / |
Family ID | 46753839 |
Filed Date | 2015-04-23 |
United States Patent
Application |
20150112761 |
Kind Code |
A1 |
Carwile, JR.; Dennis Wayne ;
et al. |
April 23, 2015 |
CENTRALIZED CUSTOMER CONTACT DATABASE
Abstract
According to some embodiments, a method receives a request for
contact information associated with a customer. The method
determines a plurality of contact values associated with the
customer. The plurality of contact values include a first set of
contact values that a first line of business associates with the
customer and a second set of contact values that a second line of
business associates with the customer. The method determines
priority information associated with each contact value. In
response to the request for contact information, the method
communicates one or more of the contact values. For each contact
value being communicated, the method communicates at least some of
the priority information associated with the each contact value
being communicated.
Inventors: |
Carwile, JR.; Dennis Wayne;
(Charlotte, NC) ; Roe; Mathew Timothy; (Elkton,
MD) ; DiCaprio; Adam Anthony; (Concord, NC) ;
Permar; Gregory Vincent; (Kennett Square, PA) ;
Thomas; Scott Stephen; (Pomona, CA) ; O'Brien;
Michael John; (Virginia Beach, VA) ; Densmore; Larry
Ray; (Port Orchard, WA) ; Arciniega; Edward
Elias; (Diamond Bar, CA) ; Noles; Helen Ramsey;
(Browns Summit, NC) ; Basher; Kellie Marie; (North
Tonawanda, NY) ; Heller; Ryan Scott; (Middletown,
DE) ; McLaughlin; Robert John; (Huntersville, NC)
; McCain; Jennifer Leigh; (San Dimas, CA) ;
Coleman; Melodee; (Charlotte, NC) ; Edwards; Jeanne
Carole; (Blythewood, SC) ; Miller; Dan R.;
(Saint Louis, MO) ; Schneeweis; Stephen Mark;
(Newark, DE) ; Keener; Harold Cooper; (Charlotte,
NC) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Bank of America Corporation |
Charlotte |
NC |
US |
|
|
Family ID: |
46753839 |
Appl. No.: |
14/588514 |
Filed: |
January 2, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13039036 |
Mar 2, 2011 |
|
|
|
14588514 |
|
|
|
|
Current U.S.
Class: |
705/7.29 |
Current CPC
Class: |
H05K 13/0486 20130101;
G06Q 30/0201 20130101; G06Q 10/107 20130101 |
Class at
Publication: |
705/7.29 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02 |
Claims
1. A system, comprising: an interface operable to: receive a
request for contact information associated with a customer; and one
or more processors operable to: determine a plurality of contact
values associated with the customer, the plurality of contact
values comprising: a first set of contact values that a first line
of business associates with the customer, wherein the first line of
business provides a first type of financial products or financial
services on behalf of a financial institution; and a second set of
contact values that a second line of business associates with the
customer, wherein the second line of business provides a second
type of financial products or financial services on behalf of the
financial institution; and determine priority information
associated with each contact value; the interface further operable
to: communicate the contact information in response to the request,
the contact information comprising: one or more of the contact
values; and for each contact value being communicated, at least
some of the priority information associated with the each contact
value being communicated.
2. The system of claim 1, wherein the priority information
comprises one or more metric values, wherein at least one of the
metric values is selected from the group consisting of: a recency
metric indicating a time period that has elapsed since successfully
contacting the customer; a frequency metric indicating a number of
times contacting the customer according to a selected contact value
results in successful contact; and a time of day metric indicating
a likelihood that contacting the customer at a particular time of
day according to the selected contact value will result in
successful contact.
3. The system of claim 1, wherein the priority information
comprises a number of sources of a same contact value.
4. The system of claim 1, the interface further operable to receive
feedback indicating whether the customer was contacted according to
a selected contact value.
5. The system of claim 1, the one or more processors further
operable to: associate an expiration value with a selected contact
value, the expiration value indicating when to delete a contact
record comprising the selected contact value; receive an event
indicating the selected contact value remains valid; and increase
the expiration value associated with the selected contact
value.
6. The system of claim 1, further comprising: the interface further
operable to: receive a first vendor request message requesting a
third party to provide additional contact values associated with
the customer; and receive a second vendor request message
requesting the third party to provide additional contact values
associated with the customer; the one or more processors further
operable to: aggregate the first vendor request message and the
second vendor request message to yield an aggregated vendor request
message; and remove duplicate information from the aggregated
vendor request message; and the interface further operable to: send
the aggregated vendor request message to the third party.
7. A non-transitory computer readable storage medium comprising
logic, the logic, when executed by a processor, operable to:
receive a request for contact information associated with a
customer; determine a plurality of contact values associated with
the customer, the plurality of contact values comprising: a first
set of contact values that a first line of business associates with
the customer, wherein the first line of business provides a first
type of financial products or financial services on behalf of a
financial institution; and a second set of contact values that a
second line of business associates with the customer, wherein the
second line of business provides a second type of financial
products or financial services on behalf of the financial
institution; determine priority information associated with each
contact value; and communicate the contact information in response
to the request, the contact information comprising: one or more of
the contact values; and for each contact value being communicated,
at least some of the priority information associated with the each
contact value being communicated.
8. The logic of claim 7, wherein the priority information comprises
one or more metric values, wherein at least one of the metric
values is selected from the group consisting of: a recency metric
indicating a time period that has elapsed since successfully
contacting the customer; a frequency metric indicating a number of
times contacting the customer according to a selected contact value
results in successful contact; and a time of day metric indicating
a likelihood that contacting the customer at a particular time of
day according to the selected contact value will result in
successful contact.
9. The logic of claim 7, wherein the priority information comprises
a number of sources of a same contact value.
10. The logic of claim 7, wherein the priority information
comprises one or more tag values associated with a selected contact
value.
11. The logic of claim 7, further operable to: receive feedback
indicating whether the customer was contacted according to a
selected contact value.
12. The logic of claim 7, further operable to: associate an
expiration value with a selected contact value, the expiration
value indicating when to delete a contact record comprising the
selected contact value; receive an event indicating the selected
contact value remains valid; and increase the expiration value
associated with the selected contact value.
13. The logic of claim 7, further operable to: receive a first
vendor request message requesting a third party to provide
additional contact values associated with the customer; receive a
second vendor request message requesting the third party to provide
additional contact values associated with the customer; aggregate
the first vendor request message and the second vendor request
message to yield an aggregated vendor request message; remove
duplicate information from the aggregated vendor request message;
and send the aggregated vendor request message to the third
party.
14. A method, comprising: receiving a request for contact
information associated with a customer; determining, by a
processor, a plurality of contact values associated with the
customer, the plurality of contact values comprising: a first set
of contact values that a first line of business associates with the
customer, wherein the first line of business provides a first type
of financial products or financial services on behalf of a
financial institution; and a second set of contact values that a
second line of business associates with the customer, wherein the
second line of business provides a second type of financial
products or financial services on behalf of the financial
institution; determining priority information associated with each
contact value; and communicating the contact information in
response to the request, the contact information comprising: one or
more of the contact values; and for each contact value being
communicated, at least some of the priority information associated
with the each contact value being communicated.
15. The method of claim 14, wherein the priority information
comprises one or more metric values, wherein at least one of the
metric values is selected from the group consisting of: a recency
metric indicating a time period that has elapsed since successfully
contacting the customer; a frequency metric indicating a number of
times contacting the customer according to a selected contact value
results in successful contact; and a time of day metric indicating
a likelihood that contacting the customer at a particular time of
day according to the selected contact value will result in
successful contact.
16. The method of claim 14, wherein the priority information
comprises a number of sources of a same contact value.
17. The method of claim 14, wherein the priority information
comprises one or more tag values associated with a selected contact
value.
18. The method of claim 14, further comprising: receiving feedback
indicating whether the customer was contacted according to a
selected contact value.
19. The method of claim 14, further comprising: associating an
expiration value with a selected contact value, the expiration
value indicating when to delete a contact record comprising the
selected contact value; receiving an event indicating the selected
contact value remains valid; and increasing the expiration value
associated with the selected contact value.
20. The method of claim 14, further comprising: receiving a first
vendor request message requesting a third party to provide
additional contact values associated with the customer; receiving a
second vendor request message requesting the third party to provide
additional contact values associated with the customer; aggregating
the first vendor request message and the second vendor request
message to yield an aggregated vendor request message; removing
duplicate information from the aggregated vendor request message;
and sending the aggregated vendor request message to the third
party.
Description
RELATED APPLICATION
[0001] This application is a continuation of U.S. Ser. No.
13/039,036, filed Mar. 2, 2011, entitled "Centralized Customer
Contact Database," the disclosure of which is hereby incorporated
by reference herein.
TECHNICAL FIELD OF THE INVENTION
[0002] The present invention relates generally to customer contact
databases and more specifically to providing a centralized customer
contact database.
BACKGROUND OF THE INVENTION
[0003] Banks, financial institutions, and other businesses maintain
customer contact databases that contain customer contact
information, such as phone numbers, street addresses, and/or e-mail
addresses associated with customers. The businesses use the contact
information to contact the customers for the purpose of offering
new products, collecting late payments, and so on. Known customer
contact databases store limited types of information. Accordingly,
attempts to contact a customer using contact information provided
by known customer contact databases may result in a relatively high
number of unsuccessful attempts.
SUMMARY OF THE INVENTION
[0004] In accordance with the present invention, disadvantages and
problems associated with known customer contact databases may be
reduced or eliminated.
[0005] According to some embodiments, a method receives a request
for contact information associated with a customer. The method
determines a plurality of contact values associated with the
customer. The plurality of contact values include a first set of
contact values that a first line of business associates with the
customer and a second set of contact values that a second line of
business associates with the customer. The method determines
priority information associated with each contact value. In
response to the request for contact information, the method
communicates one or more of the contact values. For each contact
value being communicated, the method communicates at least some of
the priority information associated with the each contact value
being communicated.
[0006] Certain embodiments of the invention may provide one or more
technical advantages. A technical advantage of one embodiment
includes aggregating customer contact data from multiple lines of
business. Another technical advantage of an embodiment provides
priority information that may be used to identify a subset of the
customer contact information associated with a particular customer
that is more likely to result in successful contact. Another
technical advantage of an embodiment includes a feedback system for
collecting information regarding attempts to contact the customer.
Information collected through the feedback system may be used to
generate and/or update the priority information. Yet another
technical advantage includes formatting contact values according to
a standard format. Using a standard format may facilitate searching
through the contact values and may allow duplicate information to
be readily identified.
[0007] Certain embodiments of the invention may include none, some,
or all of the above technical advantages. One or more other
technical advantages may be readily apparent to one skilled in the
art from the figures, descriptions, and claims included herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] For a more complete understanding of the present invention
and its features and advantages, reference is now made to the
following description, taken in conjunction with the accompanying
drawings, in which:
[0009] FIG. 1 illustrates an example of a system that aggregates
customer contact information to facilitate contacting
customers;
[0010] FIG. 2 illustrates an example of customer data stored in a
database of server memory; and
[0011] FIG. 3 illustrates a flowchart for communicating customer
contact information.
DETAILED DESCRIPTION OF THE INVENTION
[0012] Embodiments of the present invention and its advantages are
best understood by referring to FIGS. 1 through 3 of the drawings,
like numerals being used for like and corresponding parts of the
various drawings.
[0013] Banks, financial institutions, and other businesses maintain
customer contact databases that contain customer contact
information including, for example, phone numbers, street
addresses, and/or e-mail addresses associated with customers. The
businesses use the contact information to contact the customers for
the purpose of offering new products, collecting late payments, and
so on. Known customer contact databases store limited types of
information. Accordingly, attempts to contact a customer using
contact information provided by known customer contact databases
may result in a relatively high number of unsuccessful attempts.
The teachings of the disclosure recognize that it would be
desirable to provide detailed information regarding ways to contact
the customer to increase the likelihood that attempts to contact
customers will result in success. FIGS. 1 through 3 below
illustrate a system and method of centralizing customer contact
information.
[0014] FIG. 1 illustrates a system 100 according to certain
embodiments. System 100 may include an enterprise 110, one or more
clients 115, a network storage device 125, one or more servers 140,
and one or more users 135. Enterprise 110, clients 115, and network
storage device 125 may be communicatively coupled by a network 120.
Enterprise 110 is generally operable to provide contact information
195, as described below.
[0015] In general, one or more servers 140 may provide contact
information 195 to users 135. User 135 may first provide a request
190 for contact information 195 associated with a customer. User
135 provides request 190 to server 140 utilizing client 115. Server
140 may then determine contact information 195 associated with the
customer indicated in request 190. Contact information 195 includes
one or more contact records. The contact records include contact
values for contacting the customer, such as one or more phone
numbers, e-mail addresses, and/or street addresses. In some
embodiments, server 140 may determine contact values that a first
line of business associates with the customer and contact values
that a second line of business associates with the customer. The
contact records may also include priority information associated
with the contact values. Server 140 may use the priority
information to select one or more contact values to communicate in
response to request 190. Server 140 then communicates certain
contact information 195 comprising the one or more contact values
to user 135. For each contact value communicated, server 140
communicates at least some of the priority information associated
with that particular contact value.
[0016] Client 115 may refer to any device that enables user 135 to
interact with server 140. In some embodiments, client 115 may
include a computer, workstation, telephone, Internet browser,
electronic notebook, Personal Digital Assistant (PDA), pager, or
any other suitable device (wireless, wireline, or otherwise),
component, or element capable of receiving, processing, storing,
and/or communicating information with other components of system
100. Client 115 may also comprise any suitable user interface such
as a display 185, microphone, keyboard, or any other appropriate
terminal equipment usable by a user 135. It will be understood that
system 100 may comprise any number and combination of clients 115.
User 135 utilizes client 115 to interact with server 140 to receive
contact information 195, as described below. In some embodiments,
user 135 may be a financial institution employee responsible for
contacting a customer for the purpose of offering new products,
collecting late payments, recovering delinquencies, mitigating
risks, detecting fraud, or any other suitable purpose. An example
of fraud prevention may include verifying a minimum number of
contact values prior to allowing a customer to complete a
transaction. As an example, the customer may be asked to provide a
new street address and a previous street address, and both
addresses may be verified against the addresses that the enterprise
associates with the customer.
[0017] In some embodiments, client 115 may include a graphical user
interface (GUI) 180. GUI 180 is generally operable to tailor and
filter data entered by and presented to user 135. GUI 180 may
provide user 135 with an efficient and user-friendly presentation
of request 190 and/or contact information 195. GUI 180 may comprise
a plurality of displays having interactive fields, pull-down lists,
and buttons operated by user 135. GUI 180 may include multiple
levels of abstraction including groupings and boundaries. It should
be understood that the term GUI 180 may be used in the singular or
in the plural to describe one or more GUIs 180 and each of the
displays of a particular GUI 180.
[0018] In some embodiments, network storage device 125 may refer to
any suitable device communicatively coupled to network 120 and
capable of storing and facilitating retrieval of data and/or
instructions. Examples of network storage device 125 include
computer memory (for example, Random Access Memory (RAM) or Read
Only Memory (ROM)), mass storage media (for example, a hard disk),
removable storage media (for example, a Compact Disk (CD) or a
Digital Video Disk (DVD)), database and/or network storage (for
example, a server), and/or or any other volatile or non-volatile,
non-transitory computer-readable memory devices that store one or
more files, lists, tables, or other arrangements of information.
Network storage device 125 may store any data and/or instructions
utilized by server 140. In the illustrated embodiment, network
storage device 125 stores customer data 164a to 164n. FIG. 2 below
illustrates an example of customer data 164.
[0019] In some embodiments, one or more network storage devices 125
may provide centralized storage. Centralized storage may refer to
storage accessible to different lines of business of enterprise
110. Network storage devices 125 providing centralized storage may
or may not be located proximate to one another. Centralized storage
may facilitate all lines of business having access to the most
current customer data 164 available. For example, if a customer
opens a checking account on Day 1 and provides a new phone number
to the checking account line of business, but the customer's credit
card becomes delinquent on Day 10, the credit card line of business
may retrieve the new phone number from centralized storage.
Therefore, the customer does not need to provide the new phone
number to the credit card line of business directly. Providing the
credit card line of business with the customer's current phone
number through the centralized storage may increase the likelihood
of successfully contacting the customer to efficiently resolve the
delinquency. In addition to facilitating access to the most current
customer data 164 available, centralized storage may provide the
different lines of business with more alternative ways to contact
the customer. For example, if a customer provides a home address to
a consumer credit card line of business and a work address to a
small business credit card line of business, both addresses may be
centrally stored and accessible to both lines of business.
[0020] In certain embodiments, network 120 may refer to any
interconnecting system capable of transmitting audio, video,
signals, data, messages, or any combination of the preceding.
Network 120 may include all or a portion of a public switched
telephone network (PSTN), a public or private data network, a local
area network (LAN), a metropolitan area network (MAN), a wide area
network (WAN), a local, regional, or global communication or
computer network such as the Internet, a wireline or wireless
network, an enterprise intranet, or any other suitable
communication link, including combinations thereof.
[0021] In some embodiments, enterprise 110 may refer to a financial
institution such as a bank and may include one or more servers 140,
an administrator workstation 145, and an administrator 150. In some
embodiments, server 140 may refer to any suitable combination of
hardware and/or software implemented in one or more modules to
process data and provide the described functions and operations. In
some embodiments, the functions and operations described herein may
be performed by a pool of servers 140. In some embodiments, server
140 may include, for example, a mainframe, server, host computer,
workstation, web server, file server, a personal computer such as a
laptop, or any other suitable device operable to process data. In
some embodiments, server 140 may execute any suitable operating
system such as IBM's zSeries/Operating System (z/OS), MS-DOS,
PC-DOS, MAC-OS, WINDOWS, UNIX, OpenVMS, or any other appropriate
operating systems, including future operating systems.
[0022] In general, server 140 aggregates and prioritizes contact
values received from multiple sources, such as multiple lines of
business of enterprise 110, and provides contact information 195 to
users 135. In some embodiments, servers 140 may include a processor
155, server memory 160, an interface 165, an input 170, and an
output 175. Server memory 160 may refer to any suitable device
capable of storing and facilitating retrieval of data and/or
instructions. Examples of server memory 160 include computer memory
(for example, RAM or ROM), mass storage media (for example, a hard
disk), removable storage media (for example, a CD or a DVD),
database and/or network storage (for example, a server), and/or or
any other volatile or non-volatile, non-transitory
computer-readable memory devices that store one or more files,
lists, tables, or other arrangements of information. Although FIG.
1 illustrates server memory 160 as internal to server 140, it
should be understood that server memory 160 may be internal or
external to server 140, depending on particular implementations.
Also, server memory 160 may be separate from or integral to other
memory devices to achieve any suitable arrangement of memory
devices for use in system 100.
[0023] Server memory 160 is generally operable to store an
application 162 and customer data 164. Application 162 generally
refers to logic, rules, algorithms, code, tables, and/or other
suitable instructions for performing the described functions and
operations. In some embodiments, application 162 facilitates
aggregation and prioritization of contact values and offers contact
information 195 to users 135.
[0024] Server memory 160 communicatively couples to processor 155.
Processor 155 is generally operable to execute application 162
stored in server memory 160 to provide contact information 195
according to the disclosure. Processor 155 may comprise any
suitable combination of hardware and software implemented in one or
more modules to execute instructions and manipulate data to perform
the described functions for servers 140. In some embodiments,
processor 155 may include, for example, one or more computers, one
or more central processing units (CPUs), one or more
microprocessors, one or more applications, and/or other logic.
[0025] In some embodiments, communication interface 165 (I/F) is
communicatively coupled to processor 155 and may refer to any
suitable device operable to receive input for server 140, send
output from server 140, perform suitable processing of the input or
output or both, communicate to other devices, or any combination of
the preceding. Communication interface 165 may include appropriate
hardware (e.g., modem, network interface card, etc.) and software,
including protocol conversion and data processing capabilities, to
communicate through network 120 or other communication system,
which allows server 140 to communicate to other devices.
Communication interface 165 may include any suitable software
operable to access data from various devices such as clients 115
and/or network storage device 125. Communication interface 165 may
also include any suitable software operable to transmit data to
various devices such as clients 115 and/or network storage device
125. Communication interface 165 may include one or more ports,
conversion software, or both. In general, communication interface
165 receives request 190 from clients 115 and transmits contact
information 195 to clients 115.
[0026] In some embodiments, input device 170 may refer to any
suitable device operable to input, select, and/or manipulate
various data and information. Input device 170 may include, for
example, a keyboard, mouse, graphics tablet, joystick, light pen,
microphone, scanner, or other suitable input device. Output device
175 may refer to any suitable device operable for displaying
information to a user. Output device 175 may include, for example,
a video display, a printer, a plotter, or other suitable output
device.
[0027] In general, administrator 150 may interact with server 140
using an administrator workstation 145. In some embodiments,
administrator workstation 145 may be communicatively coupled to
server 140 and may refer to any suitable computing system,
workstation, personal computer such as a laptop, or any other
device operable to process data. In certain embodiments, an
administrator 150 may utilize administrator workstation 145 to
manage server 140 and any of the data stored in server memory 160
and/or network storage device 125.
[0028] In operation, application 162, upon execution by processor
155, facilitates aggregation and prioritization of the contact
values and offers contact information 195 to users 135. In some
embodiments, application 162 aggregates contact values provided by
multiple lines of business, such as home loan, car loan, consumer
credit card, small business credit card, checking and savings,
and/or other lines of business. The lines of business may be
associated with the same enterprise, such as a particular financial
institution, or with multiple enterprises, such as other financial
institutions, data bureaus, and/or third party vendors. Contact
information 195 may include data for the customer's personal
accounts, business accounts, or both. In some embodiments, contact
information 195 may include data associated with members of the
customer's household, such as the customer's spouse, children,
and/or parents.
[0029] To provide contact information 195, application 162 may
first receive request 190 from users 135 via clients 115. In some
embodiments, GUI 180 may provide locations for user 135 to enter
request 190 and/or to select pre-filled options for request 190.
Request 190 may include one or more identifiers indicating the
customer for whom contact information 195 is being requested.
Examples of identifiers include customer name, social security
number, date of birth, party identifier (e.g., an identifier
assigned by the enterprise to identify all the accounts associated
with the customer), account number, and so on.
[0030] Once application 162 receives request 190, application 162
determines a plurality of contact values associated with the
customer. The plurality of contact values may be determined
according to the identifier contained in request 190. In some
embodiments, application 162 aggregates contact values provided by
each line of business of enterprise 110. Aggregating contact values
may include combining all of the contact values associated with the
customer indicated by the identifier of request 190. Aggregating
contact values may further include consolidating contact values by
applying a common format (e.g., standardizing the word "Street"
with the abbreviation "St.") and identifying and removing duplicate
contact values. Application 162 may aggregate the contact values in
response to receiving request 190. Alternatively, application 162
may aggregate the contact values in advance and store the
aggregated contact values in a database that may be accessed upon
receiving request 190.
[0031] In some embodiments, application 162 determines priority
information associated with each of the contact values. Priority
information represents information that may be used to assess the
likelihood that the customer will be successfully contacted
according to the contact value. Accordingly, priority information
may be used to prioritize the contact values such that the contact
values that are more likely to result in successful contact get
higher priority than the contact values that are less likely to
result in successful contact.
[0032] Priority information may be received as an input to
application 162 and/or may be generated by application 162. A
feedback event may be used to generate priority information. For
example, application 162 may receive a feedback event each time a
user 135 attempts to contact the customer. The feedback event
indicates whether the attempt was successful or unsuccessful.
Application 162 may generate a metric from the feedback events,
such as a frequency metric indicating how frequently contact
attempts resulted in success. As another example, application 162
may generate a priority value according to an algorithm. For
example, the algorithm may cause contact values associated with
frequent success to have a higher priority value than contact
values associated with infrequent success.
[0033] Application 162 then communicates contact information 195
via interface 165 to client 115. Contact information 195 includes
one or more of the contact values associated with the customer. For
each contact value communicated, contact information 195 includes
at least some of the priority information associated with that
contact record.
[0034] FIG. 2 illustrates an example of customer data 164 stored in
a database of server memory 160. Customer data 164 may include one
or more customer identifiers 200 and stored contact information
202. Customer identifiers 200 may include any identifier or
combination of identifiers for associating a customer with stored
contact information 202, such as customer name, social security
number, date of birth, party identifier (e.g., an identifier
assigned by the enterprise to identify all the accounts associated
with the customer), account number, and so on.
[0035] Stored contact information 202 may comprise one or more
contact records 204. The contact records 204 may be organized
according to fields, such as a contact field, an expiration field,
and one or more priority information fields. For each contact
record 204, the contact field may be populated with a contact value
206, such as a phone number, street address, e-mail address, and/or
other information for contacting the customer. Similarly, for each
contact record 204, the expiration field may be populated with an
expiration value 208 indicating when to delete contact record 204
due to expiration of its contact value 206. For each contact record
204, priority information fields may include one or more tag
fields, metrics fields, and/or priority fields. The fields may be
populated with tag values 212, metric values 214, and priority
values 216, respectively (collectively, "priority information
210").
[0036] In some embodiments, contact information 195 communicated to
user 135 comprises at least a portion of stored contact information
202. That is, contact information 195 comprises one or more contact
values 206 and at least some priority information 210 associated
with those contact values 206. For example, in one embodiment,
contact information 195 may comprise contact values 206(a) and
206(b) and their associated metric values 214(a) and 214(b)
respectively.
[0037] Expiration value 208 indicates when to delete a stored
contact record 204 due to expiration of its contact value 206.
Typically, when a customer provides a new contact value to a
business, a previously provided contact value is deleted from
customer data 164 and replaced with the new contact value. However,
there may be situations where the previously provided contact value
remains valid, and it would be desirable to keep such previously
provided contact value. For example, if a customer moves to a new
street address on a short term basis and then returns to a previous
street address after a period of time, it would be desirable to
maintain information associated with the previous street address.
As another example, the new contact value may reflect additional or
alternate information. For example, a customer may provide a home
address when opening a personal checking account ("the old
address") in Year 1. Even if the customer provides a business
address when opening a small business credit card account in Year 2
("the new address"), it may be desirable to maintain the old
address because that is the customer's residence. Accordingly,
rather than deleting a previously provided contact value upon
receipt of a new contact value, certain embodiments may maintain
the previously provided contact value in one of the contact records
204 until expiration.
[0038] Expiration value 208 may be an expiration date, a number of
days or months until expiration, or other suitable value. If an
event occurs indicating contact value 206 is still valid,
expiration value 208 may increase. Examples of events that may
cause expiration value 208 to increase include successfully
contacting the customer using contact value 206, the customer
verifying contact value 206, and the customer providing a known
contact value 206 to enterprise 110. A customer may provide a known
contact value 206, for example, when opening a new account using
the same phone number that enterprise 110 already associates with
an existing account of the customer.
[0039] Upon expiration, the contact record 204 associated with the
expired contact value 206 may be deleted. That is, the expired
contact value 206 and information associated with the expired
contact value 206, such as priority information 210 or expiration
value 208, may be deleted. In some embodiments, before deleting a
particular contact value 206, a check may be performed to ensure
that a minimum number of contact values 206 would remain available
after deleting the particular contact value 206. For example, if
the check determines that enterprise 110 associates one phone
number with a particular customer, rather than deleting the one
phone number upon expiration, expiration value 208 may increase to
ensure at least one phone number associated with the customer is
maintained.
[0040] Priority information 210 refers to information for
prioritizing contact values 206. Priority information 210 may
include one or more tag values 212, metric values 214, and/or
priority values 216. A tag value 212 describes contact value 206.
Any suitable description may be used. As an example, tag value
212(a) describes the type of contact value 206, such as phone
number, e-mail address, street address, or other type. As another
example, tag value 212(b) describes a sub-type of contact value
206, such as whether a phone number refers to a mobile phone, home
phone, or work phone. As another example, tag value 212(c)
describes the source of contact value 206. The source may be one or
more lines of business of the enterprise. For example, if a
customer provides the same phone number to two different lines of
business, each line of business may be listed as a source. In some
embodiments, the source may be a third party vendor that provides
contact value 206 to enterprise 110.
[0041] Tag value 212(n) provides examples of other tag values 212.
For example, tag value 212 may indicate a result of a previous
attempt to contact the customer using contact value 206. Example
results include successful and unsuccessful. In addition, tag value
212 may include a reason that the attempt was unsuccessful, such as
the telephone line being disconnected, no answer, wrong number,
e-mail bounce-back, or any other reason. As another example, tag
value 212 may indicate preference information submitted by the
customer, such as a preference to be contacted by e-mail rather
than by phone, a preference to be contacted by home phone rather
than by mobile phone, or a preference to be contacted at a
particular time of day or day of the week. As yet another example,
tag value 212 may indicate security information, such as
permissions granted by enterprise 110 and/or by the customer.
Permissions may include a list of users 135 or lines of business
that have (or do not have) permission to view contact record 204
and/or a list of users or lines of business that have (or do not
have) permission to contact the customer using contact value
206.
[0042] Metric values 214 may comprise statistics for quantifying
the likelihood that the customer may be successfully contacted
using contact value 206. A successful contact may be defined by
enterprise 110 and may refer to a customer answering the phone, a
representative of the customer answering the phone (e.g.,
voicemail, family member, or secretary), the customer returning a
phone call, delivery of an e-mail to the customer's inbox (e.g.,
the absence of an "undeliverable e-mail" error), the customer
reading an e-mail (e.g., receiving a read receipt), the customer
responding to an e-mail, the customer responding to a letter,
and/or other contact with the customer.
[0043] Examples of metric values 214 include recency metrics,
frequency metrics, time of day metrics, and source count metrics,
however, any suitable metric value 214 or combination of metric
values 214 may be used. A recency metric indicates a time period
that has elapsed since successfully contacting the customer
according to contact value 206. The recency metric may be
represented as a date or a number of days, weeks, months, years, or
other suitable time period.
[0044] A frequency metric indicates how frequently contacting the
customer according to contact value 206 results in successful
contact. For example, a customer may be contacted four times during
a selected time period, such as during the past year. If one of the
contacts was successful, the frequency metric would be 25%.
[0045] A time of day metric indicates a likelihood that contacting
the customer according to contact value 206 will result in
successful contact at a particular time of day. The time of day may
be represented generally, such as morning, afternoon, or evening,
or more specifically, such as 9:00 AM, 9:30 AM, 10:00 AM, and so
on. In some embodiments, a first time of day metric may represent
inbound contacts and a second time of day metric may represent
outbound contacts.
[0046] A source count metric indicates the number of sources, such
as lines of business and/or third party vendors, that provided the
same contact value 206. In some embodiments, the source count
metric may be determined by formatting or standardizing contact
values 206 according to a common format, identifying duplicate
contact values 206, and counting the number of duplicates of a
selected contact value 206.
[0047] Priority value 216 indicates the relative priority of a
particular contact value 206. Priority value 216 may be represented
as a rank (e.g., 1, 2, 3, and so on), a category (e.g., high,
medium, and low), or other suitable value. In some embodiments,
priority 216 may be calculated using an algorithm that accepts
expiration value 208, tag values 212, and/or metric values 214 as
inputs. For example, contact value 206(a) that expires in
thirty-six months may have a higher priority value 216 than contact
value 206(b) that expires in six months. As another example,
contact value 206 tagged as "wrong party" or "disconnected" may
have a relatively lower priority value 216. Contact value 206
tagged as being the customer's preferred contact method may have a
higher priority value 216 than other contact values 206. Contact
values 206 indicating that the source line of business is the same
as the line of business requesting contact information 195 may have
a higher priority than contact values 206 obtained from other lines
of business. As yet another example, contact values 206 associated
with metric values 214 indicating that the customer was recently
contacted successfully, is frequently contacted successfully, or
has provided the same phone number/address to several lines of
business may have relatively higher priority values 216 than other
contact values 206.
[0048] FIG. 3 illustrates a flowchart for communicating customer
contact information. The method begins at step 304 by receiving a
request for customer contact information. In some embodiments, the
request may be initiated by a user via a website, such as a
password-protected or other secure website. The website prompts the
user to lookup a customer using any suitable search criteria.
Examples of search criteria include name, phone number, address
information, account number, social security number, or party
identifier.
[0049] At step 308, the method determines contact values associated
with the customer included in the request. The contact values may
be determined according to an identifier, such as the search
criteria of the request. In some embodiments, the contact values
are determined from a first set of contact values that a first line
of business associates with the customer and a second set of
contact values that a second line of business associates with the
customer. A set of contact values may include zero, one, two, or
more contact values. Contact values from various lines of business
may be aggregated prior to receiving a request. For example, the
method may aggregate the contact values and store them in a
database in advance. Alternatively, the contact values may be
aggregated in response to receiving the request of step 304.
[0050] Aggregating contact values may include combining all of the
contact values associated with the customer. Aggregating contact
values may further include consolidating the contact values by
applying a common format (e.g., standardizing the word "Street"
with the abbreviation "St.") and identifying and removing duplicate
contact values. A tag may be used to identify each of the sources
of contact values for which duplicates have been removed.
[0051] At step 312, the method determines priority information. As
described in FIG. 2, priority information may include tag values,
metric values, and/or priority values. The method may receive
inputs that include certain priority information, such as reasons
that previous contact attempts were unsuccessful. The method may
use an algorithm to generate other priority information, such as
metrics or priority values. Priority information may be generated
prior to receiving any request, for example, the method may
generate priority information and store it in a database in
advance. Alternatively, the method may generate priority
information in response to receiving the request of step 304. To
determine the priority information at step 312, the method may
determine the particular priority information associated with the
contact values determined in step 308. In some embodiments, contact
values and priority information may be associated with one another
if they belong to the same contact record.
[0052] The method communicates the contact info illation comprising
contact values and priority information at step 316. As an example,
the method displays the contact values and priority information via
the website that the user utilized to enter the request. The
contact information may be displayed in any suitable format, such
as a table format similar to that described with reference to FIG.
2.
[0053] The contact information communicated in step 316 may include
any suitable number of contact values, such as all of the contact
values associated with the customer or a selected subset of contact
values, for example, contact values having a high priority. In some
embodiments, the request of step 304 may indicate the contact
values to be provided. For example, a user building a contact list
for an automatic telephone dialer may indicate that only phone
numbers be returned. The user may further specify to exclude mobile
phone numbers from the list or to exclude a subset of mobile phone
numbers for which the customer has not provided express permission
to call. As an example, the user may wish to exclude such numbers
in order to comply with certain laws regarding automatic telephone
dialers.
[0054] The contact information communicated in step 316 may include
any suitable portion of priority information. For example, all of
the priority information associated with the contact values being
communicated, or particular tag values, metric values, and/or
priority values. Priority information may be communicated
expressly, for example, by displaying the priority information in a
table. Alternatively, priority information may be communicated
implicitly. As an example, contact values may be communicated in an
order sorted by priority. As another example, a subset of contact
values associated with requested priority information may be sent.
For example, the request may specify sending only high priority
contact values or only contact values tagged as phone numbers.
[0055] At step 320, the method determines whether feedback
information has been received from a user. Feedback may be
initiated by the user. For example, the user that requested the
contact information may select a feedback button on the website to
initiate providing feedback. Alternatively, the method may prompt
the user to provide feedback. The feedback may indicate the result
of an attempted contact, such as successful or unsuccessful, a
reason for the result (e.g., no answer, wrong party), and/or a
description of the attempt (e.g., the time of day). If it is
determined that feedback has been received, the method proceeds to
step 324 to perform an update according to the feedback, otherwise,
the method skips to step 328.
[0056] At step 324, the method performs an update according to the
feedback. Any data associated with the contact value may be updated
including, but not limited to, any tag value, metric value,
priority value, and/or expiration value belong to the same contact
record as the contact value. For example, if the feedback indicates
the contact was successful, the recency and success frequency
metrics may be updated accordingly. If the success indicates a
threshold level of successes has occurred at the time of day
indicated by the feedback, the time of day metric may be updated
accordingly. In some embodiments, an algorithm for calculating the
priority value may be run using the updated metrics to determine if
the priority should be increased.
[0057] The method proceeds to step 328 to determine whether a
vendor request message has been received. A vendor request message
requests a third party to provide additional contact values
associated with the customer. For example, a user may initiate
sending a vendor request message on behalf of a line of business if
attempts to contact the customer using the contact values
communicated in step 316 prove unsuccessful. Accordingly, the user
may seek additional contact values from a third party. A third
party refers to a party other than the enterprise and lines of
business of the enterprise, such as a vendor in the business of
supplying contact values. In some embodiments, the user may
initiate sending a vendor request message through a website
configured to accept request information according to a
pre-configured or common format. Table 1 below illustrates examples
of fields that may be included in a request message.
TABLE-US-00001 TABLE 1 Field Description Line of Business Indicates
the line of business of the user making the request. User
Identifier Identifies the user making the request. Request Type
Indicates the type of request. For example, whether the request
seeks information internal to the enterprise or information from a
third party. Customer Identifier Indicates the type of customer
identifier, such as Type social security number, party identifier,
account number, and so on. Customer Identifier Indicates the value
of the customer identifier, for example, social security number
123-45-6789. Supplier Search Indicates the type of search to be
performed. Type Examples include a contact information search or
other type of search, such as a credit report search. Supplier
Identifier Identifies the third parties to which the request should
be sent.
[0058] If a vendor request message is received at step 328, the
method proceeds to step 332. If no vendor request message is
received, the method ends.
[0059] At step 332, the method aggregates vendor request messages.
For example, the vendor request message of step 328 may be
aggregated with other vendor request messages received from users
making requests on the behalf of any line of business of the
enterprise. Aggregating may include combining the vendor request
messages and removing duplicates. In some embodiments, the vendor
request message format may be standardized across all of the lines
of business of the enterprise to facilitate identifying and
removing duplicates. Vendor request messages may be considered
duplicates if selected fields are the same, such as customer
identifier and supplier search type. Alternatively, vendor request
messages may be considered duplicates if selected fields are
determined to be equivalent. For example, if one vendor request
message requests information associated with a social security
number of Customer A and another vendor request message requests
information associated with a party identifier of Customer A, the
requests may be determined to be equivalent because they both seek
information for Customer A.
[0060] Aggregating the vendor request messages may increase
efficiency and reduce costs. For example, vendors may charge a
search fee for each request. By removing duplicate requests, the
enterprise may avoid incurring costs associated with unnecessary,
duplicative searches. Additionally, vendors typically charge a fee
for providing new contact values to an enterprise, but do not
charge a fee for providing contact values that the enterprise
already knows. Thus, the aggregated vendor request message includes
each of the contact values that the enterprise associates with the
customer. That is, the vendor request message not only includes
contact values provided by the line of business of the user that
submitted the vendor request message, but also includes any other
contact values that the enterprise associates with the customer,
such contact values provided by other lines of business of the
enterprise. Accordingly, the contents of the aggregated vendor
request message may be used to determine whether information
provided by the vendor is new information and thus, whether a fee
may be charged.
[0061] The method sends the aggregated vendor request message to
one or more vendors at step 336. A response is received from the
vendor(s) at step 340. The response includes contact values that
the vendor(s) associate with the customer. The method performs an
update at step 344. The update may include storing new contact
values for future use and/or sending the new contact values to the
user that submitted the vendor request message. In some
embodiments, the method may determine priority information for the
new contact values. As an example, the method may determine the
source as the vendor that provided the new contact values. As
another example, the method may determine to initialize metrics and
priority levels according to default values. As yet another
example, the method may determine whether each of the new contact
values corresponds to a phone number, an e-mail address, or a
street address based on its format. The method then ends.
[0062] Modifications, additions, or omissions may be made to the
systems described herein without departing from the scope of the
invention. The components may be integrated or separated. Moreover,
the operations may be performed by more, fewer, or other
components. Additionally, the operations may be performed using any
suitable logic comprising software, hardware, and/or other logic.
As used in this document, "each" refers to each member of a set or
each member of a subset of a set.
[0063] Modifications, additions, or omissions may be made to the
methods described herein without departing from the scope of the
invention. For example, the steps may be combined, modified, or
deleted where appropriate, and additional steps may be added.
Additionally, the steps may be performed in any suitable order
without departing from the scope of the present disclosure.
[0064] Although the present invention has been described in detail,
it should be understood that various changes, substitutions, and
alterations can be made hereto without departing from the scope of
the invention as defined by the appended claims.
* * * * *