One menu record, five surfaces, and a rule for what happens when the kitchen changes an item

Most of the traffic in this category now leaves the building, and each of the channels carrying it holds its own copy of the menu. The item that changes is almost never the item that gets updated everywhere: it is corrected on the website, where the owner can see it, and stays wrong on the two surfaces that actually take the orders. Nobody notices until a guest orders something that no longer exists, which is a kitchen problem by the time anybody hears about it.

The item that changes is corrected on the website, where the owner can see it, and stays wrong on the two channels that take the orders.

1. 01

   A menu is a data problem before it is a design problem

   Name, short name, description, long description, price per channel, modifier group, allergen set, photograph and availability window are fields. Held once, they can be published anywhere. Held as five separately edited menus, they drift within a fortnight and there is no way to tell which one is right.

2. 02

   Each channel truncates differently, so the copy has to survive being cut

   One surface shows forty characters of a name, another wraps a description at two lines, a third strips line breaks entirely. Writing a single elegant description and letting each platform mangle it produces a menu that reads well in exactly one place. Every item carries a short form written deliberately, not a truncation.

3. 03

   Photography is a channel requirement, not a brand luxury

   Marketplace surfaces rank, group and display by image. An item without a photograph is an item that is visible in theory. The standard covers angle, crop ratio and background so a photograph taken in the kitchen in March still sits correctly next to one taken in September.

4. 04

   Allergen and modifier data is the field that carries real risk

   A modifier list that differs between the in-house system and a marketplace listing is a safety problem, not a marketing one, and it is the most common place for the two to diverge because modifiers are edited by whoever is closest to the ordering tablet.

**~75% of restaurant traffic is now off-premises** (National Restaurant Association *2025 Off-Premises Trends*) — the menu on those digital surfaces *is* the restaurant for most orders, so consistency across them is a revenue system, not housekeeping.

One record per item, with every field a channel might need, published outward rather than maintained inward. The website menu, first-party ordering, the marketplace listings and the Google Business Profile menu all derive from it. Photography follows a written standard so images taken months apart sit together. A change log records what changed, who changed it, and when each surface was confirmed updated, with a same-day rule for anything affecting price, availability or allergens. Nothing is edited directly on a channel; edits that happen there are treated as incidents and reconciled back to the record.

1. 1

   Week 1

   Record design

   Field schema agreed, existing menus reconciled into one record, conflicts resolved with the kitchen

   Owner: OmniFlow

2. 2

   Weeks 1–2

   Channel mapping

   Per-surface character limits, image ratios and modifier rules documented

   Owner: OmniFlow

3. 3

   Weeks 2–3

   Photography standard

   Angle, crop and background standard written, backlog shot against it

   Owner: OmniFlow + client

4. 4

   Weeks 3–4

   Publishing and change log

   All five surfaces published from the record, change log live with a same-day rule

   Owner: OmniFlow + client ops

This entry makes no performance claim. It documents a content system and the operating rule that keeps it true: the record is the menu, and a channel is a rendering of it. The test applied throughout was whether a line cook changing an ingredient on a Tuesday results in every ordering surface being correct by service that evening, without anyone having to remember which apps exist.

These are the surfaces this engagement is run and measured from, shown with representative figures built around the benchmarks cited on this page. Every account we run reports into views like these, and you keep ownership of all of them.

We built the publishing side before the change log, so for the first month updates were still being made channel by channel and then reconciled backwards, which is the exact habit the system was meant to replace. The log and the same-day rule should have shipped in week one, when the team was still forming the habit, rather than in week four when they had already formed a different one.

Real client work that shipped. No performance figures are published, because none have been verified and approved for release. See all our work