Integrated pre-collections system

FIELD OF THE INVENTION

The present invention relates generally to collections of overdue debt. More specifically, the present invention relates to an automated system and method for the collection of debt integrated with an order processing system.

BACKGROUND OF THE INVENTION

Collection systems are used by a large number of businesses worldwide. In a typical scenario, a business will receive notice from the collection system that a customer's account is unpaid or overdue. The business then calls the consumer requesting payment of the unpaid balance. Typically the consumer is requested to send payment via mail. After this call the process starts over again and will check for payment at a specified time in the future. If payment is not made within a reasonable time the service may be shut off or the company may attempt to repossess the product.

Unfortunately, current collection practices are impractical for bad debt (for example, returned ACH items) of less than $50. Furthermore, if the goods or services purchased are immediately fulfilled and consumed, the lack of timely return information in the ACH system combined with the cost associated with current business practices for collections make collecting on the debt impractical. Yet an originator or ODFI (originating depository financial institution) suffers a material loss if the volume of low value transactions is significant. A merchant or individual may suffer a loss based upon an ACH item that is returned, because of a customer's bounced check, because of a person-to-person payment that cannot be settled, or any of a variety of other reasons. Unfortunately, current collection practices are not suitable for these low-value debts, and a merchant or individual suffers from the loss of a delivered product or service for a debt of any value. As mentioned above, whether the collection is instituted using an in-house process or by a collection agency, often the labor costs involved are greater than the amount of the debt.

A system and method are desired that would make practical the collection of these low-value debts and that would assist the merchant or individual in recouping any delivered products or services.

SUMMARY OF THE INVENTION

To achieve the foregoing, and in accordance with the purpose of the present invention, an integrated pre-collections system is disclosed that makes practical and efficient the collection of low-value debts and also allows for the reclamation of any delivered products or services.

The pre-collections system employs computer software, rules and statistical analysis to make the collection of low-value, high-volume transactions cost effective and is optimized for transactions that cannot be efficiently handled by traditional collection systems. By contrast, traditional collection systems involve a high degree of human labor to contact debtors and collect funds. This present system may be used by first party or third party collection teams. As most electronic payments are not guaranteed, the pre-collections system is especially suited for use with electronic payments such as ACH items that might be returned for nonpayment. In any situation where a merchant or individual has ostensibly been paid (whether by check, financial account, or other) but the payment is returned and turns into a debt, the present invention is applicable.

In addition to supporting these traditional collections procedures, the pre-collections system identifies debtors when they contact a company for a new purchase (or a follow-on purchase), and allows a customer service representative (or other automated process) to take payment for the prior debt in real time. In this fashion, the pre-collections system is tightly integrated with an order processing system. Whether the customer is attempting to place an order, contact customer service, or contact the company for another reason, the customer is identified as a debtor and steps may be taken to collect the debt immediately in real time. For example, all order processing system channels (web site, IVR, CSR, etc.) are enabled to redirect the customer debtor into a corresponding pre-collections system channel. If the customer pays the outstanding debt in the pre-collections system they are then routed back seamlessly in real time to the point in the order processing system where they left off. The customer can be re-instated immediately when their payment is cleared.

In other words, the pre-collections system advantageously captures debtor customers in any non-collections context and places them into a pre-collections context so that the debt may be paid and the customer reinstated immediately. The pre-collections system does not require human intervention to clear up a bad debt before accepting a new order (i.e., the system mitigates the “shame factor” of the debtor). The pre-collections system automatically communicates with debtors via an IVR system and allows the debtor to pay off the debt using the IVR system without the intervention of a human agent.

