Managing Toast menus across multiple locations

The real risk is the wrong menu in the right place

In a single restaurant, a stale menu is annoying. In a group, a wrong menu is worse. The airport location charges more than the neighborhood café. One kitchen has a fryer and another does not. A franchise location runs a regional item. If a website, QR page or board shows another location’s menu, guests see prices and dishes that do not exist where they are standing.

These leaks usually happen through shared files and shortcuts: one PDF reused for every site, one board template copied and edited, one website menu page for the whole brand. Each shortcut saves time once and costs time forever.

Write down your location map

Location mapping is the record of which source menu belongs to which public location. Start with a simple table: each location, the menu it runs in Toast, and each public surface it uses, such as hosted page, website embed, QR view and board.

This table becomes the reference for every change. When a location opens, closes, moves or changes concept, update the map first. Garnsh uses a mapping step during setup so each Garnsh location is tied to the correct menu context before anything is published.

Give each location its own surfaces

Every location that has guests reading a menu should have its own public surfaces. A location-specific hosted page. A QR code that opens that page. A board configured for that room. A website that lets guests choose a location and then shows the correct menu.

Not every location needs every surface. A pop-up may only need a QR view. An airport counter may need a board and a QR view but no website embed. The point is that whatever surfaces exist are tied to the right location.

Separate central oversight from local context

Groups often want two things that seem to conflict. Leadership wants one view of what is published everywhere. Each location wants its own menu, prices and promos. Both are reasonable.

The practical answer is central visibility with location-correct content. One place shows the published state of every location and surface. Each location’s content still comes from its own menu. Shared choices such as brand styling can be applied consistently, while prices and items stay local.

Publish per location, with a preview

When a menu change affects several locations, it is tempting to push it everywhere at once. Slow down by one step. Preview each affected location, confirm the prices and items are right for that site, then publish.

Deliberate publishing makes the change visible before it is public. Rollback gives each location a way back to its previous published version if something is wrong. Neither depends on anyone remembering which file to edit.

Review the published state on a schedule

Set a regular review, weekly for most groups. For each location, check when it was last published and whether each surface shows the expected version. Freshness information makes this quick, because it shows when the source was last read and when each public version went live.

A short review catches problems before guests do, such as a location that was skipped during a price update, or a board that still carries last season’s promo.

What Garnsh does and does not cover here

Garnsh publishes location-correct menus to hosted pages, website embeds, QR views and digital boards, with preview, publish, rollback and last-known-good behavior. It does not change menus inside Toast, manage staff permissions inside Toast, run ordering, or manage hardware. Your Toast setup and access determine what menu context is available to connect.