Page Comparison

...

• Expected to run for weeks

• Guests will earn but not burn. Change of plans in March: guests will continue to burn, because RBIberia does not want to risk a drop in sales by preventing burn.

• All clients apps (Airtouch, Homeria, Winrest, Tillster) will continue to record loyalty transactions on Session M (no integration to RBI loyalty yet).

• Change of plans in March: all client apps will also send earn transactions to RBI (burn transactions will not be sent). The purpose is to test the RBI system’s performance and ensure that we record loyalty transactions accurately.

• During this phase, we will compare transactions between RBI and SessionM (although the loyalty points balance is not expected to match).

• Guest and loyalty data (including email addresses, loyalty points balance, loyalty tier and loyalty transactions) will be migrated from SessionM to RBI, as a one time data dump and load before Phase 0 starts

• Change of plans in March: loyalty data is no longer required before Phase 0. Loyalty User ID’s should still be included in the user data sync described below that happens before Phase 0.

• Guest accounts will be synced between RBI and Homeria

• The above will be accomplished by extracting data into a CSV file which will be obtained from Homeria and placed in an RBI S3 bucket, and ingested with a script. SessionM data is not required.

• At the end of the data migration above, RBI will provide a list of RBI Cognito ID’s, RBI Loyalty ID’s and email addresses for all users, to be imported by Homeria

• The RBI app is not live (all guests will use the Airtouch app)

• There will be no users created via the RBI apps (only via the Airtouch app or Homeria website)

• When users are created in the Airtouch app or the Homeria website, Homeria will call the RBI Create User endpoint to ensure that users are in sync. This endpoint will also create a Loyalty user in RBI.

• The endpoint above will be modified to respond with the RBI Loyalty ID, which will then be stored in Homeria to be used during Phase 1 to generate RBI OTP’s. The RBI Loyalty ID will then be made available by Homeria to the Airtouch app

...

• All client apps will start using the RBI OTP to identify guests when making in-store purchases. To achieve this, apps show the OTP during in-store orders only, both the Airtouch app and Homeria website need to call the Get Loyalty OTP endpoint (takes the RBI Loyalty User ID as input), which generates a dynamic Loyalty OTP valid for 15 minutes. Create OTP endpoint,. See documentation about this endpoint here: https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BWEB%2FAPP%5D-Create-OTP

• Loyalty transactions will be done primarily on SessionM, and RBI after (earn transactions only).

• SessionM transaction history will not be migrated yet

• Registration and authentication on the Airtouch app or Homeria website will continue to use Homeria

• New users created on the app or website will continue being synchronized from Homeria to RBI using the same endpoint we used in Phase 0.

...

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID

• Airtouch app / Homeria website calls the RBI Get Loyalty Create OTP endpoint

• Guest scans the OTP on the Tillster kiosk

• Tillster calls the RBI Identify endpoint and uses the OTP to authenticate the guest. Identify responds with a Transaction ID, RBI Loyalty User ID and the guest’s email address

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

• Guest completes the order

• Tillster updates SessionM, using the email address retrieved previously

• Tillster updates RBI Loyalty (this should be similar to what happens today on PLK ES):

  • Call Transaction Validate

  • Call Transaction Update (CLAIMED) with an empty basket

...

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID

• Airtouch app / Homeria website calls the RBI Get Loyalty Create OTP endpoint

• Guest scans the OTP on the WinRest QR reader

• WinRest calls the RBI Identify endpoint and uses the OTP to authenticate the guest. Identify responds with a Transaction ID, RBI Loyalty User ID and the guest’s email address

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

• Guest completes the order

• WinRest updates SessionM, using the email address retrieved previously

• WinRest updates RBI Loyalty (this should be similar to what happens today on PLK ES):

  • Call Transaction Validate

  • Call Transaction Update (CLAIMED) with an empty basket

Changes needed

...