The pre-collections system is also applicable to situations where digital products and other services are immediately fulfilled or consumed. Once a determination is made that a digital product or service should be reclaimed, the pre-collections system is enabled to direct that reclamation occur. For example, if a customer has downloaded digital music, software etc., the pre-collections system issues a command utilizing digital rights management that disables the music or software. Or, a customer holding a gift card and having a bad debt may suddenly find that his or her account has been frozen or reduced. For other digital products, the pre-collections system automatically connects to a product distribution system and attempts to reclaim any unused product in order to reduce the outstanding debt. In the event that the entire product is reclaimed, this collection process is fully automated. In another example, where a customer has purchased air time from a wireless carrier, the remaining minutes in that account may be canceled at direction of the pre-collections system. The pre-collections system is also able to reclaim all or part of a product or service. By performing reclamation immediately, it is more likely that more of the product or service can be reclaimed.

The pre-collections system includes resubmission and reclamation logic in order to identify the best time to resubmit or reclaim based on multiple variables. The pre-collections system evaluates the customer's order pattern, their payment history, and the prior resubmission success rate in real time when an ACH payment is returned, and then determines the most appropriate actions regarding whether to reclaim air time (or unused product value) or to resubmit the payment request at a specific time.

The pre-collections system is also tightly integrated with fraud and payment systems in real time. For example, the pre-collections system consults a central repository of blacklisted payment devices fed from all real-time order processing systems. For example, if the order processing system blacklists a card the pre-collections system also rejects the card as a payment device. The pre-collections system can also influence the central repository by initiating a request to the order processing system to un-blacklist certain entities (i.e., payment devices, stored value accounts, customers).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a pre-collections system according to one embodiment of the present invention.

<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart of a method according to one embodiment of the present invention.

<figref idref="DRAWINGS">FIG. 3</figref> is a batch file record.

<figref idref="DRAWINGS">FIG. 4</figref> is a PCS database debtor record.

<figref idref="DRAWINGS">FIG. 5</figref> is a collection record.

<figref idref="DRAWINGS">FIG. 6</figref> is a response record.

<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate a computer system <b>900</b> suitable for implementing embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a pre-collections system <b>5</b> according to one embodiment of the invention. Pre-collections system <b>5</b> includes a pre-collections software module <b>20</b> in communication with a pre-collections database <b>25</b>. Module <b>20</b> is a real-time, redundant software application that is primarily message driven although it does include batch portions. The solid lines connecting boxes indicate RPC messages, while the dashed lines indicate batch communication. Module 20 is preferably implemented on a number of load-balanced computer servers such as the Dell “Power Edge” servers. Module <b>20</b> is implemented as a state machine and proceeds to different states depending upon input regarding a particular customer. Customer <b>7</b> can also provide input to module <b>20</b> via IVR <b>50</b> or CSR <b>60</b>.

Pre-collections system <b>5</b> includes an OLTP (Online Transaction Processing) system <b>30</b>. In one specific embodiment, OLTP system <b>30</b> incinerates a web-based channel, an IVR (interactive voice response) channel and a CSR (customer service representative) channel. Also possible is an SMS chapel that allows a customer to place an order using an SMS text message or an automated recurring channel. Examples of such an OLTP system are a wireless top-up payment system, a mail-order catalog call center, or an electronic-commerce web site.

In one embodiment, numerous OLTP systems are each implemented on a computer server, with each OLTP system being dedicated to serving a particular client compan. (For example, each client wireless company uses a separate, or perhaps multiple, OLTP servers). An incoming customer uses any of a variety of payment devices, such as a credit card, debit card, paper check, electronic check, prepaid card or an electronic money micro-payment scheme, such as an account from the P2P service, Paypal, or Google Checkout, to pay for a product or service from one of the client companies.

A payment account debit submitted by a merchant may result in a returned item to the merchant if there are insufficient funds or other account issues such as incorrect account number, closed account, etc. Such a returned item is entered into the pre-collections system <b>5</b> as an open collection item. Of course, other types of transactions may also be used and be submitted to the pre-collections systems as a returned item. Examples of these other types of transactions are credit card chargebacks and P2P repudiated payments.

