CUSTOMER LOYALTY CARDS
TRACKING LOYALTY CARD STOCK
Both the card and the card bundles will be tracked as serial stock in the serial stock location (same as IMEI). We will have two parent items -- one generic card and one generic card bundle. We will also have a dummy item for each. Then the bundles will be receipted into head office just like normal serial stock, each bundle will have to be scanned. These will be set to stock type L for loyalty, they will also need a W because they will be whole number stock only (thus stock type must be WL).
In addition, the generic card bundle stock item will have to reference the generic card stock item in the branch product code field.
For transfer out to stores and receipt into stores, exactly the same things happens so we have the store receipting the generic bundle and then scanning the serial number off the bundle (same as IMEI). Thus the bundles go into serial stock, each individual bundle has a quantity of either 0 or 1 and we can track the location of where the bundle is currently located. The generic bundle parent item will keep the total number of bundles at each location.
The bundles should have a stock code that matches the following:
XXXXXXX-ABC-DEF prefix ranges
For example, a bundle of 100 cards numbered from 100 to 199 would have the code:
9912345-100-199 prefix ranges
We will add a special program (stbunmin) to split a bundle. When they use this menu it will ask for an operator, then it will ask for them to scan the bundle and ask OK to split?. After they go ahead, it will auto-generate a transaction batch that takes the bundle out of stock and puts a whole stack of individual serial numbered cards into stock. This will also update the generic card item to keep track of the number of loose cards in the store. The result will be exactly like the operator did a stock receipt taking 1 generic bundles out of stock and putting 250 generic cards into stock - all the serial numbers will automatically be created. Costing for these bundle splits will be based off the costing of the bundle divided down by the number of cards - thus it ensures that total value on hand for this branch does not change.
Head office will be able to keep track of stock levels by looking at the generic bundle item and the generic card item. Cards and bundles can have a non-zero cost which will correctly track value on hand of cards in stores. In theory, cards could also have a non-zero price if membership fees are introduced at a future stage.
ACTIVATING CLUB CARDS
Cards will be activated by selling them to a customer, they will sell like an IMEI item so the operator will enter the generic card (parent item) and then scan the actual card serial number. As cards go out to customers, they will be included on the sales and will go out of stock. Operators cannot put the card onto the sale unless it exists in stock (like other serial stock items).
EXISTING CUSTOMER RECORDS
We will write a program to scan through the list of current customers and change their customer IDs to all have a prefix of 99 and also try to clean up the phone number fields a bit. This will update index entries, etc. It will not change transactions or other customer history. It will blank the card issue date on all customer records (which are probably all blank now anyhow). This will require an extra field called Auxiliary Customer Code, the existing customer ID (mostly the same as the mobile number but often junk) will be moved into the auxiliary customer code. New customer codes will be sequentially allocated using the "next customer number" (see below) which can be started at 9900000000 to achieve the 99 prefix. The remaining number will be the next code after this scan is complete.
CREATING NEW ''CLUB CARD'' CUSTOMER RECORDS
When selling a card, it will work the same as the mobile phone - enter the generic card item, then scan the serial number of the card. This is what the stores already do. The system will check the customer record to see if they have already been assigned a card. It will do this by checking the card issue date in the customer file maintenance. If the card issue date is blank then they will be allowed to get a card, otherwise an error will be generated when the card gets scanned (selling a second card to the same customer is thus not possible). Selling a card to the customer takes it out of stock, sets the card issue date to today's date and also changes the customer ID to match the card. If the current customer is a cash sale then it will prompt the operator to create a new customer before completing that sale.
CREATING NEW ORDINARY CUSTOMER RECORDS
To create an ordinary customer, we will prevent the store from entering their own customer code (there is an option for this, sales option can add new customer code during sale (Y/N) which will be set to N). The operator creates a new customer by pressing ENTER at the customer code then pressing F5 at the customer name. In the config for accounts receivable other options there is a next customer code which the system will use when customers are created in this manner. These customers will get a 99 prefix if the sequence is set to a suitable value. They will remain "ordinary" customers until they get a club card.
UPGRADING EXISTING CUSTOMER RECORDS
The procedure for an existing customer will be to take their old loyalty card back, do a sale, at the start of the sale find the existing customer record (by phone number or name) so the sale goes to the right customer, then "sell" them the loyalty card. This triggers a check to see if this customer is already a loyalty-card record and won't allow a second card to be sold to the same customer. If the customer is OK to get a card then the customer code gets modified to match the loyalty card serial code and the card gets taken out of stock so it can't be sold to anyone else.
When revisiting a customer at time of retail sale, there will be an option to allow the operator to edit the customer details as per creation of normal retail customer. The operator cannot modify the customer code at this point but can change address, phone, and other things that might be expected to change from time to time.
There will also be a flag that says whether the customer details should be printed at the end of that sale (e.g. Print Details Y/N) and this will cause a docket to be printed with the customer details (including NEW customer number which is card number) at the end of the sale. This printed docket will be put together with the old loyalty card and sent to head office. At head office they can find the customer by the code, check over the details, add on any bonus point stamps (stamps are sold as stock items but only available in head-office locations). Note that if the employee has Allow output to file option set to N, they will not be able to print here either.
SELLING TO CUSTOMERS IN LOYALTY SCHEME
Once a customer is in the loyalty scheme, their ID will match the card so after the operator enters their operator code, they scan the customer card and the sale will go against that particular customer. Discounts for card holders can automatically be handled by setting the customer pricing level or category pricing group for those customers.
REPORTING
Cards will go onto the mobile phone report as IMEI items but they will be easily distinguishable from phones because they will be in a separate category and they will not have a phone number, etc. The serial numbers of the cards that have been used will show up in the IMEI column along with the date that they were used.
Quantity on hand reports will show correct quantities for the generic (not serial number) cards and bundles so it will be easy to see which stores need more bundles sent out to them.
Supplier for the bundles and the cards should be set to one of the head office locations with suitable email address set to whoever will check the stock levels because some stores might try to do a suggested purchase order on the bundles - this way those orders will be separate from real purchase orders.
ENQUIRY
It will be possible to use the card number in stock enquiry to find the card serial stock. Individual cards can be tracked by serial number - the transaction history will show when the card was split from a bundle (will look like a stock receipt) and when the card was assigned to a customer (will look like a sale). It will be possible to see the customer ID who got the card (which should be the card serial number). Card numbers can also be used in customer enquiry to bring up the customer and look at their sales, payments, etc.
STOCKTAKE
Branches will stocktake bundles as bundles (easy) and for bundles that have been split, they will have to scan the numbers on ALL the remaining cards in the stack (from 1 to 99 cards) which is a tedious job that probably will rarely get done. These stocktakes will show up lost cards, etc.
LIMITATIONS
Card serial numbers must be different from IMEI serial numbers. Since they are different length we should be pretty safe. The bundles of cards will look like: 99xxxxxx00-x99 for standard 250 card bundles (possibly other codes with similar format for half-bundles) these are 14 digit codes with a "-". The IMEI numbers are something like: 352814000464576 which are 15 digit codes and no "-" so we are not expecting a conflict between cards and phones in the stock.
Over time a large number of stock file entries will be used up by the cards. These will probably sit on the system forever.
Employees should NEVER split a bundle without using the Special Bundle menu, especially if they are silly enough to throw away the wrapper and lose the serial number from their bundle. If they try this they will not be able to sell any of the cards out of the bundle.
DUPLICATE DETECTION
We propose to add "mobile phone" and "auxiliary code" to the duplicate detection report. These fields will work the same as other fields on the same report (i.e. match the selected fields between records to search for duplicates).
AUTOMATIC MOBILE PHONE NUMBER DETECTION
Since most stores search for customer by mobile phone number at sale time by entering the mobile number into the customer code, we propose to make the software intelligent enough to recognise a 10 digit number starting with 04 and move this into the mobile phone field when the user decides to create a new record.
If the control option "can add new customer code during sale?" is set to 'N' then the system will never allow the user to choose their own customer code when creating a new customer at sale time. Usually they would be forced to blank the code, step to the next field and press F5 -- the auto detection of a mobile number will make it pretend that they are still using the old system and say "Not on file do you wish to add?" but when they do add, the mobile number will not become the code.
If they use something that is not recognised as a mobile number then they attempt to add, it will just say "Not on file" and they can only add by using the F5 option (which requires them to blank the code).