Versions Compared

Old Version 34

changes.mady.by.user Silva, Carlos

Saved on

compared with

New Version 35

changes.mady.by.user Silva, Carlos

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contents

Table of Contents

...

  • There are no gaps with cancellations and refunds initiated by the POS, since they will use both the RBI and SessionM API’s

  • For cancellations and refunds currently handled in SessionM, during the transition period support staff will continue to use SessionM and, in addition, will repeat the operation on the RBI Support Tool

  • This will guarantee that cancellations and refunds result in the same loyalty points balance in both RBI and SessionM

Phase 0 (pre & cleanup)

...

  • and

...

  • SessionM

Phase 0 - Test RBI Earning

Change of plans in PhaseMarch: loyalty data will not be kept synchronized as guests will continue to burn on Session M, but in RBI we will only record earning transactions.

The purpose of this phase is to test that the RBI Loyalty API is able to handle the load by processing earn transactions.

Plan

  • 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 1 starts

    ACTION REQUIRED: review the point above. We need to delete loyalty transactions done up to this point as well

    and load before Phase 0 starts

  • Change of plans in March: loyalty data is no longer required before Phase 0.

  • Guest accounts will be synced between RBI and Homeria

  • The above will be accomplished by extracting data into a CSV files file which will be obtained from Homeria and placed in an RBI S3 bucket, and ingested with a script. CSV files will need to be obtained from Homeria (user data) and SessionM (loyalty data including points balance, tier and loyalty transactions)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)No need for rollback

  • 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.

Scenarios

Mobile order, click & collect

...

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

  • Airtouch app / Homeria should already have the static SessionM ID in the session

  • Guest scans the SessionM ID on the scanner and authenticates (this returns the email address)

  • Guest/operator completes the order (this retrieves the basket price calculation)

  • WinRest creates a loyalty transaction in SessionM

  • WinRest creates a loyalty transaction in RBI

    • Call Identify by sending the email address

    • Call Transaction Update (CLAIMED) with an empty basket

Changes needed

RBI

  • S3 data load script to be modified to capture loyalty data from SessionM also (which will result in creating a loyalty ID for each user)for each user). No longer necessary after the March changes in plan.

  • Data extract from RBI (currently only RBI Cognito ID's) to include RBI Loyalty ID

  • New Identify endpoint that accepts an email address

SessionM

  • Extract of loyalty data (loyalty points balance, tier and loyalty transactions). No longer necessary after the March changes in plan.

Homeria

  • Extract of user data (SessionM ID required to link with the above). No longer necessary after the March changes in plan.

Airtouch

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

Tillster

  • Call RBI Loyalty API (Identify and Transaction Update)

WinRest

  • Call RBI Loyalty API (Identify and Transaction Update)

Phase 1

...

- Test RBI OTP

Plan

  • All client apps will start using the RBI OTP to identify guests

  • Loyalty transactions will be done primarily on SessionM and after

  • All client apps will use primarily RBI Loyalty, and SessionM as a backup in case a rollback is needed. Both RBI and SessionM should have the same loyalty transactions and points balance to start with

  • This requires Airtouch, Homeria (because of the website and app/delivery), Tillster and WinRest to modify their software to introduce RBI Loyalty in addition to SessionM

  • Airtouch app will use RBI loyalty codes for in-store identification, instead of SessionM codes

  • Guests will continue to earn but not burn

  • No rewards will be shown (reward configuration in Sanity will be done on phase 2)

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

  • New users created on the app or website will be synchronized from Homeria to RBI using an existing endpoint (same that we used for BK PT)

  • The endpoint above will be modified to respond with the RBI Loyalty ID, which will then be stored in Homeria to be used when calling the RBI Loyalty API. The RBI Loyalty ID will then be made available to the Airtouch app

...