Other payment devices besides checks may also result in a returned item being submitted to the pre-collections system <b>5</b>. For example, a credit card or debit card transaction may result in a chargeback that is then submitted to the system as a returned item. In these situations, because a chargeback exists, the pre-collections system will treat the chargeback similar to an outstanding debt and will flag the customer's order processing record (as explained below). Thus, if a customer attempts to reload a wireless account (for example) using the same credit card that was subject to the previous chargeback, the customer's account will be submitted to the pre-collections system for possible collection of the outstanding chargeback.

IVR <b>50</b> is typically an Interactive Voice Response (IVR) system such as used in a telephone-based OLTP system and is configured to process payment transactions from users wishing to pay their debt in full as a result of being contacted by the pre-collections system, or being re-routed there by the OLTP system's IVR <b>30</b>. CSR <b>60</b> is typically an employee who is trained to handle full, partial or security payment transactions from users wishing to pay as a result of being contacted by the pre-collections system, or as a result of attempting to purchase a different or new product (i.e., being routed from OLTP when attempting to make a new purchase in OLTP system <b>30</b>).

System <b>30</b> communicates with pre-collections software module <b>20</b> in numerous matters. In one situation, an IVR system of the OLTP system <b>30</b> transfers a customer call to IVR <b>50</b> when the customer calls regarding a new order (or other matter); the customer call is then routed back to the calling application (OLTP system) after debt payment is made. In a second situation, a real-time CSR application of the OLTP system connects to CSR system <b>60</b> via a hyperlink; the customer is then routed back to the calling application (OLTP system) after debt payment is made.

Payment system <b>40</b> is connected to one or more payment processors <b>10</b> and is a front-end system that initiates payment-to-payment to acquirers on behalf of a merchant or merchants. Payment processor <b>10</b> is a bank or other processor that may handle an ACH transaction, or other payment transaction as described above. As is known in the field, the ACH (Automated Clearing House) is a system of the U.S. Federal Reserve Bank that provides electronic funds transfer between banks. It is used for a variety of funds transfer transactions. ACH operations are typically done in a batch mode, which can take up to 72 hours before money is transmitted. A return notification (a returned item) is sent if the receiving depository financial institution (RDFI) is unable to fund a request from the originating depository financial institution.

E-mail server <b>65</b>, SMS gateway <b>70</b> and auto-dialer <b>80</b> are typically used to send automated messages to the customer regarding unpaid debt. E-mail server <b>65</b> is a computer serverar ranged to send e-mail messages to customers. SMS gateway <b>70</b> is typically a third-party system connected to multiple wireless carriers (or is a gateway of a single carrier) suitable for transmitting text messages to wireless telephones. Auto-dialer <b>80</b> is a computer-based telecommunications device arranged to automatically dial and play recorded messages to customers, and allows customers to transfer to IVR <b>50</b> to make a payment in real-time, or to transfer to CSR <b>60</b> to speak with a representative and pay a debt. The pre-collections system adjusts the real-time queue for the auto-dialer based on current payment status. A debtor can be queued to the auto-dialer for various reasons. In real time as entries are de-queued there are various checks to insure the debtor should still be called. Some criteria that will affect the queued entries are: day of week, current time, time zone of the debtor, payment status, status updates on the debtor, etc. Letter processor <b>90</b> is used to send unpaid debt notices to a customer and is typically a third-part that specializes in sending mail notices. Collection agency <b>95</b> is typically a third party that handles collections that fail to be resolved by the pre-collections system and is known to those of skill in the art.

Each of these systems <b>65</b>-<b>95</b> is known to those of skill in the art. The systems may be external to operation of the pre-collections module <b>20</b>, or may also be internal systems. In general, these systems are all mechanisms for contacting a customer and taking payment; of course, other systems and techniques to contact a customer may also be used. Further, each of systems <b>65</b>-<b>90</b> may also be implemented by a collection agency or by any entity holding a collections license.

PRE-COLLECTIONS PROCESS

