Contents
| Table of Contents | ||||
|---|---|---|---|---|
|
Overview
System wide Typically, offers are one of these two types:
Systemwide offers are
Location
In the app, systemwide offers are located at /rewards/offers. Note that routing to /offers will redirect here when systemwide offers is enabled.
The configuration for systemwide offers are located in sanity under Order-Level Content > Loyalty > Incentives > Offers >Systemwide Offers.
How to Create a System Wide Offer
Most sanity fields within system wide offers are the same or similar to the fields in CBA offers. This guide will highlight anything new in system wide offers in blue.
Step 1: Navigate to Order-Level Content > Loyalty > Incentives > Offers > Systemwide Offers
Step 2: offers that are available to all guests, although these can be restricted to guests who have an account and are signed in;
Personalized (or Config) offers are configured as “config” and assigned to specific guests, and therefore used to implement personalization. These offers are only available for signed in guests.
There are other types of offers (covered in /wiki/spaces/HELP/pages/4902027448), but they are less common. This guide explains how to create systemwide and config offers, and you can refer to the reference guide above for details about other types of offers.
| Info |
|---|
Before creating the offer in Sanity it is important you connect with your POS (Point of Sale) vendor to create, price and make the offer available with a PLU (Price Look-Up). Save this PLU and be ready to configure it in Sanity when creating the offer. |
Always create an offer in the Staging environment in Sanity first (https://staging.menu.{brand}.{country}.rbi.tools/desk/). This will allow you to make changes and test the offer with no impact to the live guest app. To test that offers are working as expected, you can use the guest app Staging environment (https://staging-{brand}-web.{country}.rbi.tools/). Offers published in the Sanity Staging environment are only visible in the guest app Staging environment.
After testing, you can migrate the offer to higher environments (QA and Production). When you migrate offers to the Production environment, these will become available to guests.
| Info |
|---|
Sanity Migrations allow you to independently migrate content from Staging to different environments. You can therefore implement offer changes in Staging environment, test them, and afterwards push those changes to QA and Production. All this is accomplished with some clicks in the User Interface of Sanity. |
Configuration steps
Step 1: Create an Offer document
Navigate to Order-Level Content > Loyalty & Offers > Incentives > Offers > Systemwide Offers
| Info |
|---|
To create a Config Offer, click on the |
Click on the pencil icon to create a new
offer
| Info |
|---|
For Config offers this step will look like this: |
Step
32: Content Section
We’ve broken up content fields and offer mechanic fields to make it easier to create and update systemwide offers. The key distinction between the two is that ‘mechanics’ fields have a direct impact on the functionality of the offer, where content and ‘content’ fields only are purely visual and only impact the UI of an offer in the guest app / website.
Loyalty Engine ID
This is populated automatically. No update needed here.
Name
| Status | |||
|---|---|---|---|
|
|
| Note |
|---|
It is a requirement for all translations to be filled in for the name field |
This is the name of the offer that will be displayed . This field and all its translations are required to be filled out.
5% Off Your Order
in the guest app / website.
In the below example it refers to “LARGE CHICKEN/VEGAN ROYALE MEAL - APP902”.
Internal Name
| Status | ||||
|---|---|---|---|---|
|
The name that will be displayed in Sanity - it will help you quickly to identify, search, and organize your offers.
Description
| Status | |||
|---|---|---|---|
|
|
| Note |
|---|
It is a requirement for all translations to be filled in for the description field |
This is the description of the offer that will be displayed in the guest app / website.
In the below example it refers to “£5.99 large Chicken Royale® meal (945 Kcal) or Vegan Royale meal (946 Kcal). This field and all its translations are required to be filled out.
Take 5% off
Localized Use app code APP902 if using a kiosk.”
More Info
This is the offer's disclaimer that will be displayed in the guest app / website. If you add links to this text, you MUST set them to open in a new tab.
Step 3: Image
Image
| Status | |||
|---|---|---|---|
|
|
This is the image that appears on the left of the card in the offer list view. It is also the primary image when the user guest is on the specific offer link. This field and all its translations are required to be filled out.
From the previous example:
UI Pattern
UI pattern determines what UI form the offer appears to the user.
NOTE: Until Quests & Promo Codes are built into Loyalty Offers, only select ‘Standard offer’
Short Code
This is the 4 digit code that identifies the digital offer in PMIX. For loyalty enabled restaurants, in restaurant redemption occurs by adding the offer to the users' in restaurant basket and generating a unique 6 digit loyalty basket code. For non-loyalty enabled restaurants, this short code is also what an user would show a team member in restaurant to redeem an offer.
Step 4: Mechanics Section
We’ve broken up content fields and offer mechanic fields to make it easier to create and update systemwide offers. The key distinction between the two is that ‘mechanics’ fields have a direct impact on the functionality of the offer, where content fields are purely visual.
Rules:| Tip |
|---|
Best Practices Tip: Remember choosing a picture without a background will look better, remove noise, and turn the guest’s focus to the actual purchase 🍔 🍟 |
From the above example:
Image Description
| Status | ||||
|---|---|---|---|---|
|
This will be the text for the alt attribute on the image. Image description is required due to accessibility legal requirements.
| Expand | ||
|---|---|---|
| ||
The alt attribute is the HTML attribute used in HTML and XHTML documents to specify alternative text (alt text) that is to be rendered when the element to which it is applied cannot be rendered. It is also important for SEO purposes, as this description is what allows search engines (like Google) to connect this image to a search. By adding the Plant-based Whopper description, there is a chance guests will find this image in Google Images, which can lead to traffic in the platform |
Background
This is where you can input a background to your image if applicable. This field is optional.
Step 4: Rules
Rules
This is the section where you can define what the rule configurations should be for a user guest to be able to view and use redeem the offer.
For a more detailed breakdown of each rule refer to: Rulesets for Offers, Rewards and Promotions /wiki/spaces/HELP/pages/4862509059
Show this offer as Upcoming
This toggle makes the offer become an Upcoming Offer. To read more about this feature refer here: /wiki/spaces/HELP/pages/4933091370
Redemption Methods
| Status | ||||
|---|---|---|---|---|
|
The different ways the offer can be redeemed in the platform:
Restaurant Only: Offer can only be redeemable in Restaurant at Kiosk or POS
Mobile Only: Offer can only be redeemable in online ordering in the guest app / website
Mobile and Restaurant: Offer can be redeemable in both online and in-restaurant orders
Test Only
If this toggle is turned on the offer will only be available in lower environments (Dev, Staging and QA). Even if the offer is accidentally pushed to Production, it will not show up for guests in the app/website.
Step 4: Benefits
Benefit
| Status | |||
|---|---|---|---|
|
|
This is where you define the benefit the user guest receives if they are able to redeem the offer. Incentives There can only be one benefit per offer.
The benefit linked to the offer can be an item, combo, picker, or discount from the menu or not. The toggle isOfferBenefit no longer needs to be enabled when creating a new offer.This field needs to be filled out for the offer to be Published
If the offer is a discount offer (e.g. 50% off the total cart price), link an offer discount here.
| Note |
|---|
Offer activation and |
Position
This section is no longer relevant for systemwide offers. You do not need to make any changes here.
Daypart
Add the dayparts that the offer should be eligible for here. This field can accomodate more than one daypart. Ensure the spelling matches the daypart in MDM.
If this field is left empty, the offer will be available in all dayparts
and |
Does this offer have an Upsell Option?
In this section FZ can configure upsell offers. Any offer added here will be prompted as an upsell when the user clicks Add to Mobile order or Redeem In Restaurant buttons in an offer.
| Note |
|---|
If an offer is added as an Upsell offer, it will not show in the offer list in the guest app. To add an offer to the offer list in the guest app, please add it to the Live Offers list in Sanity: Live Offers |
How it looks in the Appguest app:
| Info |
|---|
All strings shown below |
can be translated. |
Guest clicks on
Offeroffer
User Guest clicks “use in restaurant” button
Guest chooses to
Upsell Offerupsell the offer
Step 5:
AddPLUs Mapping
Static Code
Here you can input the static code of the offer for in-restaurant redemptions. This code will never change.
For markets that have an in-restaurant loyalty integration, redemption occurs by adding the offer to the guests' in restaurant basket and that generates a unique 6 digit loyalty code.
For markets without an in-restaurant loyalty integration or when guests are signed out, this static short code is what a guest sees in the guest app and shows a team member in the restaurant to redeem the offer. Given this is a static code, we also show a timer to let guests know how long they can have this offer open before it is considered redeemed.
In Sanity:
In the guest app, the static code will only be available for 15 minutes:
Then static short code shows to guest:
Vendor Configs
| Status | |||
|---|---|---|---|
|
|
| Info |
|---|
In this section, input the PLU (Price Look-Up) that your POS vendor provided and you saved in the beginning on this process. |
A unique PLU for the offer. The PLU Type needs to be set to Constantplu and numbered value of the PLU needs to be inputted below Constant PLU.
| Note |
|---|
It is important to ensure that a value is configured for each POS vendor even if it’s just marking it as “empty” or “ignore”. |
NCR Offer Price
| Note |
|---|
This field |
Step 6: Set Test Only Toggle
This test only toggle is a safeguard against an offer appearing in production with incomplete config. You should enable this toggle if you are only using the offer for testing or if the config is not ready for production.
Step 7: Define Redemption Type
| Status | ||||
|---|---|---|---|---|
|
Define what kind of offer this should be. Regular offers contained in the /rewards/offers page should be standard offers. Surprise and Delight offers should be surprise. Swap offers should be swap. Refer to the terms document for more details on surprise & delight and swap offers.
Step 8is only relevant for markets that have NCR as POS vendor. |
This is a static price that will be the same no matter what, ie: $1 coke
Value is in cents, ie: $1 == 100
Step 6: Publish
Publish your offer when complete. After publishing, you should see this the Loyalty Engine ID field populate because the loyalty engine has assigned your swoffer an ID
Step 9: Position.
Step 7: Set the position of offer
Systemwide offers
Navigate to Order-Level Content > Loyalty & Offers > Loyalty Live Offers UI Configuration > Live Offers > Sorted Systemwide Offers and add your offer. Drag Then, drag it to the position you want it to show in the offer’s list and publish.
click on “Publish”. For more information on Live Offers section refer to: /wiki/spaces/HELP/pages/4933091360
Once published, you will see the sytemwide systemwide offer populate on the Offers List page (base urlnavigate to offer’s list: /rewards/offers) in the guest app.
Config offers
Operators can control the order that personalized (config) offers will show in the guest app in the same location under Order-Level Content > Loyalty > Live Offers Configuration > Live Offers > Live Config Offers.
When a personalized (or config) offer is assigned to a guest, they show on the top of the guest’s offer list. If multiple config offers are assigned to a guest, they will still show on top of all other systemwide offers (national offers), but they will follow the order set in Sanity in the Live Config Offers section.
Step 8: Test the Offer
Go to the Staging environment in the guest app (https://staging-{brand}-web.{country}.rbi.tools/rewards/offers) and test:
Redeeming the offer(s) online. Check for content, pricing and success of order. Read here for more information on the online ordering flow: /wiki/spaces/HELP/pages/4861722909
Redeeming the offer(s) in restaurant. To test ordering the offer in-restaurant, connect with your POS and Kiosk vendor(s) to setup a lab environment for you to test. Read here for more information on the in restaurant ordering flow: /wiki/spaces/HELP/pages/4921393188
| Info |
|---|
Note: The URL for the systemwide offer will be constructed using the Loyalty Engine ID Example URL: |
|
| Info |
|---|
Note: The URL used to directly access the personalized offer is built using the unique personalized offer ID. This means that for every guest, the path to get to the personalized offer using the URL will be different. Example URL: |
Step 9: Migrate to Production
After thoroughly testing your offer is working in Staging environment, follow this guide to migrate the offer from Staging environment to QA and Production environments: /wiki/spaces/HELP/pages/4956422399.
Further reading
This document is meant to explain how to configure an offer, but does not detail all the different options that can be used for offers. Please refer to the /wiki/spaces/HELP/pages/4862476291.