Page Comparison

...

Key Concepts

• Partner: Will

• RBI Platform: The RBI M&O platform, app, and website for the brand.

  • RBI User: A user that exists in the RBI Platform.

• Loyalty Platform: The RBI Loyalty platform, runs independently from the RBI Platform.

  • Loyalty User: A user that exists in the Loyalty Platform. This user exists separately from the RBI User.

  • Point Burning: Spending loyalty points (crowns).

  • Point Earning: Earning Loyalty Points (crowns).

  • POS: Point of Sale.

  • OST: Order Selection Transfer is a mechanism in which given an identifier, we can trace it back to an order a user has started on another platform. Eg. the user starts an order on their mobile phone, and then it can be transferred to a Kiosk totem or cashier POS. Some of these are: OTPs, User UUID(RBI Loyalty User Id), User UUID (Base 10), Phone Number, Swipe Card Number (Not in use), PAN Number (Not in use).

  • OTP: One Time Password is one of the many OST identifiers we support. The user is given a temporary (15-minute) 6-digit code that can be traced back to the user’s order.

  • Identify: Process in which we exchange an OST for a new Loyalty transaction. Ideal for FE platforms where we want to allow guests to identify quickly without requesting all their credentials.

...

Phase 0 - User Synchronization

Details

Before the transition can happen RBI needs to have a full list of all the existing users and the relevant data (user and loyalty data) in the Homeria app and SessionM platform for them to be migrated to the RBI Platform and the RBI Loyalty Platform.

...

...

At this point, both RBI and Homeria should have their user databases in sync, with the correct associations between RBI IDs and Homeria User IDs with no downtime, and (if following the correct order) ensuring we don’t have any lost users while the user import process took place.

Assumptions

• This phase will run for weeks.

• User updates are not communicated to RBI. If any user data changes, once the RBI apps are enabled, they will roll back to the point where this migration happened.

  Status
  colour Yellow title Issue

• Point expiration dates will not be migrated, a new date will be determined by RBI.

  Status
  colour Yellow title Issue

• Point burning will be disabled on all platforms (Airtouch, Homeria, Winrest, Tillster).

• All client platforms (Airtouch, Homeria, Winrest, Tillster) will still utilize SessionM as the Loyalty Platform.

• The RBI Platform will not be live yet.

  • No users will be created on the RBI Platform.

  • All users will continue using the AirTouch app or the Homeria website.

• There’s no risk of data loss, so there’s no need for a rollback plan at this phase.

Changes Needed

...

⚠️ In the Phase 1 and Phase 2, if we want to synchonize all the transactions/orders to RBI orders, which are stored in mono table, we need a daily sync for daily transactions/orders happened, we conducted this for PLK ES in the past. If we apply this somehow “offline“ sync, the created RBI orders won’t connected with corresponding RBI Loyalty Transactions (not needed)

Phase 1 - RBI Loyalty Enablement

Requirements

Loyalty points will not be in sync if during Phase 0 Homeria have Loyalty Earning, Burning, and Tiers expiration, and/or if Phase 1 begins at any time that it’s not immediately after the import process is complete. This means that at a later point, we’ll need to synchronize all users' Loyalty Points, Tiers, and any other user Loyalty data once again. The same conditions apply, there has to be some Loyalty downtime while the sync takes place.

...

Details

RBI Loyalty will become the primary Loyalty platform for the brand, but at the same time, all loyalty transactions on Homerias' side will be sent both to the RBI Loyalty Platform and SessionM.

There will be two main scenarios which require different interactions with the RBI Loyalty Platform:

Flow 1 - The FE client knows who the user is (Web / App):

Flow 2 - The FE client doesn’t know who the user is (Kiosks and POSs):

Rollback Plan

Given all transactions are still being reported to SessionM. Homeria and all other existing platforms must have mechanisms in place to switch the source of truth back to SessionM once again.

Scenarios

Mobile Order, Click & Collect

1. The guest opens the Airtouch Mobile App.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Airtouch, as part of the ordering process, starts a process on their BE.

5. Airtouch BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BAPP%5D-Create-RBI-Loyalty-Transaction---Airtouch

6. Airtouch BE creates a new Transaction in SessionM:

   1. How they do this is up to Airtouch, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Mobile Order, Delivery

1. The guest opens the Airtouch Mobile App.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Airtouch, as part of the ordering process, starts a process on Homeria’s BE.

5. Homeria’s BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BAPP%5D-Create-RBI-Loyalty-Transaction---Airtouch

6. Homeria’s BE creates a new Transaction in SessionM:

   1. How they do this is up to Homeria, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Online Order, Website