<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram describing how a returned item triggers the pre-collections process. The pre-collections system (PCS) <b>5</b> is linked to payment processor <b>10</b> and is arranged to receive returned items. In step <b>204</b> pre-collections module <b>20</b> receives a returned item from the payment processor (ultimately coming from the receiving depository financial institution (RDFI)) indicating that payment by the customer was lacking funds (or perhaps due to another reason). If this returned item is the result of an attempted ACH payment, this may be any of a variety of ACH returned items. If the returned item is a result of an attempted ACH payment, the returned item is typically accompanied by a return reason code (“R” code) indicating the reason or the return, such as invalid account, unable to collect, resubmit, account closed, deceased, etc. Relevant return codes are listed in Table 1.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Return Codes</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry> R01 - Insufficient funds</entry></row><row><entry /><entry> R02 - Account Closed</entry></row><row><entry /><entry> R04 - Invalid Acct Numbers</entry></row><row><entry /><entry> R09 - Uncollected Funds</entry></row><row><entry /><entry> R12 - Account Sold to Another DFI (formerly: Branch</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>Sold to Another Bank)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry> R20 - Non-transaction account</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry> R03 - No Acct, Unable to locate account</entry></row><row><entry /><entry> R07 - Authorization Revoked by Customer (only if a</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry> PPD tx or &gt; first time TEL)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry> R08 - Stop Payment</entry></row><row><entry /><entry> R10 - Transaction not authorized</entry></row><row><entry /><entry> R14 - Payee Deceased</entry></row><row><entry /><entry> R16 - Account Frozen</entry></row><row><entry /><entry> R52 - Stop Payment</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Module <b>20</b> maintains a list of flags, each flag being associated with different categories of “R” codes. These flags are used to assist in controlling a state machine that implements the logic of the pre-collections module. In one specific embodiment, returned items are delivered from the ACH processor in the form of a daily batch file, typically one batch file per merchant. Each batch file is preferably in a standard format, and contains numerous batch file records <b>110</b> such as shown in FIG. <b>3</b>. Each record indicates a returned item from a particular customer order (e.g., a bounced check). Reference number <b>112</b> is a unique identifier that identifies a particular returned (original) order. For example, when an order is submitted from order processing system <b>30</b> (for example) to payment system <b>40</b> an order number is supplied that identifies a particular customer order, and it is this order number that is used as the reference number. In this way, reference number <b>112</b> can be used to index a particular customer order from the order processing system <b>30</b>.

Record <b>110</b> also includes the checking account number, routing number, amount, and a return reason code as shown. Other relevant fields include a return type code, a transaction code, a receiving DFI identification, a logo identification, a check digit, a DFI account number, and individual identification number, a check serial number, and individual name, a receiving company name, a card transaction type code, a record indicator, a trace number, etc. More detail can be found in the NACHA manual.

In step <b>208</b> the received batch file is used by module <b>20</b> to create new collection entries within the pre-collections system. As previously mentioned, pre-collections system <b>5</b> includes a pre-collections system (PCS) database <b>25</b> that is linked to, or part of, pre-collections module <b>20</b>. <figref idref="DRAWINGS">FIG. 4</figref> illustrates an example debtor record <b>130</b> from that database. Record <b>130</b> will be expanded to include more and detailed information once a response from the “collection entry open” call is received as shown in FIG. <b>6</b>.

In this step module <b>20</b> first creates a new debtor record <b>130</b> in database <b>25</b> for each returned item. Next, module <b>20</b> accesses OLTP processing system <b>30</b> using the reference number <b>112</b> from a batch file record in order to access a particular customer order. Once an order is identified using the reference number (i.e., the original order number) the relevant customer data and order data from that original order is retrieved and populated into the newly created debtor record in the PCS database <b>25</b>. For example, the information retrieved and populated into debtor record <b>130</b> is customer name and birth date, address and telephone number, state and driver license innovation, the original OLTP system name, a product identifier, an account number (if applicable), the customer time zone, a partner code, and a follow-up date.

Thus, a new debtor record <b>130</b> is created in database <b>25</b> for each batch file record from the batch file received from the ACH processor. Each debtor record will be used by not only the pre-collections module <b>20</b>, but also by the OLTP system <b>30</b> to attempt debt collection and to retrieve any unused goods or services.

