How it works
Nobody’s first print run should be an experiment.
Changing menu systems is a risk operators are right to take seriously: the failure mode is expensive, public, and printed. Here is how a move to Menuology™ actually runs, and how we take that risk out of it.
The stages of a rollout
Discovery
We look at your actual menus, your current process, and wherever your data lives today: design files, a shared drive, spreadsheets, another system, or all of the above. You get an honest assessment of what carries over cleanly and what does not.
Template build
Your menu designs are rebuilt as templates in the platform, faithfully, not as somebody's interpretation of them. You approve proofs against your existing printed menus before anything goes live.
Loading your data
Your team loads the data: items, prices, modifiers, locations and users. That is deliberate. The people who will run the system are the ones who learn where everything lives. We set the system up, sit alongside you on what goes where, and check the result against your printed menus, whether the load is an export from wherever the data lives now or keyed in from the menu on the table. Values go in as they are today, prices, vintages, references and ordering included, not tidied into something different.
Parallel run
Both systems run side by side and we compare output menu by menu, location by location, until the new system reproduces the old one. No launch weekend, no first print run that discovers a problem.
Training and cutover
We build field guides for your administrators and your store users, your team is trained on their own data, and the old system is retired only once nobody needs it. Then it stays available, read-only, as a backstop.
The part that matters
We prove the new system before you rely on it.
During the parallel run both systems are live and producing the same menus for the same locations. We compare the output, not by eye and not by sampling, but menu by menu and location by location, and we fix every difference until there is nothing left to reconcile.
It is unglamorous and it takes as long as it takes. It is also the reason a cutover is a scheduling decision rather than a leap of faith. When your team stops opening the old system, it is because they no longer need it, not because somebody turned it off.
And the old system stays
After cutover your previous system remains available, read-only, as a backstop. Historical data is retained rather than discarded, including records that were deleted in the old system, which we keep recoverable rather than purging.
Where your menus are now
Wherever it is now, it can come in.
Design files and a shared drive
Your existing designs become templates rather than a redesign project. Your designer’s work is preserved, not reinterpreted, and you proof the result against what you print today before anything is signed off.
Spreadsheets and a very patient person
More common than anyone admits, and a fine starting point. The load into your system is your team’s work, from the spreadsheet or from the menu on the table, and we work alongside you on where everything goes. The harder part is usually agreeing on what the real menu is, which is a conversation worth having anyway, and one we have with you before anything is keyed.
On timelines
How long it takes depends on how many menus you have.
We won’t quote you a number on a marketing page. The honest driver is the size of your template set and the state of your data. A group with a dozen menu designs and clean records moves quickly. A group with a hundred designs and fifteen years of accumulated exceptions does not, and shouldn’t.
What we will do at discovery is count your templates, look at your data, and give you a real schedule before you commit to anything.
Start with discovery.
Show us your menus and where the data lives. You’ll get an assessment of what moves cleanly, what doesn’t, and what the schedule would actually be.