Versions Compared

Old Version 2

changes.mady.by.user En Ouyang

Saved on

compared with

New Version Current

changes.mady.by.user Silva, Carlos

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel6
outlinefalse
typelist
printablefalse

...

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.

...

  • RBI will provide an endpoint and keys to create a user in the RBI Platform.

    • This endpoint will also ensure the associated user gets created in the RBI Loyalty Platform, with its appropriate linkage to the RBI User.

    • Homeria must store and associate the returned RBI User ID and RBI Loyalty ID with their Homeria User.

  • Homeria will make sure that any user created in the current system will be also created in the RBI Platform via the provided endpoint.

Lucidchart
pageCount45
autoUpdatefalsetrue
alignleft
typerich
autoSize1
macroId1af6873699365006-83d38b9a-4fd54740-8892bcf2-e924d3382cd0f45d35c397d0
instanceId920ae5b1-83d6-3e36-b794-1710780f64f3
pages1
width700
documentTokenv2_36780044c64e30f0813c4367457fe8ee73b3898af2b733e912c3e19c4e3bcbe09f1ba0f9615adb98998dda1deeaac75e1f00c01c698b5afc1de0d2680af2cee6-a=133831322&c=920ae5b1-83d6-3e36-b794-1710780f64f3&d=d7a4e6b03f78436c-3bf8b5c3-486144ff-bd9d840e-47059000a698&p=4429447543
documentIdd7a4e6b0-3bf8-4861-bd9d-47059000a698
updated1704904205077
height500
Lucidchart
pageCount5
autoUpdatetrue
typerich
alignleft
autoSize1
macroId99365006-8b9a-4740-bcf2-f45d35c397d0
pages1
instanceId920ae5b1-83d6-3e36-b794-1710780f64f3
width700
documentId3f78436c-b5c3-44ff-840e-c468e134dd0a
documentTokenv2_9f1ba0f9615adb98998dda1deeaac75e1f00c01c698b5afc1de0d2680af2cee6-a=133831322&c=920ae5b1-83d6-3e36-b794-1710780f64f3&d=c468e134dd0a&p=4460904486
documentId3f78436c-b5c3-44ff-840e-c468e134dd0a&p=4460904486
updated1706259482233
height500

...

  • Homeria will provide a CSV with all the user data from their system and all the user loyalty data from SessionM (eg. SessionM ID, Homeria User ID, points, balance, tier, and transactions).

  • RBI will host these files in a private S3 bucket and create the necessary database records via a script run in a provisioned EC2 instance with the appropriate role.

    • RBI will not create duplicated users for those already created by the synchronization process.

    • RBI will update the Loyalty Points balance, tiers, and other Loyalty data for the users already created.

    • (Optional) I suggest Homeria disables Loyalty Earning, Burning, and Tier and Points expiration while this process takes place.

      • Check Phase 1 - Option A & B.

        Status
        colourYellow
        titleIssue

  • RBI will provide a CSV back with the correlation between the Homeria User, RBI User ID, and the RBI Loyalty ID to be imported by Homeria.

Lucidchart
pageCount

...

5
autoUpdate

...

true
alignleft
typerich
autoSize1
macroId

...

207053ae-

...

9b01-

...

4fb2-

...

b3bb-

...

970a10228010
instanceId920ae5b1-83d6-3e36-b794-1710780f64f3
pages2
width700
documentTokenv2_

...

9f1ba0f9615adb98998dda1deeaac75e1f00c01c698b5afc1de0d2680af2cee6-a=133831322&c=920ae5b1-83d6-3e36-b794-1710780f64f3&d=

...

3f78436c-

...

b5c3-

...

44ff-

...

840e-

...

c468e134dd0a&p=

...

4460904486
documentId

...

3f78436c-

...

b5c3-

...

44ff-

...

840e-

...

c468e134dd0a
updated

...

1706259637562
height500

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
    colourYellow
    titleIssue

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

    Status
    colourYellow
    titleIssue

  • 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

RBI

  • User Creation Endpoint:

    • Will develop or adjust the user creation endpoint.

      • This should happen at the User Service Domain.

    • Will create, test, document and share the API Keys and documentation for the previously mentioned endpoint.

  • User Import process:

    • Create the S3 Bucket.

    • Securely receive and store the Homeria and/or SessionM CSV in the S3 Bucket.

    • Develop and/or test the import script for the transition.

    • Provision or request the necessary EC2 instance with the correct IAM Permissions to run the import script.

  • User export process:

    • Develop and/or test an import script for exporting all (necessary) User and Loyalty data from BK ES.

    • Provision or request the necessary EC2 instance with the correct IAM Permissions to run the export script.

    • Share the generated CSV securely back to Homeria.

SessionM

  • Provide CSV with SessionM Loyalty User data.

Homeria

  • Provide CSV with Homeria User data.

  • Import CSV provided by RBI and associate Homeria Users with the respective RBI and RBI Loyalty Users.

Airtouch

  • Remove screens that will not be used (discussed separately).

Tillster

  • No changes required.

WinRest

  • No changes required.

...

⚠️ 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.

...

Info

From this point on, I’ll ignore this problem and continue assuming this was solved.

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):

Lucidchart
pageCount45
autoUpdatetrue
alignleft
typerich
autoSize1
macroIddd3046a96fa09e8c-66cdf622-46ce4578-9c6093b3-a7f4e5c10c2a83adc15b552d
instanceId920ae5b1-83d6-3e36-b794-1710780f64f3
pages3
width700
documentTokenv2_c3e557dbca22342918f987f0c86fb03a514a18dce2d91e29ece0de0fd320f7289f1ba0f9615adb98998dda1deeaac75e1f00c01c698b5afc1de0d2680af2cee6-a=133831322&c=920ae5b1-83d6-3e36-b794-1710780f64f3&d=d7a4e6b03f78436c-3bf8b5c3-486144ff-bd9d840e-47059000a698c468e134dd0a&p=44526469134460904486
documentIdd7a4e6b03f78436c-3bf8b5c3-486144ff-bd9d840e-47059000a698c468e134dd0a
updated17059148492861706259717415
height500

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

Lucidchart
pageCount45
autoUpdatetrue
alignleft
typerich
autoSize1
macroIde360c7199179a2c5-cf04724c-4bbb4d97-b87eb4f1-e151639478e33dab27cf2957
instanceId920ae5b1-83d6-3e36-b794-1710780f64f3
pages4
width700
documentTokenv2_c3e557dbca22342918f987f0c86fb03a514a18dce2d91e29ece0de0fd320f7289f1ba0f9615adb98998dda1deeaac75e1f00c01c698b5afc1de0d2680af2cee6-a=133831322&c=920ae5b1-83d6-3e36-b794-1710780f64f3&d=d7a4e6b03f78436c-3bf8b5c3-486144ff-bd9d840e-47059000a698c468e134dd0a&p=44526469134460904486
documentIdd7a4e6b03f78436c-3bf8b5c3-486144ff-bd9d840e-47059000a698c468e134dd0a
updated17059148728721706259778615
height500

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

  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

  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

  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
      colourRed
      titleunnecessary

    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
      colourRed
      titleunnecessary

    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

RBI

SessionM

Homeria

Airtouch

Tillster

WinRest

...