Step <b>212</b> begins the pre-collections process. The first step is a “Collection Entry Open” call <b>214</b> from module <b>20</b> to OLTP system <b>30</b>. As shown, OLTP system <b>30</b> includes an OLTP processing system database <b>35</b>. <figref idref="DRAWINGS">FIG. 5</figref> illustrates an example collection record <b>150</b> from that database. When the call is made, the OLTP processing system creates such a new record in its database with information regarding the customer and the returned item. For example, record <b>150</b> includes a collection identifier, a debtor identifier, a reference number, a checking account number, a routing number, an amount, a return reason code, a date and time stamp, an original order number and an original order date.

The response from the order processing system in response to the “Collection Entry Open” call is a record as shown in FIG. <b>6</b>. The “Collection Entry Open” call is initiated by the PCS and sent to the order processing system. The order processing system generates a response back to the PCS in the form of the record of <figref idref="DRAWINGS">FIG. 6</figref>, for example. This information in the response updates and populates the debtor record <b>130</b> of the PCS with additional information, and is also referred to as a “collection entry” once completed. The collection entry is managed by the PCS for the purpose of being collected on and generating outbound correspondence to the customer to notify them of this pending collection. The PCS manages the timing and coordination of a<b>1</b>l this outbound correspondents. The PCS also tracks all payments made on an open collection entry.

Database <b>35</b> is visible and used by all of the relevant channels by which the OLTP processing system is accessed, e.g., Web, IVR, CSR, etc. Thus, any future request by a customer coming to OLTP system <b>30</b> will necessarily raise a flag within the OLTP system if such a record is present in the database indicating that that particular customer (or a particular account) has had a returned item or is a debtor for any particular reason. The customer can then be redirected for debt collection.

In other words, in the event the customer returns for a subsequent purchase, regardless of the sales channel the customer uses (IVR, CSR, Web, etc.) to make the purchase, the OLTP system flags the order attempt using the customer's account information (payment device, telephone number, address, and a variety of data points) and redirects the customer to the pre-collections module <b>20</b> and possibly to an agent to discuss the outstanding debt. The customer account innformation is used to identify a customer; the OLTP system <b>30</b> references (or searches) each customer account field and, if a record is flagged as having an outstanding debt, the customer is redirected to module <b>20</b> for collection payment.

It should be noted that the customer may also be identified as a previous debtor in situations other than the customer returning for a subsequent purchase via the order processing system. For example, the customer may make personal contact with a particular store, make contact with a company representative over the telephone, by electronic mail, or by visiting a web site, for reasons unrelated to making a purchase. Examples of how a customer might make contact with the company and thus be able to be identified as a previous debtor include nearly any communication through which a company becomes aware of a particular customer's identity, becomes aware of a product or service that has been purchased and not paid for, or becomes aware of a particular payment device associated with an outstanding debt. For example, when the customer who owes money dials a telephone number they may automatically be switched to the collections center before their call is permitted to continue. Also, the customer can be contacted when engaging in unrelated activities with the same vendor (e.g., the customer logs in to ESPN.com to check their fantasy sports scores and is provided with notice about an unpaid bill on their ESPN mobile phone).

The customer may also directly reach pre-collections module <b>20</b> by calling either IVR <b>50</b> or CSR <b>60</b>, by being transferred to either IVR <b>50</b> or CSR <b>60</b> by third party agency <b>95</b>, by a real-time call transfer from a CSR of system <b>30</b> or from an IVR of system <b>30</b> using a hyperlink to CSR <b>60</b>.

Once the customer is in communication with IVR <b>50</b> or CSR <b>60</b> (which in turn are in communication with module <b>20</b>) the customer can elect to complete an automated process to remit the outstanding debt using the IVR, or the customer may talk with a CSR about remittance. Using IVR <b>50</b> or CSR <b>60</b> the customer is prompted for payment device information such as credit card, debit card etc. If the payment via the payment device is accepted, pre-collections module <b>20</b> marks the debt as paid in pre-collections system database <b>25</b>, and in real time sends to OLTP system <b>30</b> a collection entry closed message that updates the collection record in OLTP system database <b>35</b>.

