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.

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to customer contact databases and more specifically to providing a centralized customer contact database.

BACKGROUND OF THE INVENTION

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

In accordance with the present invention, disadvantages and problems associated with known customer contact databases may be reduced or eliminated.

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.

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.

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

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:

FIG. 1 illustrates an example of a system that aggregates customer contact information to facilitate contacting customers;

FIG. 2 illustrates an example of customer data stored in a database of server memory; and

FIG. 3 illustrates a flowchart for communicating customer contact information.

DETAILED DESCRIPTION OF THE INVENTION

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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”).

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.

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.

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.

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.

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.

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.

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.

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.

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%.

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.

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.

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.

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.

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.

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.

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.

The method communicates the contact information 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.

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.

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.

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.

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.

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 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            Indicates the type of customer identifier, such as social
Identifier Type     security number, party identifier, account number, and
                    so on.
Customer            Indicates the value of the customer identifier, for
Identifier          example, social security number 123-45-6789.
Supplier Search     Indicates the type of search to be performed. Examples
Type                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.

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.

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.

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.

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.

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.

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.

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.

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; and a second set of contact values that a second line of business associates with the customer; 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; and a second set of contact values that a second line of business associates with the customer;

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; and a second set of contact values that a second line of business associates with the customer;

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.