Menu Digitisation: Printed Menus to Structured Data

Often, yes — we built the handwriting side for forms and it carries over. But the confidence is lower than on printed text and it should be. A specials board photographed at an angle in bad light is the hardest input in this whole category, and the right behaviour is to return what it is sure of and flag the rest, not to invent a dish name.

Reliable enough to be a first pass, not reliable enough to be the final word, and we will not pretend otherwise. Deriving allergens from a dish description is inference: "pesto" usually means pine nuts and parmesan, but not in every kitchen. The system flags what it infers as inferred, separately from what the menu states outright, so a human confirms before anything reaches a customer with an allergy.

Common, and handled — a bilingual menu comes back with both, linked to the same dish rather than as two unrelated rows. Where a dish name is a proper noun that should not be translated, it is left alone.

Yes, and for platforms this is usually the real requirement. Reading the menu is the easy half; deciding that this venue's "Margherita" is the same product as the one already in your catalogue is the half that takes judgement. We do that matching with a confidence score and leave the uncertain ones for review.

It reads what is on the menu, which is the honest answer. If the printed card is out of date, the data will be too. Where you need current prices, the sensible pattern is to digitise once and then take updates from the POS rather than re-photographing the card.

It starts with a free assessment: send us a handful of menus — including the messy ones, the handwritten board and the bilingual card — and we will run them and show you exactly what came out. Within 24 hours, from the engineer who would build it. If your menus turn out to be easy, we will tell you that too, and the project will be smaller than you expected.