Explain it once: how to keep a restaurant standard alive

A living standard is written once, in four lines, tied to a role, linked to training and to the day's tasks, and corrected in a single place when it changes. You can recognize it with a simple test: ask two team members from two sites to show it to you. If they show the same version, it lives. If not, you have a document.

The sauce that changed twice

A fictional example. The chef decides to cut the salt in a signature sauce. He says so at a kitchen briefing, on a Tuesday. The first site applies it the next day. At the second, the prep commis follows the laminated sheet, which has not changed. Three weeks later, a regular guest writes that the sauce has "changed from one location to the other." The chef looks for someone to blame. There is no one: the posted sheet was the only source the commis had.

The life of a standard in four stages

Birth: write it short

Four lines are enough: the goal, the action, the critical error, the proof. A long standard does not get read, a standard without proof cannot be verified.

Distribution: attach it to what already exists

A standard is only alive if it shows up in three places: the day's task for the role concerned, the training path that prepares for it and the new hire's welcome. Without these three relays, it stays a file.

Revision: one source, one date, one owner

The owner is a role (the head chef, the floor manager). Every change is dated and explained. Only one version circulates.

Retirement: remove what no longer serves

A standard nobody uses is noise. A quarter without anyone consulting or applying it: remove it or rewrite it.

Standard sheet template

Standard: Plating of the daily starter
Goal: identical plate from one service to the next
Action: sauce dot at the 2 o'clock position, protein centered, herbs last
Critical error: plate sent out with a smudge on the rim
Proof: reference photo at the pass, checked by the head server
Owner: head chef
Last review: (date) / reason: change in presentation
Linked to: "plating" task of the cold station, "starters" module of the training

Why a standard dies

• It is created in a meeting and never attached to a task. Nobody has a moment to consult it.
• It has several copies. Each one drifts from the original over time.
• It has no proof. You do not know whether it is applied, so you do not know whether it works.
• It describes everything. It does not distinguish what is negotiable from what is not.

Bringing a standard to life: seven moves

1. Pick a task that costs a lot when it goes wrong. A sauce, a check, a greeting.
2. Have it written by the person who does it best, then reread by someone who does not do it: if they do not understand it, the sheet is too vague.
3. Set the critical error. Just one. It sets the boundary of the standard.
4. Choose a light proof. A photo, a reading, a signature.
5. Attach the standard to a role and to a dated task in the typical day.
6. Link it to the matching skill in the new hire's path.
7. Set the next review, and hold to it.

Dead standard	Living standard
PDF in a shared folder	Sheet linked to a task of the role
Unknown author	Designated owner (a role)
Several versions posted	One version, a dated change log
Applied "when we think of it"	Checked with a minimal proof
Never reread	Review on a fixed date

On the mechanics of instructions that keep coming back, read how many times to repeat an instruction before changing the system. If your standard also has to be used for training, see how to stop training new hires differently at every location. To anchor it to concrete criteria, the skills matrix extends the logic.

Common mistakes

• Writing a standard for everything. Start with the tasks that cost the most when they go wrong.
• Correcting the sheet without telling anyone. A change only exists if it is seen.
• Never removing the old version. It always resurfaces.
• Confusing standard with rigidity. Fix the result and the limit, leave the technique to the team when it allows.

What to measure

• The number of versions of the same standard in circulation across your sites. One.
• The delay between a change being decided and its application being confirmed at the station.
• The number of standards with no review since the planned date.

Where Tsuno comes in

Tsuno keeps standards, procedures and expected skills, dated and viewable. What you keep repeating is written once, assigned to a role, then passed on through checklists, training and onboarding: when the standard changes, the version in circulation changes everywhere. Observed facts (a signed task, a reading, a photo) are attached to the standard with their source. Tsuno does not rate people: a gap points back to the process or the training. See the Tsuno solution page.

Key takeaways

A standard lives if it is short, tied to a role, carried by a task and a training, and corrected in one place. Write it once, date it, and review it on a fixed date.