Three documents to test whether software understands your restaurant

One real procedure, one recipe and one schedule are enough to know whether software understands your restaurant. The procedure tests whether it understands the task, the recipe whether it understands the ingredients, the schedule whether it understands time and people. A tool that reads these three documents as they are, without asking you to rewrite them, has a good chance of fitting your reality.

The evening the software got everything wrong, politely

A fictional restaurateur brings a vendor three documents: a closing sheet written by hand and then typed up, a sauce card with quantities in grams, in "ladles" and in "a little," and a location's schedule with split shifts. The software takes them in with no visible error. The next day, the sauce card shows wrongly converted quantities, the closing is cut into tasks with no role, and the schedule has turned the split shifts into continuous days. Nothing was flagged.

That is the worst case: a tool that does not flinch at what it did not understand. The three documents worked as a test.

Why these three documents rather than others

• They cover the three dimensions of the trade. The task, the ingredients, the time.
• They already exist in almost every restaurant. No need to produce them for the occasion.
• They contain irregularities. That is where the truth about a product hides.
• They are low-sensitivity. With the schedule anonymized, there is no major issue.

First document: the procedure

Choose a procedure actually used in service: closing, receiving deliveries, cleaning a machine. Preferably one the team has modified over time.

What you are testing: the tool's ability to recognize steps, an order, a role, a point of caution.

Encouraging sign	Warning sign
Steps are kept in order	The order is changed without explanation
The relevant role is proposed, for validation	No role is attached
Points of caution stay visible	They are blended into the text
Ambiguities are raised as questions	They are settled without telling you

Second document: the recipe

Take a spec sheet with its flaws: mixed units, a note like "depending on season," presentation variants. A perfect recipe reveals nothing.

What you are testing: whether quantities, units and allergens are respected, and whether the tool flags what is missing.

• Quantities and units are kept with no silent conversion.
• Any allergens are picked up or flagged as needing to be completed.
• A vague mention ("a little," "by eye") is spotted, not rounded off.
• Seasonal variants are kept as variants, not merged.

One point deserves attention: any information that touches food safety or allergens must be validated by a person. A tool that proposes and has it validated is better than a tool that decides.

Third document: the schedule

Take a real schedule from a location, with its split shifts, mixed roles and last-minute replacements. Anonymize the names.

What you are testing: how it reads time, roles and constraints, without judging people.

Question	Good answer	Bad answer
Split shift	Two time blocks kept	One continuous day
Replacement	Visible as such	Erased
The person's role	Attached to the real role	Invented role
Missing data	Flagged	Filled in at random

The test method, in five steps

1. Choose the three documents in the morning, not the night before. Take what is lying around the prep counter, not what is presentable.
2. Remove sensitive data. Names, personal information, anything touching payroll.
3. Have the tool read them, without preparing the ground. No prior formatting.
4. Review the result with a manager. They quickly spot what does not look like how you operate.
5. Note three things: what is right, what is wrong, what is flagged as uncertain. This third group is the most reassuring.

Testing mistakes

• Bringing the vendor's templates. You would be testing their preparation, not their understanding.
• Judging on appearance. A nice layout can hide an error of substance.
• Not reviewing in detail. The errors are in the units, the hours, the roles.
• Forgetting to ask for the source. Each piece of information must be traceable to the original document.

What to observe in the result

• The number of items correctly restored, compared with what your manager expected.
• The number of ambiguities flagged rather than silently resolved.
• The time needed to correct the result, compared with writing everything by hand.

Where Tsuno comes in

This is precisely the principle behind "Try with 3 documents": a recipe, a procedure, a checklist or an anonymized schedule, nothing sensitive. Tsuno extracts, proposes a match, and submits any sensitive mapping to a person: the AI proposes, a person decides. Each fact keeps its provenance, and when data is missing, Tsuno says so instead of making something up. It does not score the people who appear on the schedule: it reads time and roles. Your data stays yours, exportable. For a full setup, the "La Mise au Carré" service starts from the same principle. See the setup page.

To go deeper

Before choosing, read how to choose without being fooled by a perfect demo. To understand why an empty trial discourages, why a free account can be a bad idea. The reasoning on onboarding is in software delivered pre-filled, and the starting framework in do restaurants really need another software tool.

Key takeaways

A procedure, a recipe, a schedule: three real, imperfect, non-sensitive documents reveal whether a tool understands your restaurant. Look for flagged ambiguities, respected units, split shifts kept intact. A tool that admits what it does not understand is more reliable than one that always answers.