Modules:LoyaltyManagement/User Documentation

Introduction

This article explains how to use Loyalty Management functionality in Openbravo. It is not intended to be a module to work standalone but with customizations on top of it. It should be seen as the base piece for Loyalty programs where there is an integration with a third party or Loyalty vendor. Each integration is different, therefore, there will be customizations on top of this module, but this project offers a common structure to be used if desired in each implementation.

The main functional flows are customer balance request, points accumulation and point redemption. The idea is that the interaction with the loyalty program is in Web POS, and the configuration and visualization of the results from the Backoffice.

So at high level, first customers can check their loyalty balance from Web POS, by accessing a web service that will be different in each program, thus customizations will be required here.

Second, he or she will be able to earn loyalty rewards in each sale transaction (here it is possible to reuse all standard functionality as Openbravo replicated the accumulation rules so they can be configured and used from Web POS, but it the part of sending the accumulated points by each customer to the third party system will be custom.

And Third, customers will be able to pay tickets using their available awards, by using a new payment method that will be from the Loyalty Program. Again here, Openbravo provides the structure of the new payment method and the conversion from the store currency to the loyalty currency, but the access to the third party system for redeeming these points from customer's account will be a customizations as it will be an online webservice, different in each program.

Customer Identification

Customer identification is common to all three functional flows (balance request, accumulations and redemption). This can be by for example reading the magnetic band of a loyalty card, and extracting automatically the customer data (as seen in the screenshot below).

Each loyalty card has different formats, so data extraction would be a customization in each program. However, Openbravo allows to introduce manually the card number or customer account if there are no loyalty cards or card readers.

There is a preference related to this to enable this. More info on how to configure it here [1].

Customer Balance Request

There is a new menu entrance in Web POS that is Points Balance Request (to enable this there is a preference, more info here [2]).

Openbravo is providing a basic API and structure so each Loyalty Program can use it and adapt it to each program. In this section we will distinguish what is common to all program and what is a customization. Customer Balance will be used when customer wants to know his or her balance:

Then it is asked to slide the card so the customer can be identified. Alternatively, the card number can be introduced manually, instead of sliding the card. Once this is done, the corresponding format needs to be extracted (remember this will be a customization in each Program).

After that, there is a call to the web service (custom as well) that will get the balance in the third party system. This is only possible in online mode, otherwise a message will be appear:

In a normal situation, there would be connection and the request would be done, so the pop-up will show a message while waiting for the response: "Connecting to the server. Please wait...". In the screen only the three last digits of the customer's account will be shown for security reasons. Remember that the web service request and get the answer should be customized to each Loyalty Program. If the connection is lost at this moment, the following message will be shown:

A time-out can be programmed so the connection is closed after certain seconds of no response from the server. To visualize the results there are two options, if there is a template defined for customer balance (as explained here [3]) a ticket will be printed with the balance.

Alternatively, the customer's balance could be shown in the screen.

Points Accumulation

Customers can earn points after each purchase. Loyalty program in Openbravo replicates the rules of the vendor's program to accumulate points, so they can be earned after each sale in Web POS.

First of all, rules for accumulation need to be configured in the backoffice as explained here [4].

Then, from Web POS, there are two ways to accumulate points, by accessing manually the menu entrance of "Points accumulation" or by pressing the total, after products have been added to the ticket and before turning to payments window. This second option is more intrusive in the process, and may make sense when this step needs to be mandatory in each sale transaction. The two options have preferences [5].

Once products have been added to the ticket, either by clicking the accumulation menu entrance or the ticket total, the pop-up for customers identification will appear, asking to slide the card (or introduce the customer's card number manually):

After that, it will turn to the payments window, to add the corresponding payment methods to the ticket and close it. Before closing it the system will calculate the points earned according to the products added to the ticket and rules defined. It will save this information in a new table and also print it in the ticket that is tendered to the customer.

Accumulation Example

Let's see how the accumulation works based on the different rules defined in the backoffice. Let's say we have the following rules defined and only activity 10 is defined as "Generic Rewards":

Then in Web POS select the following products: Avalanche Transceiver 1 quantity, Ice Screw Bag 1 quantities and Alpine Poles 1 quantity:

Press total, slide the customer's card where the points will be accumulated and add the payments to the ticket in order to close it. Then the receipt ticket will be printed, where it can show the total points accumulated and the detail separating by generic points (of activity 10) and Promotional points for each of the two products. This is just an example of how it could look like, but each implementation will need to customize the template:

Here there is the explanation on how the points calculation is done:

• Product "Avalanche Transceiver" Qty 1:
  • Activity 10 (Only Generic Rule applies): 150.50 * 0.1 = 15.50
• Product "Ice Screw Bag" Qty 2:
  • Activity 10: 9.90 * 0.1 * 2 = 1.98
  • Activity 20: 9.90 * 0.5 * 2 = 9.9
  • Activity 30: 9.90 * 0.2 * 2 = 3.96
• Product "Alpines Poles" Qty 1:
  • Activity 10: 36.50 * 0.1 = 3.65
  • Activity 20: 36.50 * 0.4 = 14.6

As it is shown in the ticket, this is how to calculate the total differentiating by Generic Rule or not (note that the rounding "Half Up" is done after summing up all amounts by activity. To change the rounding type look here [[6]], the field "Accumulation Rounding Type"):

• Regular Points (sum of activity 10, as it was marked as "Generic Rewards"):
  • Activity 10: Round (15.50 + 1.98 + 3.65) = Round (21.13) = 21
• Extra Points (sum of activities 20 and 30):
  • Activity 20: Round (9.9 + 14.6) = Round (24.5) = 25
  • Activity 30: Round (3.96) = 4
  • Total Extra points = 25 + 4 = 29
• Total Points earned = 21 + 29 = 50

Additionally, the points accumulated can be seen from the backoffice Sales Order window, tab Accumulated points. There you can see the detail of points earned by line:

Or by ticket:

In order to see the points accumulated, a process needs to be run first in order to populate the accumulation table (it can be scheduled to be run after n time). This is the process "Loyalty Process Accumulation", and this needs to be run under Organization *:

The idea behind this process could be generating a daily file for all accumulated points earned in all stores (as they are earned offline) and send them via FTP to the Vendor's platform. Again this part would be a customization.

Points Redemption

In this section points redemption is explained where the user will choose a new payment method (created under the loyalty program) to pay the ticket, whose payment amount is converted to the points according to the conversion rules defined in the backoffice. This process will invoke an online web service to the third party platform to redeem the customer points. This operation will thus need online connectivity with the server.

If the conversion rate was defined as 0.075 (as shown in [7]), and the new payment method for loyalty is called "Miles Club" (as shown in [8] ) then in Web POS, if we have a ticket of 277.80€ and we click on "Miles Club" payment method, automatically the amount to pay will be converted from € to Miles as 277.80 / 0.075 = 3704 ML as shown in the following figure:

Then the customer will decide how much amount to pay with Miles, let's say 250€, after typing that quantity and enter, the following popup will appear showing the equivalent of 250€ in miles that is 3334 ML and the rest to pay that is 27.80€. He or she will be asked to slide the card to be identified and the send the request online to the third party platform:

Once the response is sent back and the customer balance was successfully decreased in the third part platform, a new payment will be added in Web POS showing the quantity paid and also the remaining to pay:

Let's say the remaining amount of 27.80€ is paid in cash, so the ticket is closed and printed. As it is shown in the following picture, the miles paid are shown and the current customer balance too (that will depend whether the web service returns that value or not), but in any case, the development of the web service will be a customization of each loyalty implementation.