RTN20 eBook - Menu Sync Software Spec

RTN’s Restaurant Menu Synchronization Specification Industry standard for delivering multiple, complex menu systems for smooth third-party consumption. |1|

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

www.restauranttechnologynetwork.com

Introduction This Restaurant Menu Synchronization Software Specification and related technical materials were created by RTN’s ThirdParty Delivery Workgroup. The workgroup included restaurant operators and technology solution providers who defined the need for a single, comprehensive solution to deliver multiple, complex menu systems to various systems, partners, and distributors that consume this information.

Staff

ABBY LORDEN

KATHERINE WARE

VP and Brand Director, HT Co-Founder, RTN 973.607.1358 alorden@ensembleiq.com

Senior Account Executive, HT & RTN 785.424.7392 kware@ensembleiq.com

NOELL DIMMIG

ANGELA DIFFLY Co-Founder, RTN 404.550.7789 angela@restauranttechnologynetwork.com

Account Executive, HT & RTN 973.607.1370 ndimmig@ensembleiq.com

PATRICK DUNPHY

MOLLY MCLOONE

CIO, HTNG & RTN 312.690.5039 patrick@restauranttechnologynetwork.com

ROBERT FIRPO-CAPPIELLO Editor in Chief, HT 917.208.7393 rfirpo-cappiello@ensembleiq.com

Brand Marketing Manager, HT & RTN 908.433.2796 mmcloone@ensembleiq.com

TAMMY HANSON Membership Manager, RTN 314.570.4798 tammy@restauranttechnologynetwork.com

ANNA WOLFE

CODY CZMYR

Senior Editor, HT 207.773.1154 awolfe@ensembleiq.com

Director of Marketing, Communications and Membership, RTN cczmyr@ensembleiq.com

Copyright 2020 Restaurant Technology Network (RTN). All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or information storage and retrieval systems, without express written permission from the publisher. RTN is a wholly owned subsidiary of EnsembleIQ, with principal headquarters at 8550 W. Bryn Mawr Ave., Suite 200, Chicago, IL 60631.

RESTAURANT TECHNOLOGY NETWORK

|2|

Table of Contents Introduction .................................................................................................................................2 Menu Synchronization Software Specification at a Glance...................................... 4 System Roles................................................................................................................................5 Verification/Audit Between Menu Publisherand Menu Subscribers............................................................................................6 Menu Setup...................................................................................................................................8 Location Setup..........................................................................................................................10 New Menu Item........................................................................................................................... 11 86 Items (Removing Items).................................................................................................. 12 Limited Time Offer................................................................................................................... 14 Full Menu Synchronization.................................................................................................... 16 Key Contributors....................................................................................................................... 18

RTN Mission The Restaurant Technology Network (RTN) is a membership community solely dedicated to the restaurant technology industry. Through access to valuable benefits and powerful connections, our members shape industry standards and share technical guidance to help restaurateurs run successful businesses and better serve their customers.

|3|

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

Menu Synchronization Software Specification At A Glance Used together, RTN’s Menu Synchronization Software Specification and companion documents enable restaurant operators and solutions providers to integrate systems vital to any restaurant menu technology ecosystem. The use cases contained here are not exhaustive, but are meant to provide implementing companies and developers additional guidance.

The use cases and system roles described in this document are companion documentation to the following materials.

Click below + to explore.

+ DOWNLOAD SPEC FILES Definitions, Models, Messages (all)

+

+

ORDER RESOURCES

+

MENU RESOURCES

+ RESTAURANT TECHNOLOGY NETWORK

RESTAURANT DETAILS

TECHNICAL RESOURCES

|4|

(all)

System Roles The following system roles are used throughout this specification.

ROLE NAME

DEFINITION

EXAMPLE

MENU PUBLISHER

A software system that contains a product catalog, including a name, pricing, description, nutrition, options, availability, tax, images, location, meal periods, order channels.

POS, Menu Management System, Online Ordering Providers, Content Manager

MENU SUBSCRIBER

A software system that subscribes to the menu system and is notified of any change.

Third-Party Delivery Providers, Kiosks, Online ordering systems

MENU CONTENT PUBLISHER

Provides additional detail, photo, video around an individual menu item.

Pushes out changes from a centralized location to all thirdparty delivery companies as well as additional restaurant infrastructure that can accept these changes (i.e. menu boards)

RECIPE MANAGEMENT

Provides product formulation, nutrition analysis, recipe analysis, virtual experimentation, government-compliant labeling

Food & Nutrition Analysis software (ESHA)

INVENTORY MANAGEMENT

Food cost, vendor management, inventory availability

NA

ONLINE ORDERING SYSTEMS

