...
Info |
---|
STS Gen2
|
Agreements
Info |
---|
Managing Pricing & Availability per Service Modes on a Restaurant-level1) PricingDifferent pricing between service modes will be managed by priceSequence within the same definitionSequence. Applicable for all products (item, combo, modifier).
2) AvailabilityGET Menus call returns all items for a given store, it doesn't take availability into account. To retrieve unavailable items per store, we need to make another call to the UNAVAILABLE endpoint, which returns the list of unavailable items. Hence, whenever we build the store menu (after a guest selects a restaurant in the platform), we need to call both endpoints to determine availability on a store-level:
Operators in the restaurant manage items availability on a store-level using the POS, Oracle POS only supports that on store-level for both service modes - not distinguishing availability per service mode. Assumption: In general, menu item availability is not managed specifically differently per service mode (on a store-level). For specific items whose availability is different for pickup and delivery within the same store, the following will be the suggestion to the operator: |
In certain markets, there are menu items whose availability can be temporarily different for different service modes on a restaurant-level. Meaning, item_1 being available for pickup and delivery normally for a given store, but temporarily needs to be made unavailable only for the delivery service mode while still being available for pickup. An example of this is packaged ice creams not being sold via delivery temporarily during heat hours but still sold on pickup. For those items, the configuration requires two distinct PLUs per service mode, as well as 2 separate Sanity menu content documents. To illustrate:
The market has 500 menu items in total. Menu item availability for almost all menu is managed per store for both service modes (if a menu item is not available in the restaurant for online pickup ordering, then it also won't be available for delivery).
There are only 10 menu items that could have different availability per store and service mode at the same time, like the icecream example mentioned above.
The operator configures a single PLU for 490 items, the same PLU is shared for both service modes. Availability is managed for both service modes at the same time on a store-level - always.
For the 10 exceptional menu items, distinct PLUs are defined per service mode - in total 20 PLUs.
These different PLUs then can be marked available/unavailable via the Oracle POS to manage availability differently per service mode.
Similarly, 2 unique Sanity menu documents are created for these items, one for each service mode. Example: Ben & Jerry's Icecream Pickup and Ben & Jerry's Icecream Delivery. Applicable pickup and delivery PLUs are then added to each document. This is different than the remaining 490 items where there is a single Sanity menu item document and the same PLU is entered for both service modes under Vendor Configs.
This setup is required for the guest application to manage the availability correctly.
...
Info |
---|
Items
Single item
Expand | ||
---|---|---|
| ||
Code Block | | |
|
Info |
---|
Combo Size ConfigurationWe will aim to manage different combo sizes with different PLUs (e.g. small, medium and large combos all having different PLUs). We would need default sides selected for each combos to be able to show the pricing correctly. We might need to have this default logic enforced to the operator on Sanity (either implemented or a small button/toggle will be added to Sanity.) |
Info |
---|
ModifiersA single PLU will be used for each modifier, and no PLUs for modifier multipliers. Modifier multipliers will be managed via prefixes, and prefixes will be enabled by RBI Tech platform by utilizing the quantity-based PLU or multiconstant PLU solutions. Having one of these solutions work will require some work on partnersAPI and likely within platform (menu and pricing). To improve the experience of the operator, a single Sanity document should be used for management of modifiers on Sanity later on. Therefore, removing the modifier multiplier document from Sanity completely. |
Note |
---|
Note that the above agreements (especially the service mode management via pricingSequence and using distinct PLUs for different combo sizing) depends on the impact to the restaurant operations. Currently, there are complexities on duplication of buttons for the POS screen which could turn out to be a blocker, will be tested by Jean and then alignment/buy-in will be received from the operations. |
Items
Single item
Expand | |||||
---|---|---|---|---|---|
| |||||
|
...
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Condiment Group
Condiment Item. This applies also to
| ||||||||||
Expand | ||||||||||
| ||||||||||
|
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Combos
Note |
---|
Oracle can only handle up to 10,000 combos. |
Info |
---|
Combo pricing can be configured in 2 different ways:
In both cases the total combo price = combo price + main item price + side 1 price + side 2 price. Therefore, summing up prices of everything always gives to total. |
Info | |
---|---|
For different combo sizes, Oracle has 1 PLU per combo for all sizes. Different sizes are distinguished based on the size of the two sides. Take the Whopper combo – Oracle has 1 PLU for combo small Whopper. To have a medium Whopper, we would have a medium drink and medium fries, which would be considered as premium sides and therefore have a higher price, which would add up to the total combo price following the calculation explained above. However, Oracle can technically create different PLUs per combo size
|
Combos
Note |
---|
Oracle can only handle up to 10,000 combos. |
Single combo
Expand | |||||
---|---|---|---|---|---|
| |||||
|
...