Press-quality output, and the file is yours

The scheduled run, and the reprint you need in the next ten minutes.

Your menus come out at true print specification: the typography, the spacing and the placement your designer intended, on a file a commercial printer will accept without a conversation. That covers the scheduled run. It also covers the other kind — the salmon ran out at four o'clock, so you pull it, reprint, and the next guest is handed a menu that simply never listed it. No apology at the table, no line struck through in pen, no 'sorry, we're out of that.' The file is an ordinary PDF and it belongs to you: send the long run to your commercial printer, put the urgent reprint through the machine in the back office, or walk it into the shop down the road — different choices for different menus, or different locations, if that suits you better. Plenty of vendors will only sell you menus printed through them, at their price and on their schedule. We hand you the file and stay out of it. Your printer stays your printer. Menuology produces the file; where it gets printed is your decision and always has been.

Price control across every location

One item at one restaurant, or every price nationwide.

Change one item's price at one restaurant, or every price across the country, or anything between the two. Nothing forces you into a sweeping update when what you meant was a single number, and nothing makes you edit four hundred menus one at a time when you meant all of them. Stage changes ahead of the date they take effect, then push them exactly as far as they should go — nationally, across a region or a state, to a group of locations you define, or to that one restaurant. If a push turns out to be wrong, roll it back. Price history and change reporting mean you can always answer what a price was, when it changed and who changed it, without anyone reconstructing it from memory.

Your structure, not ours

National, regional, state, market, group, single location — in any combination.

Items and prices are assigned wherever they actually belong: nationally, by region, by state, by market, by concept, by a group of locations you define yourself, or at one individual restaurant — and in any combination of those at once. A national price, with a different number across one state, and a different one again at the airport location, is an ordinary Tuesday rather than a special case that needs a workaround. You set the exceptions. Everywhere else takes care of itself, so nobody is maintaining a separate menu for every store. This is the part that decides whether a system can hold a real chain at all. Menuology adapts to how your business is already organized. You do not reorganize your business to suit Menuology.

Corporate control, local flexibility

Locations change what you permit, and nothing else.

The structure above decides what reaches a location. This decides what a location may do about it. Where you want the latitude, individual restaurants maintain their own items — a local wine list, a regional special, a seasonal insert — inside limits corporate sets. Where you don't, they simply can't, and the option isn't there to be argued about. Anything a location does add still runs through the same pricing and print rules as everything else, so local autonomy never becomes a gap in the record.

Local beverage programs that stay on brand

Local wine, beer and cocktail lists, set in the corporate template.

Beverage is where a national brand meets a local market. The list that sells in Portland is not the list that sells in Miami, and it shouldn't be — but neither should a store's wine list look like it was typed up in the back office. Locations maintain their own wines, local taps and seasonal cocktails while corporate keeps the core pours, the section structure, the typography and the layout. The result reads as though head office designed it, because head office did. Everything a store adds still flows through the same pricing and print rules as the rest of the menu.

A record of what actually printed

Which menu, which locations, which version, when, and by whom.

Every publish is logged — which menu, which locations, which version, when, and by whom. When someone asks what the Denver store had on the table last Tuesday, the answer is in the system rather than in somebody's memory.

Also included

Everything else, and none of it an add-on.

Not upsells, not modules, not a higher tier. They ship with the product because a menu system without them is only most of a menu system.

Multilingual menus

Every language your guests read, checked before it prints.

Publish the same menu in the languages your guests actually read. Your team reviews and approves every translation rather than trusting a machine with your food descriptions, and you can see at a glance which languages are still incomplete — so a Spanish menu never ships with three untranslated desserts nobody noticed.

Reporting your operators will actually open

Print activity, item usage, change history — all exportable.

See which locations printed what and when, where an item is used across the menu set, and what changed between two versions. Everything exports to Excel. And if you need a report nobody else does, it gets built into your system rather than turned down.

Training materials that stay current

Illustrated training material built around your operation, and kept current.

Rolling software out to a few hundred general managers is a training problem, not a software problem. We build illustrated field guides around your own system — real screenshots of your screens, covering the features your locations actually have, in separate editions for corporate administrators and store users. We keep them current as the software changes, so nobody is ever training from a manual that no longer matches the screen. Most vendors hand you a generic PDF and wish you luck.

Modern authentication

Passkeys, two-factor, role-scoped access.

Passkey sign-in and two-factor authentication, with roles that keep corporate administrators and store users apart. Accounts are created by your administrators — nobody signs themselves up to your system, and nobody is still using a shared password taped inside the office drawer.

The workflow

Draft, proof, publish — with a record of all of it.

1

Author centrally

Items, descriptions, prices and modifiers live in one catalog. A change is made once.

2

Right at every location

Each location gets its own menu: the corporate catalog, plus market pricing, local items, or a section it doesn’t carry. Nobody assembles it by hand.

3

Proof on screen

Previews come back in seconds, so approvals never wait.

4

Publish final

You publish, and every published menu is kept exactly as it went out, so you can always retrieve precisely what a location printed, and when.

The final publish confirmation, with the rendered menu open for review
Sample data throughout — not a client menu.

Connecting it up

Your website should not contradict your menu.

If you have a web team, they can pull your finalised menus straight from Menuology and put them on your site — the same menu you just sent to press, not a copy somebody remembered to update. Nobody retypes a price, and your website stops quietly disagreeing with the menu on the table.

On the roadmap, not yet shipped

QR-code menus for the table, an embeddable menu for your own site, and white-label apps under your brand are all coming. They are not available today, and we would rather tell you that than sell you a date. When they arrive they will show the menu you actually published, like everything else.

Want to see it against your own menus?

The most useful demo we do is the one where we put your current printed menu next to what the system produces.