Digital ordering and delivery enablement

NA

MENU MAPPING SYSTEM

Maps product IDs from disparate systems to one another, for example: matching an item ID in a POS to an Item ID in a third party system

NA

|5|

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

Verification/Audit Between Menu Publisher and Menu Subscribers Use Case ASSUMPTIONS

• Menu publisher has the ability to connect with a location’s POS to retrieve menu data.

• Menu subscribers are integrated with the menu publishing system.

PRE-CONDITIONS

• A restaurant’s POS is online.

• Menu publishing system is online.

• Menu subscribers can communicate with the menu publishing system.

• A restaurant’s customer facing menu has been curated in the menu publishing system and is active.

TRIGGER

• Menu health check

BASIC COURSE OF EVENTS

• Menu publisher checks the health of a menu 2 hours prior to a location opening.

• Validates that all items & modifiers on the customer facing menu can be found on a location’s POS. • Retrieves updated pricing for items & modifiers.

• If an item or modifier is not found on the POS or multiple versions exist, menu publisher automatically 86’s the entity on the menu.

• Menu publisher notifies the restaurant if any items or modifiers have been 86’d during the menu health check.

• Restaurant addresses the issue on the location’s POS (This is sometimes handled manually, and across multiple endpoints).

• Menu publisher checks the health of a menu again 30 minutes prior to a location opening to pick up any POS changes made by the restaurant as a result of the first menu health check.

• Customer-facing menu is ready for retrieval by menu subscribers or scheduled pushes to ordering platforms.

POST-CONDITIONS

• The updated customer-facing menu is available on ordering platforms for restaurant consumers.

EXCEPTION PATH

• The menu publisher is not able to connect to a location’s POS. • The menu subscriber is not able to connect to the menu publisher.

ALTERNATIVE PATHS

• Retrieve menus once all systems are online.

RESTAURANT TECHNOLOGY NETWORK

|6|

VERIFICATION/AUDIT

Message Flows The following is an example message flow with methods that demonstrate operations against each system.

: POS 2: getMenuItemsAndPrices() 1: menuHealthCheck() : menuPublisher 5: correctMenu()

4: notifyMenuDiscrepency() 3: publishItemUpdates() User (Restaurant)

: menuSubscriber

|7|

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

Menu Setup The following use cases describe an example process for initial menu setup and synchronization between two systems.

Use Case ASSUMPTIONS

• The menu publisher has the ability to connect to all subscribers through an API or menu subscribers are able to listen for updates.

PRE-CONDITIONS

• The menu publishing system must be online and connected to the subscribers to share menu updates, or the menu subscribers are able to reach out earlier and download the changes to local cache.

TRIGGER

• The restaurant is onboarding for the first time, or the restaurant is republishing an existing menu.

BASIC COURSE OF EVENTS

• The user creates a new item.

• The user sets price for the item (multiple prices may be set based on need).

• The user adds other information such as description, display titles, images, nutritional information, etc. to the item.

• The user adds additional modification options to the item.

• The user adds the item to a menu.

• The user selects brand/locations /store where this menu will apply.

• The user selects meal period where this menu will apply.

• The users selects date and time restrictions for LTO if applicable.

• The menu publisher makes the menu available to all subscribers.

POST-CONDITIONS

• The updated customer-facing menu is available on ordering platforms for restaurant consumers.

EXCEPTION PATH

• The menu publisher is not able to connect to subscribers or subscribers are not able to reach the publisher because they are offline.

ALTERNATIVE PATHS

• The user can also go directly to each subscriber and manually create a menu.

RESTAURANT TECHNOLOGY NETWORK

|8|

MENU SETUP

Message Flows

User

1: createItem() 2. setPrices() 3: addDetails() 4: mapItemToMenu()

: menuPublisher

8: newItem()

: menuSubscriber

5: mapItemToBrandsAndSites() 6: mapItemToCalendarClock() 7: publishItem()

User

1: createItem() 2. setPrices() 3: addDetails() 4: mapItemToMenu()

: menuPublisher

: menuSubscriber

5: mapItemToBrandsAndSites() 6: mapItemToCalendarClock() 7: publishItem()

User

createItem()

: menuPublisher

: menuItem

: menu id

+ + + + + + +

+ + + + + +

id prices description displayTitles images nutrtional information modification options

id items brands locations mealPeriods ItoDetails

: location + id

: brand + id

: mealPeriod + id

publishItem()

: LTO + id + startDateTime + endDateTime

: menuSubscriber

|9|

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

Location Setup The following use case describes how to set up a location to consume menu data. Typical scenarios may include a new unit added to a chain, virtual stores, or ghost kitchens.

