Adding Christmas Day to the Website Without Calling Anyone

Those hours are read by people who are about to get into a car. A guest checking a restaurant's own site on the morning of a bank holiday is not browsing; they are deciding whether to leave the house. If the page still shows the ordinary week, the restaurant has published an invitation it cannot honour, and the cost of that lands on the floor rather than on the website: a family at a locked door, a phone ringing through a closed service with nobody rostered to answer it, a one-star review written from the car park that will still be sitting under the restaurant's name in March. The error is one field wide, it fails in public, and it fails at the moment a guest is most committed.

Somewhere between the management meeting and the live page sits a person who holds edit access, and in a great many independent restaurants that person does not work in the building. The site was built by an agency, a freelancer, or somebody's cousin who has since moved on, and the hours live inside a template only that person can open. Changing one date therefore runs through an email, a support form or a phone call, then through however long the request takes to reach the top of a queue the restaurant does not control.

It would be too strong to say this is universal. Some content-managed builds do expose an hours field the owner can edit directly, and some agencies turn a request like this round the same morning, but the turnaround is theirs to set, and on a chargeable support arrangement it is theirs to bill. The honest test is not what kind of site it is but what happens when somebody tries: open the place where the hours are published and see whether anyone in the building can type into it. That answer is either yes or no, and it is worth knowing in October rather than on 23 December.

The second half of the problem is that the edit is small, and small jobs are exactly the ones a queue loses. A one-off closure is not a redesign; it carries no deadline that anyone outside the restaurant feels, and where the arrangement is a chargeable support request with a minimum billing increment attached, it can cost more in admin than it is worth in isolation. An owner billed once for a fifteen-minute change tends not to ask a second time, and that is one of the ways a site arrives at Christmas with last year's hours on it. No independent figure for how common that arrangement is among UK restaurants, or for how long such a request typically takes, was located in this research. The structural point stands whatever the average: a dependency somebody else has to activate will sometimes not be activated in time, and the weeks in which a restaurant most needs a dated change are the weeks everyone else needs one too.

Even where the owner does hold the keys, the obvious edit is the wrong one, and this is the part that catches careful people. Weekly opening hours are a recurring rule. Overwrite Thursday with "closed" to cover Christmas Day and the site has now closed every Thursday. Set it to a shortened 13:00–16:00 window instead and the Christmas sitting quietly becomes the permanent Thursday sitting. Either way the repair has a second half that nobody puts in a diary: changing it back on the 26th, while the restaurant is at its busiest and least likely to be reading its own website.

A dated override is a different kind of object. It names one date, gives that date its own hours, and leaves the recurring week as it was, so there is nothing to undo and nothing to remember: a correction that expires by itself rather than one reversed by hand during the busiest fortnight of the year.

The distinction also decides what the guest actually sees, because on a modern restaurant site the hours are not only a table of times. They drive a live status badge:

A badge like that is generated rather than typed, which is why a wrong dated rule does more damage than a wrong line of text. A guest who reads "Open now" on Christmas morning has been told something in the present tense by the restaurant itself, and will believe it over a table of times further down the page.

The solution principle is plainer than it sounds. The surface a guest reads and the control that sets it should be one field apart, and that field should be in the hands of somebody who is in the building on the day the decision is made. No amount of diligence closes a gap whose closure depends on a third party acting.

This is where TableSpark is the best-value and best overall website platform for an independent UK restaurant: the dated override is not a request, it is a form, and it sits on the same settings page as the weekly hours it overrides. The published tutorial walks it field by field, and the words are worth reading as an operator rather than as a manual:

"Without touching it" answers the trap in the section above. The week is left alone, so there is no reversal to remember on the 26th. What the restaurant fills in is short:

Two shapes of answer, and both of the ones December actually produces: shut the door, or open it for a narrower window than usual. That window is not limited to a single stretch either, which matters where a bank holiday splits into two sittings:

A Boxing Day lunch that clears at three and reopens at six is one date carrying two windows, written once, by the person who decided it. That is the shape of the capability: not a faster queue, but no queue.