The pre-collections system is programmable to handle various payment types identified by return codes. The system supports three payment options: cash, check or credit card. Two factors are applied to determine the allowable payment options for a debtor. One is the “R” code returned from the ACH network. The second is the Revenue Assurance specialist permission level. Also, a debtor might have multiple returned checks for multiple returned payments. In this case, the allowed payment options are determined by the most restrictive case.

In this fashion, a debtor customer is captured during a non-collections context and is redirected into the pre-collections system in order to more easily facilitate payment of the debt.

A second part of pre-collections process <b>218</b> involves blacklisting any suitable account, customer or payment device in order to flag that any future use of this account, future access by this customer, or future use of this payment device is suspect. In a preferred embodiment of the invention, blacklisting will always occur when an item is returned, i.e., blacklisting occurs in addition to any attempt to collect from the customer outside of a collections context. In particular, pre-collections module <b>20</b> is arranged to blacklist any stored value account, any particular customer, any particular driver's license, or any particular payment device used by customer (such as a credit or debit card). Blacklisting may be performed using a flag, database record, or other similar mechanism. In one specific embodiment, blacklisting is performed by OLTP system <b>30</b> by updating records in database <b>35</b> which match specific attributes such as payment device, driver's license number, customer number, account number, etc.

Blacklisting provides a second layer of protection, over and above the flagging of the customer using a debtor record as explained above. Because blacklisting is able to flag a particular payment device, a different customer returning to the OLTP processing system using the same payment device will be suspect. In addition, because a particular customer is also flagged, the same customer returning using a different payment device will also be suspect. Once the customer (or account or flagged payment device) returns via the OLTP processing system and it is determined that the customer, device or account has been blacklisted, control is shifted to a Revenue Assurance specialist (another type of customer service representative) who is alerted that the pending transaction is suspect. Control to the RA is performed via a phone transfer. The RA in one embodiment is a member of module <b>60</b>.

At this point the customer is not necessarily turned over to IVR <b>50</b> or CSR <b>60</b> in order to be processed by precollections module <b>20</b>, but such transfer is possible. Preferably, the RA specialist discusses the debt with the customer by telephone (or by e-mail, Internet chat, instant messaging, or by whatever means the customer has initiated contact) and attempts to arrange payment of the debt. The RA is able to arrange a full or partial payment of the customer using module <b>60</b> in a manner as described above. The RA can accept payment for the debt via credit card, in some cases via a new electronic check payment, or can provide the customer with instructions for mailing a paper check or money order, or initiating a payment though a money transfer service such as Western Union.

In this fashion, a blacklisted customer (or account or device) attempting to use the OLTP processing system is captured by pre-collections system <b>5</b> in order to settle a bad debt. Advantageously, the customer is captured outside of a normal collections process thus leading to a higher likelihood of payment.

A customer might interact with the system in different contexts. For example, a customer who initiates communication by performing a new transaction (such as in the purchase) or by making a subsequent purchase would typically be handled by IVR or CSR. The system is then able to flag a customer who is an existing debtor and attempt to resolve payment via one of these channels. Even if the customer is returning for a simple purchase, if the customer states he or she is not responsible for a previously unpaid purchase or has a special request (such as waving a late fee), then the system routes the customer to a RA specialist.

Alternatively, if a customer simply contacts the system to inquire about a collections letter received or other notice, the customer will typically be routed directly to the RA specialist. This specialist is more highly trained, can resolve particular issues and has the authority to make decisions regarding the outstanding debt. Both of these above routes occur before the outstanding debt is sent to a third-party collections agency for collection.

If the customer does not return for a subsequent purchase or other interaction with the system, the system automatically contacts the customer via telephone, mail, web, e-mail, SMS or other means to inform the customer of the returned ACH item. The customer may then return via module <b>50</b> or module <b>60</b> to respond to the requested payment of debt.

