How a caterer plans a week that is already paid for
A vertical probe on catering: deposits mean the demand is known months out, so the risk moves to headcounts that drift, specification changes, and dietary lists that arrive late. Why a confirmed booking is not yet a confirmed order. General piece: no research was attached, so it carries no catering figures.
The problem most trades have, in reverse
Most of the makers I write for spend the week guessing at demand. How much footfall on Saturday, how many flat whites the café will actually shift, how many loaves to bake before anyone has ordered a loaf. You make to a forecast and you eat the difference.
A caterer starts from the other end. The June wedding is booked in March. The deposit has cleared. The date is in the diary and it is not moving. The demand you spend most of your year trying to predict is, for a caterer, already known and already paid against.
That sounds like the easier job. In some ways it is. But taking a deposit does not settle the week, it only settles the date. Everything that decides what you actually buy and cook is still loose, and it stays loose until much later than you would like.
What the deposit actually buys
A booking with a deposit gives you a commitment and a date. It tells you a client is serious and it puts money on the table so that seriousness costs them something to walk away from.
It does not tell you what to buy. Not really. In March you have a rough headcount and a rough idea of the food. You do not have the final number, you do not have the last round of menu changes, and you almost certainly do not have the full list of who cannot eat what. The order you place with your suppliers depends on all three, and all three arrive late.
So the booking is confirmed and the order is not. Those are two different things wearing the same word.
The headcount that drifts
The number moves. It nearly always moves, and it usually moves the wrong way for planning: small changes, often, right up to the end.
A couple more guests. A table that dropped out. The client's own family arguments playing out on your spreadsheet three weeks before the event. Each change on its own is trivial. The problem is that a headcount is not a single fact you can write down once, it is a number that keeps being edited, and every edit ripples back into what you order and how much you prep.
If you locked your order to the March number, you are wrong by June. If you wait for the real number, you are ordering later than you wanted to.
The spec change and the late dietary list
Alongside the headcount, two other things drift.
The specification. The client saw something on Instagram, or the venue changed the layout, or the couple decided halfway through that they wanted a different main. A menu that was agreed is quietly not the menu any more, and the change often arrives as a message rather than a signed-off document.
Then the dietary requirements, which almost always land last. The coeliac, the tree-nut allergy, the table of four who are vegan, the guest whose intolerance is really a strong preference. This is the detail that turns up closest to the event and matters most to get exactly right, because getting it wrong is not a rounding error, it is someone in trouble at a party. You cannot finalise your ordering until you have it, and you rarely have it early.
The squeeze
Put those together and you get the real shape of a caterer's week. The money came in months ago. The information you need to spend it well comes in at the last minute. You are committing to your own suppliers, who have their own lead times, before your client has committed their final numbers to you.
That is the pressure the deposit hides. It looks like certainty and it behaves like a countdown. The closer you get to the date, the more the picture firms up and the less time you have left to act on it.
I have planned a week against a booking sheet
I spent about a decade cooking, and I was head chef in the French Alps. A kitchen's week is not one thing. Part of it is walk-in trade you can only estimate, and part of it is already spoken for: the tables booked, the group in on Friday, the function you have known about for a fortnight. You plan your prep and your ordering against that fixed part first, because it is the part you are certain of.
Except the fixed part is only fixed until the phone rings. The party of ten becomes fourteen. The set menu picks up two changes on the day. Someone mentions an allergy when they sit down that nobody flagged when they booked. I was also on the other side of it as a buyer, taking deliveries from producers, so I have seen what a shifting number does upstream: the order that was placed against one figure and needed to be another by the time it arrived.
Catering is that shape with the volume turned up and the timeline stretched out. Same certainty at the front, same drift at the back.
Make the booking a living order
The mistake is treating a confirmed booking as done. It is the start of a record that will change several times before it settles, and the changes are the whole job.
What helps is having one place where the booking lives as an order, not as a deposit receipt filed under "sorted" and a scatter of later messages amending it. One record you update when the headcount moves, when the menu changes, when the dietary list finally lands, so that the version you order and cook from is the current one and not the March guess you happen to remember. And when the event is done, the invoice comes off the numbers you actually catered, not the numbers you first quoted.
That is the part makeweek is built for: keeping an order that changes as one live thing instead of a note you are trusting to hold, and turning the final version into the invoice without you rebuilding it from memory. It does not order your ingredients for you and it does not track your stock. It keeps the commitment and its changes in one place, which is where most of the week actually leaks away.
A deposit tells you the work is coming. It does not tell you what the work is. The gap between those two is where a caterer's week is really planned, and it is worth treating that gap as a job rather than a surprise.