Use Case ASSUMPTIONS

• The publisher has the ability to connect to all subscribers through an API or subscribers are able to listen for updates.

PRE-CONDITIONS

• The publishing system must be online and connected to the subscribers to share updates, or the subscribers are able to reach out earlier and download the changes to local cache.

TRIGGER

• The restaurant is onboarding for the first time or a new location is added to an existing chain restaurant.

BASIC COURSE OF EVENTS

• • • • • •

POST-CONDITIONS

• The location is available on the subscriber for ordering.

EXCEPTION PATH

• The publisher is not able to connect to subscribers or subscribers are not able to reach the publisher because they are offline.

ALTERNATIVE PATHS

• The user can also go directly to each subscriber and manually add locations.

The The The The The The

user creates a new location. user adds address, working hours, order channels to the location. user adds GPS coordinates for the location. user adds KML file for delivery zone (optional). use maps the internal location id to subscriber location ID. user publishes the location to the subscribers.

Message Flows User

User

1: createLocation() 2. setWorkingHours() 3: setOrderChannels() 4: setGPSLocation() 5: setDeliveryZone() 6: mapSubscriberLocation() 7: publishLocation() 1: createLocation() 2. setWorkingHours() 3: setOrderChannels() 4: setGPSLocation() 5: setDeliveryZone() 6: mapSubscriberLocation() 7: publishLocation()

RESTAURANT TECHNOLOGY NETWORK

LOCATION SETUP

: menuPublisher

8: newLocation()

: menuPublisher

| 10 |

: menuSubscriber

: menuSubscriber

New Menu Item Use Case ASSUMPTIONS

• The new product is created in the system of record. The product is named, attributes are added (such recipe items in the example of Boss Burger, One White Bun, Chicken Patty, Tomato, Mayo, etc.).

PRE-CONDITIONS

• The system must be live and connected to the edge points to share menu updates. The system must be able to connect to the edge at any point of time to trigger the change in the menu.

TRIGGER

• The item creation and associated actions such as time and date.

BASIC COURSE OF EVENTS

• The menu publisher will add a new item to the system, tag a date and time for when it’s live, add any attributes; the restaurant(s), channel(s), images. Based on the criteria, the system will push the changes.

POST-CONDITIONS

• The updates to the edge are received, the application level adds, edits and publishes on the edge. This step may include manual intervention.

EXCEPTION PATH

• The precondition is not met of connection at the event time. A pull request generated from the edge to receive all updates or full menu for that date and time.

ALTERNATIVE PATHS

• Complete menu pull request from the edge to the system of record.

Message Flows User

User

1: createItem() 2. setPrices() 3: addDetails() 4: mapItemToMenu() 5: mapItemToBrandsAndSites() 6: mapItemToCalendarClock() 7: publishItem() 1: createItem() 2. setPrices() 3: addDetails() 4: mapItemToMenu() 5: mapItemToBrandsAndSites() 6: mapItemToCalendarClock() 7: publishItem()

MENU SETUP

: menuPublisher

: menuPublisher

| 11 |

8: newItem()

: menuSubscriber

: menuSubscriber

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

86 Items (Removing Items) The following use case describes an example process that removes an item for an arbitrary reason and/or timeframe. This process can be used in situations such as, but not limited to: lack of inventory, recalls, availability by a particular order channel (in-store, online, third-party, etc.).

Use Case ASSUMPTIONS

• The menu publisher has the ability to connect to all subscribers through an API or menu subscribers are able to listen for updates.

PRE-CONDITIONS

• The menu publishing system must be online and connected to the subscribers to share menu updates, or the menu subscribers are able to reach out earlier and download the changes to local cache.

TRIGGER

• The restaurant is out of stock of a particular item, or temporarily removing an item from sale, or any arbitrary reason to remove an item from a menu from any menu subscriber.

BASIC COURSE OF EVENTS

• The user identifies an item that is out of stock or low in inventory.

• The user uses the menu publisher to set the selected item(s) to zero for one or all menu subscribers.

• The user selects brand/location/store where this change will apply.

• The menu publisher updates the item availability to all subscribers.

• The items can no longer be ordered at selected subscribers. The items are either disabled or hidden from the ordering menu.

POST-CONDITIONS

• As the inventory system is updated with additional order the menu publisher resets the selected item back to available.

EXCEPTION PATH

• The menu publisher is not able to connect to subscribers or subscribers are not able to reach the publisher because they are offline.

ALTERNATIVE PATHS

• The menu publisher is able to replace the menu completely at all subscribers if it is not able to update individual items on the menu. The user can also go directly to each subscriber menu and manually remove the items from the menu.

