Getting your menu ready to import

The import step accepts a menu file — a PDF, an image, or a spreadsheet — or menu text pasted directly, and it explicitly does not need either one arriving pre-formatted. What it needs is coverage: every item's name, its price, and the category it belongs under. A menu that already exists somewhere — the PDF you hand customers, a spreadsheet your point-of-sale exports, even a photo of a printed menu — is a perfectly good starting point exactly as it is.

01What the import step actually needs

What it deliberately doesn't ask you to do first is clean anything up. Fixing formatting, reconciling inconsistent naming, or resolving anything ambiguous is the review step's job, immediately after import — not a prerequisite for starting. Making a source document perfect before uploading is extra work the process doesn't need from you.

Categories deserve slightly more care than the rest, because they shape how a caller's own question gets answered. Grouping items the way a customer would describe them — the way you'd answer if someone asked what kind of food you serve — matters more than matching a printed menu's section headings, which are sometimes organized around kitchen workflow rather than how a person orders.

02Gathering what you'll actually be asked for

1. Your current menu source. Whatever exists and is accurate — a file to upload, or text to paste. If the real menu spans more than one document (a core menu plus a specials sheet), bring them in as one combined pass. Upload and text box aren't either-or: a file for the core menu plus a few pasted lines for a handwritten specials note go into the same draft together.
2. Modifiers and their limits. Anywhere an item comes with choices — a size, a topping list, a spice level, an included side — note what's included at no charge, what adds a cost and how much, and any limit on how many a caller can pick. A side that comes standard is a different thing to configure than a topping that adds a dollar, even though both are technically “modifiers.” “Up to three toppings” or “choose one size” is exactly the shape of detail the modifiers step records.
3. Shared ingredients and components. If several items depend on the same thing — one dough for every pizza, one protein across multiple dishes — know that going in. When a shared ingredient runs out, marking it unavailable is meant to affect everything that depends on it at once; knowing what's actually shared, before a busy service, makes that mechanism worth setting up correctly the first time.
4. Anything likely to be mispronounced. House specialties, foreign-language dish names, or in-house nicknames are worth a moment's thought now — there's a dedicated step later for exactly this.
5. Prices for everything, including the small stuff. A missing price on a side item or an add-on is the single most common reason review comes back with something still blocking. Make a final pass specifically checking that nothing priced in your head is missing from the document itself.

03If nothing digital already exists

Not every restaurant has a spreadsheet sitting somewhere convenient, and that's not a reason to delay. A printed menu, photographed clearly enough to read, is exactly as valid a starting point — the import accepts an image specifically because a photo of what's already on the wall is often the fastest real source a restaurant has. There's no requirement to transcribe a paper menu into a document first. The one thing worth checking is legibility rather than formality — a flat, evenly lit shot asks less of the parsing step than a blurry photo at an angle, and a few extra seconds on a clean picture saves fixing several oddly-parsed lines in review.

04What the review step will flag, and why that's normal

After a menu comes in, it sits as a draft and gets reviewed line by line before any of it reaches a caller. That review is where gaps and inconsistencies in the source get caught — not a sign the import went badly. A parsed item missing a price, a name that reads ambiguously, a modifier that didn't map cleanly: these are the review step's entire reason for existing, and expecting a completely clean first pass is the wrong bar.

A “conflict” at this stage usually just means two things in your own source disagree — the same dish appearing twice with two different prices, or a modifier a section mentions without it being defined anywhere. Neither is unusual in a document never written for parsing, and both are exactly what this step catches before a caller encounters the confusion instead.

The same discipline carries forward after the menu goes live: a later edit sits as its own draft until explicitly published, the same way the first import does — an in-progress change never silently reaches a caller mid-review.

05When something doesn't go cleanly

• An item won't parse cleanly from your source. Common with dense PDFs or photos where formatting confuses parsing — the fix is the review step immediately after, correcting the specific item by name, not re-uploading the whole file. If the import fails outright rather than producing a rough draft, the screen says so directly, and trying again is the entire next step.
• A modifier group's limits are ambiguous in your own source. If the printed menu says “choose your toppings” with no stated maximum, resolve that with a specific number before the modifiers step — a limit left unclear is likelier to produce an odd moment on a real call than a typo is.
• Pronunciation needs a manual alias. The pronunciation step generates a first pass of aliases and phonetic hints from your menu text, and it's meant to be edited, not accepted untouched — a house dish name paired with how it should actually sound is a normal, expected correction, not a workaround.

06The step that actually makes it live

Import, review, modifiers, components, and pronunciation each refine the menu, but none of them makes any of it real. That's a separate, final, explicit action at the end of the same group — deliberate design, not oversight. A menu can sit through as many rounds of correction as it needs, over as many sessions as that takes, with no risk that a still-imperfect draft is quietly answering real calls. A menu that looks finished on screen is still not what a caller hears until that last step happens. Preparing well buys you a better draft — the distance between a draft and a live menu stays exactly one explicit action wide regardless.