The present invention relates to a system, process and computer program for exchanging cash change, owed by a vendor to a customer as a result of the customer purchasing a good or a service from the vendor, for an alternative offer of a good or a service.
When a customer pays for shopping in cash, he or she typically receives change consisting of a combination of high and low denominations of notes and coins. Low denomination cash, especially low denomination coins, may be inconvenient and undesirable for consumers, being viewed as less desirable than an equivalent value in high denomination cash and/or electronic cash. For example, low denomination coins are heavy and occupy more wallet space than an equivalent cash amount of higher denomination notes and coins. This may be particularly inconvenient for a customer who engages in small shopping tasks while travelling to/from his or her workplace; place of residence; or vehicle.
Stores sometimes provide a tip jar to relieve shoppers of the burden of carrying around unwanted change. However, the average shopper buying a litre of milk at the local store, for example, may not feel that the burden of carrying around the relevant change is ameliorated by donating the change to the shop attendant as a tip.
Consumers have previously accumulated low denomination cash received as change and delivered it to their local banks for deposit into their bank accounts. However, this process typically involves the step of bagging the coins into predetermined amounts and transporting the weighty coins to the bank. Consumers have, alternatively, accumulated low denomination cash received as change and used an automated coin counting machine to consolidate its value into higher denomination cash; or vouchers, for example. However, it may be generally inconvenient and time-consuming to accumulate change and to later safely transport it to such a machine. This is especially the case where low denomination change is frequently received.
It is generally desirable to overcome or ameliorate one or more of the difficulties of the prior art, or to at least provide a useful alternative.
In accordance with the present invention, there is provided a system for exchanging cash change, owed by a vendor to a customer as a result of the customer purchasing a good or a service from the vendor, for an alternative offer of a good or a service, said system for performing the steps of:
In accordance with another aspect of the present invention, there is provided a process for exchanging cash change, owed by a vendor to a customer as a result of the customer purchasing a good or a service from the vendor, for an alternative offer of a good or a service, including the steps of:
In accordance with another aspect of the present invention, there is provided a computer program for exchanging cash change, owed by a vendor to a customer as a result of the customer purchasing a good or a service from the vendor, for an alternative offer of a good or a service, said program for performing the steps of:
Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, in which:
The system 100 for exchanging cash change, owed by a vendor to a customer as a result of the customer purchasing a good or a service from the vendor, for an alternative offer of a good or a service shown in
Each store system 102 includes an in-store machine 112, e.g. a standard personal computer. The store system 102 also includes a seller interface 114 and a customer interface 116 for communicating with the seller and the customer in the store 102. Store hardware further includes a scanner; a customer display unit; a receipt printer; and a regular printer.
The administrator system 110 includes an administrative server 106 operable by a system administrator via an administrator interface 112. The administrative server 106 stores and distributes data relating to:
The system 100 is used at the point of sale in a store to generate, for a customer, one or more alternative offers in lieu of cash change. The system 100 allows customers, for whom small change is an inconvenience, to take up an offer that represents something of value to them, such as a voucher for a product, rather than receiving a pocket full of cash change.
The system 100 preferably provides a customer with an offer of value instead of cash change. The offer is selected to provide ongoing, or increased, profitability for a store 103, or chain of stores 103, and to provide a high perceived value for the customer. The perceived value for the customer may be influenced by the absolute amount of the change owed; the coin component of the changed owed (especially for low denomination coins); and the customer's willingness to receive an offer in lieu of the change owed.
The offers made to customers can typically be characterised into three distinct types:
An offer voucher can be highly flexible. For example, the voucher can be printed as a receipt generated by the store system 102. The value of the voucher (i.e. offer value) and the nature of the voucher (i.e. the offer description) may be selected at the point of sale based on data from an analysis of the items purchased by the customer; and up-to-date data regarding costs of products in the store 102 and from the administrator system 110. For example, if the system detects that the person purchased milk, then the voucher may be for discounted milk on the person's next visit to the store.
A voucher may be redeemable for a free product (e.g. receive a free Slurpee); a discount on a product (e.g. 4 cents off per litre for fuel); or for a discount on purchase of combination products (e.g. a soft drink and pie for $1). Offers in the form of vouchers may be preferable for a store owners as the outstanding liability represented in the voucher can be limited by specifying an expiry date for each offer. For example, the voucher may be void after a certain period of time. A further benefit of using a voucher is that there is less delay than that associated with charging value onto a stored value card, which may include scanning the card, entering identification details, etc.
The offer value, related to the value of the change, may be loaded onto a stored value card, such as a store-specific card that allows expenditure of the stored value only in specific locations. Such a card may have security features including magnetic strips, chips and/or RFID components (e.g. a smart card). Example stored value cards include a VISA prepaid card, a ‘myki’ card (Victorian State Government public transport card), a ‘Black Hawk’ gift card, and a store-specific card issued by the store 102 or chain of stores (e.g. a ‘MyerCard’ issued by Myer, in Australia).
A charitable donation can be made directly in lieu of the cash change due, or at least a portion of the change (e.g. that portion comprising low value coins). This form of charitable donation is less time-consuming and more efficient in terms of time and effort than other charitable regimes (e.g. manually collecting coins, or writing cheques to charities). An offer relating to a charitable donation can be updated at any time by the administrator 110, such that up-to-date charitable donations are available to the customer. For example, a charitable donation may be available as an offer in the minutes or hours following an emergency, rather than days later as traditional methods for collecting donations are organised and distributed.
For example, a customer may purchase $4.35 worth of goods with a $5 note. Instead of receiving 65 cents in cash change, the customer may take up an offer of a voucher for a free drink, which may be redeemed at the same store (or different store) on a subsequent visit. The offer value is determined by the system 100 based on the value of cash change that the customer is owed. For example, if the customer was owed $3.25 in change, a voucher of higher value is generated, than in the case where the customer is owed 65 cents in change. The offer may be based on one or more of the following values:
The perceived value will be impacted by the type of product being offered. The system 100 can optimise the perceived value by generating an offer that is particularly relevant to the customer. That is, the offer may be personalized to the customer based on the customer's profile. Information relating to a customer's profile is provided by an analysis of the products being purchased by the customer in the store 102. For example, if the customer purchases a Slurpee™, then a relevant offer may be for a free Slurpee™ on the customer's subsequent visit. The process performed by the system 100 is referred to as “basket analysis”. That is, analysis of the basket of goods/services purchased by the customer at the point of sale, to generate information on possible offers of interest for a customer. The information on possible offers of interest for a customer may be supplemented by a database of known co-buy information. That is, information relating to which products are commonly purchased in combination by customers. Information on co-buys is collected in the store system 102 and transmitted via a data network (e.g. the Internet) 104 to the administration server 106, which stores a database of co-buy data in an administration database 108. The administration database 108 may be further supplemented by co-buy information from third parties, e.g. survey data or data relating to known shopping behaviours.
The system 100 may increase the speed with which cash transactions can be carried out, as there is, advantageously, less need to distribute cash change owed to customers. There is also no need for the customer to receive and store high value change (e.g. notes), and low value change (e.g. coins). Furthermore, when a substantial portion of cash change is replaced by non-cash offers, the store 103 may reduce its change float, i.e. the store 103 requires less cash change to be available. A reduction in float may have a beneficial effect on cash flow management.
The system 100 is adapted to perform the following process:
Each one of these processes is explained in detail below.
The offers available to customers are generated by the administrator system 110 and stored by the administrative server 106 with the administrative database 108. The steps 200 performed by the system 100 to generate an offer are shown in
The administration server 106 verifies, at step 204, that the values in the offer parameters meet predetermined selection criteria that specify minimum requirements for allowable offers. The verification step 204 checks that all parameters contain relevant data. The verification step 204 also determines whether the offer value lies within an acceptable range in relation to its corresponding change value.
The offer typically includes Sale Conditions, represented on the data record described above, which are defined either as specific articles or as categories, which relate to the goods/services purchased in the customer's basket. For example, the offer may only be available if the customer has purchased goods of at least a certain value (e.g. over $30) or that goods of a certain category have been purchased (e.g. cigarettes, or petrol). The sale conditions impose business rules that analyse data from the basket analysis of a customer's basket, and there from determine whether the offer can be activated for a particular customer/sale (i.e. based on profile data of the customer). The offer may also specify an offer in a particular store 103, for example only stores in certain locations, e.g. in the state of Victoria.
The offer may also define one or more Redeeming Stores, i.e. stores where the offer, at least in the case of a voucher, may be redeemed. For example, a voucher may only be redeemed at the same store 103 in which it issued, or alternatively only in stores owned by a common entity and/or franchise network. An offer may also specify redemption conditions, i.e. the price required to be paid when redeeming a voucher, or the goods for which the voucher is redeemable. This may include an offer price, i.e. the price to be paid in order to redeem the offer. This may be zero, or a small value, e.g. pie and coke for $1.
The offer, in the case of a voucher, may also specify and grant a rebate which is offered by a third party to artificially depress the cost of issuing the voucher for the store 103. For example, a manufacturing or distribution company, e.g. Coca-Cola Amatil, may provide and grant a rebate such that vouchers for a particular product, e.g. Coca-Cola, can be issued for a disproportionately small change amount.
The sale conditions of a voucher offer may allow selection of the offer when the basket analysis process indicates that a customer has purchased a product from a competitor. For example, a voucher for a free product may be provided in a voucher that is selected by the offer selection process when the basket analysis indicates that a competitor's product has been purchased from analysis of the sales data. This mechanism may be particularly useful for new product launches, where an existing product from a competitor is identified in the customer's basket of shopping.
The offer description also includes specification of an offer expiry, which includes the expiration period on a voucher, and the period for which the offer is available to consumers.
If a generated offer does not meet selection criteria in the offer generation process, then corrected offer parameters are received from the administrator (repeat step 202). When the offer meets the selection criteria (step 204), the offer details are saved, at step 206, in the administration database 108 in an offer database.
When a customer presents products for purchase in the store 103, the in-store machine 112 performs the cash change offer generation process 300 shown in
In alternative embodiments, the cash change amount data may be received instead of the cash payment data, wherein the change amount in calculated by, for example, a cash register.
Once the cash change amount is generated, at step 306, the in-store machine 112 generates, at step 308, a plurality of change portion amounts, representing a plurality of possible change amounts that represent smaller instances of the change. For example, a change amount of $4.95 may comprise two $2 coins, one 50 cent coin, 2×20 cent coins and one 5 cent coin. The two $2 coins may be of sufficiently high denomination to be desirable to the customer as change, and the smaller instance of change is then 95 cents, comprising the 50 cent, 2×20 cent and the 5 cent coins. Each change amount is broken up into change portion amounts, thus providing a plurality of possible change amounts that may be used to generate a plurality of offers, for the customer, depending on the amount of change that the customer wishes to receive or relinquish.
The in-store machine 112 generates, at step 310, valid offers for the customer based on the change portion amounts, and the available offers from the offer database. Data in the offer database may be accessed directly in the administration database 108, or may be stored by the in-store machine 112 and updated periodically through the connection to the administration server 106. The validity of each available offer is determined in accordance with the selection criteria defined in the parameters of the offer, as generated, at step 310, in the offer definition process of
If a plurality of valid offers is generated, at step 310, in the valid offer generation process, then the in-store machine 112 may select only one of the valid offers, and this selection may be a random selection. Alternatively, a plurality of valid offers may be communicated to the customer, for example one valid offer in each Offer Category (i.e. either a product offer, or a charity offer).
Once valid/relevant offers have been generated, at step 310, the in-store machine 112 sends, at step 312, descriptions of the valid offers to the seller interface 114 and/or the customer interface 116, allowing the customer to select one or more of the valid offers in interactive display, or allowing the seller to describe the offer/s to the customer. For example, the seller may ask the customer whether they wish to receive their change as cash, or as a voucher, or make a charitable donation to a particular charity.
If the customer accepts one of the valid offers from step 312, the seller or the customer indicates this acceptance through the seller interface 114 or the customer interface 116, and the in-store machine 112 receives the acceptance data at step 314. The in-store machine 112 transmits, at step 316, the acceptance data to the administration server 106, where a record is made of the customer's selection, and accounting details are generated for administration of the system 100. The administration server 106 also updates its database of offers, for example to generate a new redeemable voucher record representing a voucher that has been issued, so that the system 100 can account for an outstanding liability generated by issuance of the voucher, and furthermore flag the voucher record with an expiration date.
If a voucher has been selected, the voucher is generated, at step 318, by the in-store machine 112, for example, printed as a written voucher including an identifying barcode or PIN representing unique identification data, using a printer in the store 103, for example included on the shopping receipt. If a charitable donation has been made, a receipt of the donation is generated, at step 318, for the customer. Similarly, if value has been added to a rechargeable value card a receipt is generated, at step 318. If only a portion of the total change owed has been foregone in exchange for the offer (e.g. only silver coins), the in-store machine 112 generates, at step 318, a value of remaining change due to the customer for distribution.
The system 100 performs the steps 400 shown in
The customer presents the voucher as part of a point of sale transaction or sale in the store 103. During the transaction, the in-store machine 112 receives, at step 402, sale information including information on the goods and services being sold and their corresponding values. The in-store machine 112 then receives, at step 404, voucher data regarding the voucher presented by the customer. The sale information, and the voucher data, are generated, for example using hardware in the store system 102, including a scanner 118 which optically reads a barcode on the voucher, which provides voucher data, which may be linked to a unique offer record in the offer database (either in the administration database 108, or copied to the in-store machine 112) to provide details of the voucher being redeemed. The in-store machine 112 may therefore transmit, at step 406, the voucher details to the administration server 106 which then generates, at step 407, voucher validity data, including whether or not the voucher has expired, and transmits this back to the in-store machine 112 which receives it in step 408.
Information regarding the status of the offer linked to the voucher is displayed, at step 410, to the seller and/or customer (via the seller interface 114 and/or the customer interface 116) to inform the parties of the offer description. For example, this may indicate that the offer has expired, or that certain products must be purchased in conjunction with the offer.
Whether the voucher is redeemable is determined, at step 412, either automatically by the in-store machine 112 by comparison of the sales data and the voucher offer data (e.g. that the voucher is for a product already included in the basket of goods to be purchased); or through interaction by the seller (e.g. checking that the correct brand of drink has been purchased as specified in the offer). The offer Redemption Conditions also may include type; location; cluster of stores; day of week; and time of day. If the offer is redeemable, then the voucher is considered redeemed and the voucher redemption details are transmitted, at step 414, to the administration server 106 to indicate that the voucher has in fact been redeemed and to update the relevant offer record in the offer database. The in-store machine 112 also generates, at step 416, sales completion data to allow completion of the sale in accordance with the redeemed vouched. For example, this may include reducing the sub-total of the sale in accordance with the value of the voucher corresponding to one or more of the goods in the basket of goods. Financial postings regarding the offer redemption are also generated, at step 418. That is, the redeeming store (which has produced the product) needs to be re-imbursed for the cost of the product less any granter rebates. Any remaining proceeds are shared between the two stores involved. The in-store machine 112 then generates, at step 420, data to allow the seller and buyer to process the sale (e.g. confirmation of the sale is displayed on one of the interfaces). At the end of the voucher redemption process 400, the sale is completed in the store 102. If the sale includes a cash transaction that generates change, the in-store machine 112 will then perform the cash change of a generation process, as shown in
If the offer is not redeemable, then the voucher is considered void. The in-store machine 112 also generates, at step 422, sales completion data to allow completion of the sale. The in-store machine 112 then generates, at step 420, data to allow the seller and buyer to process the sale (e.g. confirmation of the sale is displayed on one of the interfaces). At the end of the voucher redemption process 400, the sale is completed in the store 102. If the sale includes a cash transaction that generates change, the in-store machine 112 will then perform the cash change of a generation process, as shown in
The administration server 106 periodically performs the voucher expiration process 500 shown in
Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.
Number | Date | Country | Kind |
---|---|---|---|
2007906789 | Dec 2007 | AU | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/AU08/01774 | 12/1/2008 | WO | 00 | 9/13/2010 |