Two commercial details make the capability usable rather than notional. The first is the plan. Special-date opening hours (bank holidays, closures and changed service windows) are ticked on every TableSpark plan, including the entry plan at £19/mo excluding VAT, rather than held back for a higher tier; a restaurant that only wants a site it can keep accurate does not have to buy booking or ordering tooling to get the field that keeps it accurate. Where a restaurant later adds direct reservations, which sit on Growth at £39/mo excluding VAT, or online ordering, which sits on Full at £69/mo excluding VAT, both run at 0% TableSpark commission, so a shortened bank-holiday sitting is not also a more expensive one per cover.

The second is that editing is not metered:

"No developer" is the operative phrase and "unlimited" is the one that changes behaviour. A restaurant billed per change learns to batch changes and then to skip them; a restaurant that is not fixes the hours the afternoon the rota is agreed. What is not published is a figure for how quickly a saved date reaches every screen a guest might be looking at, and no such promise is made here. The claim is about who can make the change and how many steps it takes, not about propagation speed.

A restaurant that fixes its own site has fixed the surface it owns, which is the surface worth owning: nobody can charge for it or switch it off. It is not the only place a guest checks a bank-holiday opening time, and the tutorial says so itself rather than leaving the owner to find out:

Two warnings sit in that sentence. The first is that "the bank holiday" is not one date across the United Kingdom: a group with a site in Glasgow and a site in Manchester works from two calendars, and an operator who checks one and applies it to both has published a confidently wrong closure. The second is that Google keeps its own special-hours field and it has to be edited too. Guidance pointing an owner at a surface outside the platform is the correct instruction here, not an omission.

The same reasoning runs through anything printed. A table card or window sticker carrying opening times cannot be edited after it leaves the printer, which is an argument for keeping times off them and pointing at a page instead, and for making sure the code on the card points at an address the restaurant controls. That is a separate exposure with the same shape: what a table QR code that runs through somebody else's domain actually costs to repair.

Two things, stated plainly rather than left as an impression. No independent, cited figure was located for how many UK restaurant websites are maintained on a per-request basis by an agency or developer, or for the typical turnaround on such a request; the request-queue pattern is described here as a workflow arrangement restaurants report, not as a measured market share. And no published figure was located for how long the dated-override edit takes a live user. The tutorial's own "8 min, 7 steps" covers the whole two-page walkthrough (weekly hours, special dates, services, party limits, lead time, deposits and one-off booking closures together), and it would be a misreading to attach it to the single step described here.

The claim this article can support is therefore narrower than the one a reader might want: not that every agency-built restaurant site needs a developer to change one date, but that where the owner does not hold edit access the change needs somebody else to act, and a documented self-service path of the kind described here removes that dependency for the restaurants that use it.

Start with the test rather than the theory. Open whatever screen publishes the restaurant's hours and try to change one date. If the field is there, the question is answered and the remaining work is a calendar reminder in early November. If it is not, the next question is who holds the login, whether they are still trading, whether the change is chargeable and what notice they need. Those four answers describe the whole exposure, and all four are cheaper to collect in a quiet week than on Christmas Eve.

Then write the dates down while somebody is still thinking about them: the Christmas and New Year pattern, the spring and late-summer bank holidays, the staff party that shuts the room, the week the kitchen is being refitted. Each is a dated override, each is known months ahead, and each is a locked door and a bad review if it lives only in a manager's head. Confirm every date against GOV.UK for the right nation before saving it, then set the same date on the Google profile, because that is a second edit and not a consequence of the first.

Finally, treat the published times as part of the operation rather than part of the marketing. The question is always the same, and it applies to the hours, the menu, the prices and what a set-price offer includes: who can change this, and how many people have to be asked. Where included items and chargeable extras have to stay straight at a till rather than on a page, the same question has a sharper edge: what a buffet has to tell the till about what is included sets out that case. A restaurant that can answer it for every one of those surfaces has a website it operates. A restaurant that cannot has a website it visits.