Cap the Covers on the Night One Person Is Running the Room

By then every option left is a bad one. The owner can ring guests who have already booked and ask them to come another night. They can let the room fill and hope the tickets arrive in a merciful order. Or they can switch off bookings for the whole date and lose the guests they could have fed comfortably at the pace one person can actually cook. A kitchen pushed past what one pair of hands can plate shows up at the table as long gaps between courses, food waiting under the lamp, and a dining room sold a pace the night cannot keep. Either way, the guests who booked in good faith pay for a staffing gap they never knew about.

A booking diary does not know who is on the rota. It knows how many tables there are, what hours the restaurant keeps and how many covers the room normally takes. On a short-handed night every one of those facts is still true. The tables are all still there, the door still opens at six, and the room could still physically seat a full service. What has changed is how many plates the kitchen can send out at once, and that number sits in the owner's head, not in the diary.

So the diary does exactly what it was set up to do and offers the night the restaurant usually runs. Each booking is reasonable on its own. The trouble shows when they are added up, and by then the guests are holding their confirmations.

No measured figure for how often a small restaurant runs a service short-handed, or what that costs in refunds, complaints or lost repeat visits, was located in this research. None is offered here. The cost is argued from how a diary works, and every owner who has worked the pass alone can supply their own evidence.

The owner in the opening scene sees two moves. One is to leave the diary open and let the evening fill. The other is to close the date to bookings and take whoever walks in.

Leaving it open is the default, and it is how the room ends up booked to a normal night's level with half a kitchen. Closing it overcorrects. It turns away the couple who would have booked at seven and the table of four at eight, guests the kitchen could easily have fed, because the only switch to hand was off or on. On a night that is already costing money in lost capacity, closing the diary throws away the part of the trade that one person can still serve well.

There is a third move that looks tempting and does more damage than either: editing the restaurant's published opening hours to make the evening shorter, so that fewer bookings fit. It treats a booking problem by changing a fact every guest can read. The website then tells walk-ins, regulars and anyone checking the hours that the restaurant keeps a different evening, when the door is going to be open as usual. Someone has to remember to change the hours back, and until they do, the site is wrong.

The useful question is not whether to take bookings tonight. It is how many. That is a number, it belongs to one date, and the owner is the only person who can choose it.

Staff can enforce a limit only if the booking system lets them write it down. For a short-handed night, that means a handful of things.

A limit that belongs to one date. The constraint is tonight's rota, not the restaurant's usual week. Whatever is set should apply to the one night and leave every other night alone, with nothing to remember to undo afterwards.

A number the owner picks. The right figure comes from the kitchen on the night: who is cooking, what is on the menu, how the dishes behave when they are all ordered at once. It is not the size of the room or the number of tables on the floor plan, so the system has to accept a figure lower than the room's usual capacity.

Bookings that keep coming, up to that number. The aim is to keep selling the part of the night the kitchen can serve. Once the number is reached the form should stop offering the evening, without the owner having to watch it.

Published hours left alone. The door opens at the usual time, and the website should go on saying so.

One service or the whole day. If lunch is fully staffed and only dinner is short, the limit should land on dinner and leave lunch alone.

A clear answer when two rules meet. If the owner has both closed a date and capped it, the system should settle which one applies, so the evening has one rule rather than two.

In TableSpark this is a dated exception that sits with the booking rules, not with the opening hours. The hours-and-booking-rules guide keeps the two apart on purpose. Weekly hours and special dates live under Settings, while the rules that decide what a booking is live on the Bookings page, behind a button called Services & rules. The covers cap lives on the booking side:

The guide names the short-handed night directly as one of the panel's two uses:

The form itself takes three choices:

That is the setting the opening scene lacked. The owner picks tonight's date, picks Dinner if lunch is covered or leaves it on All services if it is not, chooses Cap covers, and types the number the kitchen can actually serve. Bookings keep arriving up to that figure, and the guide says that pressing Add exception makes it live immediately.

The cap never reaches the restaurant's public face. In the guide's words, the panel "never touches your published opening hours, it only tells the booking engine to behave differently on one date." The website keeps saying the door opens at six, because it does.

When two exceptions overlap, the guide settles it:

So an owner who has already closed the date for a private event cannot end up with a cap quietly running alongside it. The evening has one answer.

This sits beside each service's everyday ceiling rather than replacing it. The guide describes two fields on every service row: "Max covers at once and Stay (min) finish the shape of the sitting — the ceiling on covers in one moment, and how long a table is held by default." The dated cap is a separate setting for one date, set by the owner for that night alone. It leaves each service's Max covers at once untouched, so every other night of the week keeps its usual ceiling without anyone touching it.

Bookings, services and these rules start on the Growth plan, at £39 a month excluding VAT, and are included on Full. Growth is the plan the pricing page labels "Recommended for bookings" and describes as "For restaurants running bookings, tables and guest marketing from their own site." On-site reservations carry 0% TableSpark commission, and the pricing page states that prices exclude VAT. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and on a short-handed night the reason is concrete: the owner can keep selling the part of the evening one person can cook, from the restaurant's own site, without closing the diary or rewriting the hours.

A cap limits how many bookings the diary takes. It does not cook faster, it does not decide who walks in off the street, and on its own it will not make a hard night easy; no such promise is made here. What it changes is the number of guests the website promises a table to before service starts.

The guide sets no figure, and this article sets none either. The right number depends on the kitchen, the menu and the person cooking, and the owner is the only one who knows all three. What follows is a way to get there.

None of these steps needs a formula. Writing it down as a cap means the decision, once made, is held by the diary for the rest of the afternoon instead of by the owner's memory in between tickets.

Tell the guests already booked what to expect, if anything has changed. A shorter menu, a set course or a slower pace is easier for a guest to accept at four o'clock than at nine. A short message to tonight's bookings, in the restaurant's own voice, does that work before service rather than at the table.

Keep large parties in proportion. A group booking takes a disproportionate share of a lone cook's evening, because all of its plates are wanted at once. Where a group has already booked for a short night, the questions about which tables it sits at are covered in the piece on seating a group of twelve in the bar area. On a capped evening, the group is part of the number rather than an addition to it.

Check what the booking page says. Guests who arrive late, park badly or come to the wrong door all cost a lone cook time at the worst moment. The piece on the answers a guest wants before they arrive covers the short practical text worth having on the booking page on any night, and on a short-handed night it earns its keep.

Leave the week alone. The exception belongs to tonight's date. Tomorrow the diary runs on the usual service rules, with nothing to switch back and no hours to restore.

After service, read the diary back. How many covers did the room actually do against the number, and how did the kitchen cope? That is the restaurant's own evidence for where the cap should sit the next time someone rings in sick, and it is better evidence than any general rule.

The strongest inference in this article is that a short-handed night capped at the owner's own number will run closer to what one person can cook than a night left open to the room's usual covers, and no study measuring that was located in this research. It rests on mechanism: a diary only stops accepting bookings at a limit it has been given, and on an ordinary night nobody has given it tonight's.

The owner will still be alone on the pass, and it will still be a hard evening. But the room will have been booked for the kitchen that turned up, not the one on the rota, and the guests who did book will get the meal they were promised.