1. The guest opens the Homeria website.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Homeria, as part of the ordering process, starts a process on their BE.

5. Homeria’s BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BAPP%5D-Create-RBI-Loyalty-Transaction---Airtouch

6. Homeria’s BE creates a new Transaction in SessionM:

   1. How they do this is up to Homeria, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

In-Store Order

PART 1, Homeria & Airtouch

The Guest opens the Airtouch App or Homeria website, then navigates to the page where their Loyalty Identifier is displayed.

...

1. The code has to be automatically refreshed.

2. The FE has to poll the Get OTP endpoint every around 10 seconds to detect if the code has already been used, the status is claimed.

   1. The endpoint details and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BWEB%2FAPP%5D-Get-OTP

3. If the code has already been used, display a modal acknowledging the successful transfer to the guest, and immediately generate a new one.

4. If the code request fails, the FE has to display some sort of feedback to the user prompting them to try to get a new OTP code again.

5. All the edge cases, process feedback to the user, and polling have to be implemented and handled by Airtouch and Homeria.

6. The OTP code will be displayed both in a QR and plain text format.

PART 2, Tillster Kiosk

1. Guest inputs the OST provided by the app:

   1. Scanning the QR Code.

   2. Manually introducing the plain text OTP code.

2. Tillster calls the RBI POST Identify endpoint and uses the OST to identify the guest.

   1. If the guest wants to use offers, they would input their code directly into the kiosk. These offers are not configured in RBI.

   2. posType: Tillster

   3. The endpoint details and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BIn-Store%5D-Identify-RBI-Loyalty-User

3. Tillster calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty User Id. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc).

   1. We need the email address to use later during the creation of the SessionM transaction.

   2. The endpoint details and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#Get-RBI-Loyalty-User

4. The guest places an order.

5. As part of the ordering process, the In-Store flow for Kiosk integrating with RBI is initiated:

   1. The guest finishes their order and proceeds to checkout.

   2. Tillster calls the POST Validate RBI endpoint.

      Status
      colour Red title unnecessary

   3. Tillster calls the PUT UPDATE RBI endpoint.

      1. OPTION A: All the items for the order with each item’s price.

      2. OPTION B: A single mock item with the total price of the order.

   4. The Transaction will have the status of CLAIMED.

   5. The Transaction channel will have the value of restaurant.

   6. Any other information about the order is optional, but it’s recommended to include the most we can for any potential debugging purposes (eg: Payment method, payment amount, etc).

6. Tillster creates a new Transaction in SessionM:

   1. How they do this is up to Tillster, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

PART 2, Winrest POS

1. Guest inputs the OST provided by the app:

   1. Guest scans the OTP on the WinRest QR reader

2. Winrest calls the RBI POST Identify endpoint and uses the OST to identify the guest.

   1. If the guest wants to use Offers, they would ask the cashier to add the offer code to their order. These offers are not configured in RBI.

   2. posType: Winrest

   3. The endpoint details and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BIn-Store%5D-Identify-RBI-Loyalty-User

3. Winrest calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc).

   1. We need the email address to use later during the creation of the SessionM transaction.

   2. The endpoint details and example payload can be found in https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#Get-RBI-Loyalty-User

4. The guest places an order.

5. As part of the ordering process, the In-Store flow for Kiosk integrating with RBI is initiated:

   1. The guest finishes their order and proceeds to checkout.

   2. Winrest calls the POST Validate RBI endpoint.

      Status
      colour Red title unnecessary

   3. Winrest calls the PUT UPDATE RBI endpoint.

      1. OPTION A: All the items for the order with each item’s price.

      2. OPTION B: A single mock item with the total price of the order.

   4. The Transaction will have the status of CLAIMED.

   5. The Transaction channel will have the value of restaurant.

   6. Any other information about the order is optional, but it’s recommended to include the most we can for any potential debugging purposes (eg: Payment method, payment amount, etc).

6. Tillster creates a new Transaction in SessionM:

   1. How they do this is up to Tillster, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Phase 2 - Reward Enabled

Scenarios

Mobile Order and Online Order

The only difference from Phase 1 is that in step 5, the Rewards need to be added in the payload sent to Create RBI Loyalty Transaction endpoint.

In-Store Order

In-Store Order PART 1

The only difference from Phase 1 is that in create OTP in the website/App, the Rewards need to be added in the payload sent to Create OTP endpoint.

In-Store Order PART 2

The only difference from Phase 1 is that in step 5, the Rewards need to be added in the payload sent to Update/Claim RBI POS Loyalty Transaction endpoint.

Changes Needed

...