Two cooks, the same recipe, two different plates. One plates generously, the other sticks to the card, and at the end of the month the cost of goods does not match the costing. The usual explanation is that the staff need better training.
Usually that is not true. When the same dish comes out differently depending on the shift, it is rarely because someone cannot cook, and almost always because nowhere does it say what “right” even means.
This article shows what makes a recipe standardised, what actually has to be written down for that, and why the Excel spreadsheet that almost every business starts with stops carrying the load beyond a certain size.
What is a standardised recipe?
A recipe is standardised when the same dish comes out, regardless of who cooks it and on which day.
That sounds banal, but it is the reversal of what most templates do. They define a standardised recipe by its appearance: as many ingredients as possible, grams as precise as possible. That describes a form, not a goal. And it explains why so many carefully filled-in recipe sheets change nothing anyway.
Thought through from the result, four quantities decide whether the same thing comes out twice:
- The batch size. How many portions does the batch yield? Without this number every quantity is unreadable, because nobody knows what it refers to.
- The quantity per portion. The only quantity that fixes the plate and the costing at the same time.
- The steps that change the result. Not all the steps. Whether the meat goes into the pan in batches or all at once decides the crust; whether you cut the onions before or after decides nothing.
- The finished plate. What the dish should look like and behave like when it is right.
A recipe with fifteen exact weights and no portion count is not standardised. One with four entries and a clear batch size is. The quantities here are always the net quantities, meaning what is left after trimming and actually ends up on the plate; how you get there from the purchase quantity is covered in the article on yield and waste.
How do you tell that your recipes are not standardised?
By four symptoms. Individually, each of them gets blamed on the staff; together they are a system problem.
The same dish comes out differently depending on the shift. The classic, and the only one everyone notices. It gets reported as “they plate too generously”, rarely as “we never fixed how much is supposed to go on”.
The food cost moves without any purchase price having moved. This is the most honest signal, because it cannot be argued away. When supplier prices are standing still and the percentage wanders anyway, the portion is wandering. What else moves that figure is in the article on the food cost percentage.
A new cook needs someone beside them for weeks even though they can cook. Professionally they are ready on day one. What they are missing is nothing to do with craft; it is the information about how this business makes this dish. That lives in a few heads, which is why every onboarding costs more than just the new cook’s time.
There is no quick answer to the question of which version applies. There is a file on the kitchen computer, a printout on the wall and a version somebody adjusted after the last price round. Which of them is the right one? If the answer takes a phone call, it is no.
Anyone who recognises two of these four does not have a staff problem.
What belongs on a recipe card, and what does not?
Less than most templates demand. Plus one line almost everyone forgets.
This is what a card could look like, here for a beef stew with pasta. Cross out whatever does not come up in your kitchen:
| Field | Example | Why it belongs on the card |
|---|---|---|
| Dish and batch size | Beef stew, batch for 20 portions | Without a portion count every quantity is unreadable |
| Quantity per portion | 160 g meat, 200 g sauce, 120 g pasta | Fixes the plate and the costing at the same time |
| Ingredients with net quantities | Beef shoulder 3.2 kg trimmed, carrots 800 g … | Net, not purchase quantity: the yield is already in it |
| Base recipes as a reference | ”Sauce: base recipe red wine sauce, 4 l” | The point where copying hurts later |
| Only the steps that affect the result | ”Pat the meat dry, sear in batches” | Not the whole cookbook, only what changes the result |
| The finished plate | ”Sauce at coating consistency, meat falls apart under pressure” | The only line that creates consistency between two cooks |
| Who, when | ”M. Keller, 12.03.” | Makes the version question answerable |
This recipe card is available as a template to fill in. Two files, direct download, no login, no email address:
- Recipe card template as XLSX: with the beef stew as the example and a how-to sheet
- Recipe card template as CSV: raw, for import into Excel or Google Sheets
The “finished plate” line is the one that appears in almost no template and delivers the most. Quantities can be weighed; whether the sauce is at coating consistency can only be described. That is exactly how the new cook knows they are done.
Just as important is what does not belong on the card. Not the purchase price, because it changes independently of the recipe and makes the card wrong on the day the supplier updates the price list; it belongs in the costing. Not the nutrition values, because no business of this size maintains them. Not the complete step-by-step sequence, because the card is not a cookbook for someone who cannot cook. And not the allergens as a separate column, because those live in the allergen matrix; keep them in two places and you end up maintaining neither.
The rule behind it: what fixes the result belongs on the card. Anything that changes independently of the recipe belongs somewhere else.
That puts three documents side by side that regularly get confused:
| Recipe card | Allergen matrix | Contamination sheet | |
|---|---|---|---|
| Describes | one dish, completely | all dishes times 14 allergens | the kitchen: places and measures |
| Answers | Does the same thing come out? | What is in it? | What can get in by accident? |
| Updated on | recipe change | recipe, product or supplier change | change to equipment, station or workflow |
Three documents, three triggers. Squeeze them into one file and none of them gets maintained.
Why do Excel spreadsheets fail at this?
For twenty recipes at one site they do not fail at all. There a spreadsheet is the right choice, and anyone who claims otherwise is selling software.
They break on a single property, and it has nothing to do with arithmetic. Excel calculates flawlessly. The problem is that the same value sits in several places and nothing holds those places together. That shows up in three ways.
The base recipe sits in several dishes. The red wine sauce is in the stew, in the roast, in the ravioli, on the daily special and on the catering menu. If the base recipe changes, the same line has to be changed in five files, by hand and from memory of which five they were.
The version question cannot be answered. Two files, one printout, one adjusted version in an email attachment. A spreadsheet does not know which of them is the one that applies, and it has no way of knowing.
The forgotten place never announces itself. This is the most unpleasant part. A calculation error shows up because the result looks absurd. An ingredient that got changed in four of five files looks correct everywhere. The fifth is silently wrong from that moment on, and stays wrong until somebody stumbles over it by chance.
That is not a quality judgement on Excel; it is a statement about the construction: a spreadsheet is a good document and a bad system. As a document it holds one recipe cleanly and can be passed on. As a system it is supposed to keep several truths in sync, and it was never built for that.
What that costs in practice can be worked out on your own business. The red wine sauce sits in five dishes. The supplier changes the formulation of the roast stock: five places. If three of those five dishes each have a summer and a winter version, it is eight. The point is not the number; the point is that it grows with the menu, and the time to keep up does not.
How do you introduce standardisation without paralysing the kitchen?
With ten recipes. Not with the menu.
The usual advice is to capture every dish, and that is exactly where every project of that kind fails. Every menu carries a long row of dishes that are hardly ever ordered, and whoever starts at the front and works through alphabetically stops somewhere around the starters.
The entry point that holds is narrower. Ten dishes that carry the revenue. One afternoon. Written down by the person who actually cooks them, at the station during service, not at a desk from memory. At the desk you get the recipe you would like to have; at the station you get the one the business actually makes, including the shortcut everyone has been taking for two years.
After that comes the extension stage, and it genuinely goes beyond it: the rest of the menu, dish by dish, whenever it is being worked on anyway. Base recipes as units of their own that the dishes point to, instead of copied blocks in every file. A fixed trigger for updates, so they do not depend on chance. And the wiring into the costing and the allergen matrix, so that a change in one place does not create silent errors in others.
Whoever does just the ten and stops there has the larger part of the benefit. Whoever starts with all of them has, in the end, a half-filled template and the conviction that standardisation achieves nothing.
What happens when a recipe changes?
It is never just the recipe. Four things shift at the same time.
The costing, because a changed quantity shifts the cost of goods per portion and with it the percentage the business steers by (food cost). The allergen information, because a new ingredient or a new convenience product changes the declaration, and with nested recipes a changed base ingredient pulls every dish it sits in along with it (matrix). The yield, and with it the portion count, as soon as a cut or a cooking method changes (yield). And finally what the guest reads, on the menu or on the sign (declaration).
That is exactly why standardisation cannot be worked off as a documentation task. A binder of complete recipe cards is correct on the day it is finished and a little less correct every day after that. The real question is not whether the values are written down, but whether they are connected to each other.
How do you keep it under control when ten recipes become a hundred?
From the point where a base recipe sits in several dishes, keeping up becomes the actual work. That is exactly what we are building Trolevo for.
Recipes live there with nested sub-recipes: the base recipe exists once, and the dishes point to it instead of copying it. Change the red wine sauce and it changes in every dish that uses it. The allergens from all ingredients and sub-recipes roll up automatically into one allergen label per dish, portion scaling converts the batch to any portion count, and the costing hangs off the same numbers instead of a second file. This helps you meet the labelling duty; responsibility for correct information stays with the business.
What it does not do, plainly: it does not write your recipes down, it does not decide which steps change the result in your kitchen, and it does not replace the ten recipes from the section above. Someone who can cook has to write those down once.
If all you want is to bring one batch to a different portion count, our free recipe scaler is enough. Trolevo itself is in development – get early access.