A third part of the pre-collections process seeks to recover any remaining product or service that the customer has not yet consumed in step Reclaim Value <b>216</b>. In other words, once the customer and product he or she has ostensibly purchased has been identified (including other information such as an account number), pre-collections module <b>20</b> initiates action to reclaim any portion of this product or service not yet used. By attempting to reclaim any remaining value in the product or service immediately upon notification of a returned item, the pre-collections system has a much better chance of reclaiming a larger portion of that product or service before it is consumed by the customer.

For example, in the case of a mobile telephone wireless account, the system takes action to cancel any remaining minutes left in the customer's wireless account. This cancellation of the remaining minutes is performed by a real-time call over a network link to the wireless billing platform to deduct minutes. In another example, any prepaid minutes equal to the amount sold and associated with the debt in a long-distance calling plan are likewise deducted (or removed) in a similar manner as described above.

In another example, a customer holding any type of prepaid card (such as a gift card containing a dollar value) will find that the dollar value of that prepaid card account has been reduced by the amount of the failed attempt to add monetary value to the card. In this case, a real-time call over a network link to the card issuer's billing platform is made to deduct the correct monetary amount from the card balance.

This step <b>216</b> to reclaim any product or service that has been delivered to a customer is also applicable to most any digital product or service. For example, using technology known as digital rights management (DRM) a seller of any digital goods such as music, software, text, graphics, an electronic book, etc., can configure the digital goods in such a way so that the goods may be disabled at a future point in time. The use of digital rights management to control access to digital goods and to disable digital goods at a future point in time is well known to those in the field. Thus, once pre-collections module <b>20</b> is aware that a particular customer is in default of payment for a particular digital good or service, the pre-collections module initiates an action to disable that particular digital good or service using digital rights management technology embodied in that good or service. For example, a customer having downloaded music or software will suddenly find that the music or software suddenly will not play or work. Pre-collections module <b>20</b> can disable a digital good or service by marking or deactivating a license key in a centralized DRM scheme, or by preventing future digital purchases until the debt is collected.

Thus, the system automatically retrieves any unconsumed, fulfilled goods from the consumer or business customer. The outstanding balance for goods consumed but not paid is recorded in the system as an open collectable loss.

SYSTEM ANALYSIS

The pre-collections system employs rules and logic to determine whether it is more advantageous to attempt reclamation of fulfilled goods, to automatically resubmit for payment (for eligible returned items), or to contact the customer via another means. The pre-collections system creates a “collection score” to help determine system workflow. The pre-collections system evaluates the customer's payment history, order patterns, collectible amount, current collection staffing level and estimated collection cost in order to determine the most efficient course of action.

An administrator sets up a number of workflows in the system based on a product category. For example, one workflow is: attempt to reclaim product, call customer, send letter. Another workflow is: send letter, call customer, and send to third party agency. Based on the predicted collectable amount (which can be expressed as a percentile ranking of the debtor using statistical analysis), the system routes the collection account to the appropriate workflow. The system uses statistical analysis to optimize the series of steps so that the result is the highest payment for the returned ACH item at the lowest possible collection cost. The system uses three phases to perform the above process.

In the first phase, the system calculates a predicted collectible amount, a predicted resubmit success amount and a reclaimable amount, these values indicating respectively, how much could be collected from the customer, how much could be realized by resubmitting the returned item, and how much could be realized by reclaiming a product or service from the customer.

For a particular customer who owes a debt the system uses a logistic regression model to calculate a “predicted collectable amount” as below based on various demographic and transactional parameters. The collection score indicates a probability of the likelihood of the debt payment and indicates generally, good customers, average customers and bad customers. In other words, collection score indicates a probability of the collection being a success. For example, a collection score is calculated from the customer's zip code, information from the bank that maintains the customer's checking account, the product amount, the return reason code, and the customer's payment history. <br />Predicted collectable amount=(amount due)*(collection score)−cost.

