Full Menu Synchronization

This business scenario describes a full menu update that could occur on a campaign/ rollout schedule, or on a more frequent basis. Menu publishers often include either a third-party platform for menu management or direct from the brand’s own data source. Various brand departments are involved in a menu update that often include culinary, finance, operations, marketing and IT. The goal is to coordinate with all stakeholders what needs to be updated on the various menus and then apply those changes to the menu publisher system of record to publish changes to the menu subscribers.

OVERVIEW

Teams work together to update the system of record where the menu publisher at a given time/day will publish the changes by menu subscriber channel.

Use Case

ASSUMPTIONS

• The menu publisher system(s) are assumed to have full API publishing capabilities of the known data points of a menu update as well as enterprise level management for different company configurations. The menu subscriber(s) are assumed to have full API ingestion capabilities of the known data points of a menu update.

PRE-CONDITIONS

• The menu publishing system must be online and connected to the subscribers to share menu updates.

TRIGGER

• A restaurant company has a menu update on a scheduled basis, often referred to as a campaign or rollout. Updates often include new items, deleting items, modifications to existing items, item modifiers for menu item names, descriptions, prices, photos, nutrition and allergen content, availability, tax, channel management and meal periods.

BASIC COURSE OF EVENTS

POST-CONDITIONS

EXCEPTION PATH

ALTERNATIVE PATHS

• The use case starts when menu decisions are finalized by marketing, culinary, operations, finance and franchisees regarding what changes to initiate. • Changes are configured in the menu publisher system(s) of record. • Menu publisher initiates a publishing event to the menu subscriber(s) at a scheduled day/time to push a change set of data for updating ordering channels. • Should support real-time menu changes, rather than just scheduled changes. • A receipt is obtained from the systems signaling a successful transaction of data or exceptions that must be remedied.

• Once updates are published, the data can be manipulated in each subscriber system by using the application admin. For this reason, it’s advisable to implement an audit between systems, checked against the master (menu publisher) at regular intervals and an admin notified of any anomalies.

• The precondition is not met at the time of the update. The user then goes into each subscriber application and makes the updates within the application admin.

This is the non-preferred method, and may include manual intervention.

• Bidirectional link allowing the subscriber to pull a complete menu and a delta report, created by the menu publisher to note the differences for updating the endpoint.

Message Flows

User

1: defineMenuUpdates() 2: scheduleMenuUpdates() 3: initiatePublish()

3: initiatePublish() 4: publishMenus()

: menuPublisher : menuSubscriber

5: sendReceiptAndExceptions()

User

1: defineMenuUpdates() 2: scheduleMenuUpdates() : menuPublisher : menuSubscriber