RESTAURANT TECHNOLOGY NETWORK

| 12 |

86 ITEMS

Message Flows

User

1: adjustAvailability()

: menuPublisher

2: updateItem()

: menuSubscriber

User

1: adjustAvailability()

: menuPublisher

: menuSubscriber

User

1: adjustAvailability()

: menuPublisher

| 13 |

2: publishFullMenu()

: menuSubscriber

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

Limited Time Offer The following use case describes a potential implementation of a limited time offer (LTO), which is essentially a temporary menu item, temporary price, or other aspect of a saleable item.

Use Case ASSUMPTIONS

• The menu publisher has the ability to connect to all subscribers through an API or menu subscribers are able to listen for updates.

PRE-CONDITIONS

• The menu publishing system must be online and connected to the subscribers to share menu updates, or the menu subscribers are able to reach out earlier and download the changes to local cache.

TRIGGER

• The restaurant is running a temporary promotion like LTO or happy hour.

BASIC COURSE OF EVENTS

• The user identifies an item for a LTO. • The user uses the menu publisher to set the start date, time and end date and time.

• If the offer is recurring by day of week or time day, the user adds those conditions.

• The user selects brand/location/store where this change will apply.

• The menu publisher updates the item availability to all subscribers.

• The item(s) become visible at the designated start date and time, and is hidden at the designated end date and time.

POST-CONDITIONS

• If the LTO is recurring, the item automatically becomes visible or hidden based on date and time range.

EXCEPTION PATH

• The menu publisher is not able to connect to subscribers or subscribers are not able to reach the publisher because they are offline.

ALTERNATIVE PATHS

• The menu publisher can replace the full menu at all subscribers if it is not able to update individual items on the menu. The user can also go directly to each subscriber menu and manually add and remove the items from the menu.

RESTAURANT TECHNOLOGY NETWORK

| 14 |

LIMITED TIME OFFER

Message Flows

User 1: createLTO() 2: addTimeDetails()

: menuPublisher

4: updateItem()

: menuSubscriber

3: mapLTOToBrandsAndSites()

User 1: createLTO() 2: addTimeDetails()

: menuPublisher

: menuSubscriber

3: mapLTOToBrandsAndSites()

| 15 |

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

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

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

POST-CONDITIONS

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

EXCEPTION PATH

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

ALTERNATIVE PATHS

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

RESTAURANT TECHNOLOGY NETWORK

| 16 |

FULL MENU SYNCHRONIZATION

Message Flows

4: publishMenus()

User 1: defineMenuUpdates() 2: scheduleMenuUpdates()

: menuPublisher

: menuSubscriber

3: initiatePublish()

5: sendReceiptAndExceptions() 3: initiatePublish()

User 1: defineMenuUpdates() 2: scheduleMenuUpdates()

: menuPublisher

| 17 |

: menuSubscriber

RTN’S RESTAURANT MENU SYNCHRONIZATION SPECIFICATION

www.restauranttechnologynetwork.com

Key Contributors

STUART PRILLAMAN

BRIAN WHITNEY

SUSAN LUCAS

Principal Architect Appetize

VP of Sales Appetize

Sr. VP of Technology Cooper’s Hawk

ROHINEE MOHINDROO

SHAUN SHANKEL

DAVID JONES

GEORGE HUTTO

TOM FOX

CHRISTY TRINKLER

CEO Fresh Technology (ToGo Tech)

VP, Major Accounts & Channels HungerRush

Sr. BI Developer MOD Super Fast Pizza

Chief Business Officer Omnivore

Sr. Dir., Product Marketing & Strategic Partnerships Trabon

JOSHUA NORD

PARIJAT JAUHARI

ROBERT PETERSON

SKIP KIMPEL

CHRISTOPHER SEBES

VP, Software Development QSR Automations

VP, Product Management Qu

VP of Sales Qu

CIO 4 Rivers Restaurant Group

Partner RTS

Founder Dyjit

LUCY LOGAN CEO FoodCalc

Additional Contributions

RTN Vision

Join Us

In an industry built on service and entrepreneurial spirit, purpose-built technology fuels success.

The Restaurant Technology Network aspires to help restaurant professionals and solution providers work together to solve problems large and small and inspire bold ideas for the future.

If you have a vested interest in the restaurant technology industry, join us. Collectively, our members shape the industry by creating and disseminating technology standards and technical guidance to benefit members. Through our cornerstone virtual think-tank workgroup meetings, our members solve industry challenges and prosper inside a unique, collaborative environment.

RESTAURANT TECHNOLOGY NETWORK

+ VIEW OUR MEMBERS | 18 |