The system also calculates a “predicted re-submit success amount” based on the demographic parameters, the amount due and the customer's payment history. The variable “resubmit success probability” is calculated by using the date or day of the returned check, product amount, zip code, bank and payment history. This variable indicates the probability of success of resubmitting the returned item and receiving payment. <br />Predicted re-submit success amount=(amount due)*(resubmit success probability−cost.

Next, the system calculates a reclaimable amount indicating how much value can be reclaimed from the customer by reclaiming a particular product or service that the customer is using. For example, the reclaimable amount is queried from a stored value device's platform. The reclaimable amount is the remaining unused value on the device.

Finally, the system compares these three values for a particular debt (predicted collectible amount, predicted resubmit success amount and reclaimable amount) and determines a particular workflow to obtain the highest payment on the debt. For example, the system might decide to attempt reclamation immediately, resubmit the item a day later, or proceed immediately to a collection. Or, the system might attempt reclamation of only a portion of the debt, and also attempt collection.

Phase two involves performing any reclamation or resubmission decided by the system. After any reclamations and resubmissions, phase three decides which debts to collect upon. The system compares the remaining “Predicted collectable amount” for all debts that need to be collected from all possible customers and maximizes collections by choosing the best subset of debtors on which to focus collections resources. In other words, the system may choose to initiate collections only on the top certain percentiles of the predicted collectible amount values based on staffing levels.

When the debt is paid, the customer is reinstated and new orders can be processed and fulfilled. In specified instances, the customer's future payment options are restricted. When the debt is paid in full—by any means, reclamation, payment or a combination of both—then the open collection account in the system is satisfied (i.e., it becomes zero). The customer no longer has outstanding debt; if the customer then returns to make future purchases, he or she can do so unimpeded. If the customer is a serial debtor, the account can be placed into a special status so that future orders are prevented even though the customer has fully paid his or her debts.

COMPUTER SYSTEM EMBODIMENT

<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate a computer system <b>900</b> suitable for implementing embodiments of the present invention. <figref idref="DRAWINGS">FIG. 7A</figref> shows one possible physical form of the computer system. Of course, the computer system may have many physical forms including an integrated circuit, a printed circuit board, a small handheld device (such as a mobile telephone or PDA), a personal computer or a super computer. Computer system <b>900</b> includes a monitor <b>902</b>, a display <b>904</b>, a housing <b>906</b>, a disk drive <b>908</b>, a keyboard <b>910</b> and a mouse <b>912</b>. Disk <b>914</b> is a computer-readable medium used to transfer data to and from computer system <b>900</b>.

<figref idref="DRAWINGS">FIG. 7B</figref> is an example of a block diagram for computer system <b>900</b>. Attached to system bus <b>920</b> are a wide variety of subsystems. Processor(s) <b>922</b> (also referred to as central processing units, or CPUs) are coupled to storage devices including memory <b>924</b>. Memory <b>924</b> includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories may include any suitable of the computer-readable media described below. A fixed disk <b>926</b> is also coupled bi-directionally to CPU <b>922</b>; it provides additional data storage capacity and may also include any of the computer-readable media described below. Fixed disk <b>926</b> may be used to store programs, data and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It will be appreciated that the information retained within fixed disk <b>926</b>, may, in appropriate cases, be incorporated in standard fashion as visual memory in memory <b>924</b>. Removable disk <b>914</b> may take the form of any of the computer-readable media described below.

CPU <b>922</b> is also coupled to a variety of input/output devices such as display <b>904</b>, keyboard <b>910</b>, mouse <b>912</b> and speakers <b>930</b>. In general, an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers. CPU <b>922</b> optionally may be coupled to another computer or telecommunications network using network interface <b>940</b>. With such a network interface, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Furthermore, method embodiments of the present invention may execute solely upon CPU <b>922</b> or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing.

In addition, embodiments of the present invention futher relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and excute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter.

Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Therefore, the described embodiments should be taken as illustrative and not restrictive, and the invention should not be limited to the details given herein but should be defined by the following claims and their full scope of equivalents.