Page Comparison

Modifiers

Most markets support 2 levels of modifiers for mobile ordering: Add and No.

• 2 dimensions - service mode and quantities (multipliers).

• We can distinguish between service modes and multipliers using a combination of the 3 IDs.

• Recommendation: Use priceSeq and single constantPLU per modifier, keep definitionSequence constant, no PLUs to be defined for modifier multipliers separately.

For management of modifier multipliers beyond these 2 levels (light, heavy, 2 bacons, etc.), we will use the X field in Oracle instead of defining modifier multipliers.

• Two main modifiers:

  • Most markets support 2 levels of modifiers for mobile ordering: ADD and NO.

    • Remove (“No”). No multiples available.

    • “Add”, which will have several quantities (multiples for each quantity – e.g. 1x ketchup, 2x ketchup).

  • Each modifier has a priceSequence - 1 for pickup and 2 for delivery, just like items and combos.

  • PriceSequences will be used for determining the ADD and NO modifiers, as well as pricing across service modes. Khumbu will manage the mapping for PLU+definitionSeq+PriceSeq as shown in phase 2 on the slide deck.

  • Similarly, for management of modifier multipliers beyond the ADD and NO values for modifiers (light, heavy, 2 bacons, etc.), other pricing sequences or definitionSequence will be used.

• Recommendation: Use priceSeq and single constantPLU per modifier, keep definitionSequence constant, no PLUs to be defined for modifier multipliers separately.

  • In cases where a modifier is not available in delivery service mode specifically (while available for pickup), this could be managed via empty vendor config in Sanity for display in whitelabel. (The pricing for the modifier will still be managed via the mapping with Khumbu).

Alternative to using PricingSequence or DefinitionSequence for Multipliers - the Quantity Field: This will be enabled by RBI Tech platform by utilizing the multiconstant PLU solution. Having the multiconstant PLU solution work will require additional engineering effort (e.g. there are gaps in partnersAPI, and potentially Menu Service in general).

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.