Your bookings arrive on an analogue line that is being switched off by January 2027

The direct answer is that this is an inventory problem long before it is a service problem, and it stops being cheap to fix on the evening it surfaces. Nobody can tell you from outside what will survive your migration, because the answer depends on the sockets in your building, the age of the boxes wired into them and the contracts behind each one. The working principle is simple enough to run between services. Walk the building and check the socket, write down everything that terminates on that line, ask your provider which of those items relies on the old network and what your account's migration date actually is, put the same question to each equipment supplier about their own box, and make sure a second route exists for the one flow you cannot afford to lose, which is a guest trying to give you money on a Saturday.

Picture the shift rather than a case study, because this is a scenario and not a customer story. It is a Friday, the room is two thirds full, and somebody notices that the phone has not rung since about six. Unusual, but not alarming, so nobody chases it. At half past eight a walk-in mentions she tried twice on the way over and got an engaged tone both times. Somebody lifts the handset and there is nothing there at all.

Now the shift splits in two. One person is on a mobile hunting for a provider's fault line, everybody else is running service. The bookings meant to arrive that evening have gone somewhere, and you will never know where, because a caller who gets a dead line does not leave a note. They ring the next place on the list. Those are covers lost with no record, no callback number and no complaint to answer. The damage arrives as an absence.

Then somebody tries to take a payment and the terminal by the till will not connect. That is the moment the evening turns from irritating into expensive, because a room of finished tables and no card payments is a queue at the door and a very long conversation with every one of them.

None of that requires anybody to have done something wrong. It requires only that several things you depend on were sharing one old line, and that nobody had ever written down what they were.

The public sources are unusually plain about this. Ofcom's guidance for landline customers states that "BT has taken the decision to retire its PSTN by January 2027". UK government guidance describes the programme as covering "all UK landlines, needing to be fully upgraded by January 2027", and records that "Over two thirds of UK landlines have already been upgraded to VoIP". A separate government page puts the same endpoint slightly differently: "Most customers are expected to have made the switch by the end of January 2027."

Read those three together and two things follow. The first is that the direction is settled: the old analogue network is going, and the replacement is a phone service carried over your broadband connection, which is what VoIP means in practice. The second is that this is not one national morning when every line is switched off at once. It is a migration running provider by provider, customer by customer, and much of it has already happened. Your own date sits inside your provider's plan, not on a poster.

That distinction is the useful part for an owner. You are not waiting on a national deadline. You are waiting on a letter or a call from your own supplier, and the point of the inventory below is to have done it before that arrives.

Most restaurants treat the phone number as a fact about the business rather than as infrastructure with an owner, a contract and a lifespan. It is worth reclassifying. That number is a booking channel, it is printed in places you cannot edit, and it depends on a service that is being switched off.

Two practical consequences follow. The first is that the number appears in far more places than you control. Your own site, yes, but also printed menus, window vinyl, third party listings, old flyers in flat hallways and a map profile somebody set up years ago. Whether your number stays the same through migration is a question for your provider, and if the answer is that it changes, only some of those places can be corrected quickly.

The second is that the one surface you fully control deserves to behave like a live field rather than a printed artefact. If you can update the number on your own website in minutes, without waiting for anyone, a bad morning costs you five minutes rather than a support ticket. That is the same discipline that applies to any inbound route you own, which is why it is worth running the equivalent of a contact form not working checklist on the phone number too: assume it can fail silently, and know in advance how you would prove it still works.

This is the part telecoms sales calls skip, because it is not where the line rental saving lives. Ofcom's wording is direct: "You might also have equipment such as card payment machines, alarms, and monitoring equipment connected to your landline that might not work once you have migrated to a VoIP service." Government guidance lists the affected categories more fully.

Caption: the published wording is that this equipment might not work after migration, not that it will fail. What happens depends on what a given site actually has connected, and providers are migrating customers on staggered schedules rather than all at once. Sources checked 25 August 2026.

Read the table as a prompt for a walk round your own building, not as a prediction about it. A restaurant with a modern card terminal on mobile data and a monitored alarm already on broadband may have nothing to do at all. A site with a lift, an old panel in the office and a terminal that dials out has real coordination in front of it.

Everything above reduces risk on the line. It does not remove the dependency, and a restaurant whose bookings arrive through one channel is exposed to more than this switch: a handset fault, a broadband outage, a service so busy nobody can reach the phone. The stronger position is a second route a guest can use while the phone is unavailable.

A second route only helps if it is genuinely independent and genuinely joined up. Independent means a guest with a phone in their hand can complete it without your line being involved. Joined up means what they submit lands in the same diary your staff already work from, because two systems that both take tables and never talk to each other create the other classic failure, which is two parties given the same table on the busiest night of the month.

It also has to be honest with the guest about what they have just done. A form that quietly collects a request while the guest believes they hold a confirmed table is a complaint waiting at the door, so the difference between a booking request and a confirmation needs to be visible in the wording they see. Get that right and the web route is no poor substitute for the phone. On a night when the line is dead, it is the only channel still bringing covers in.

This is where a restaurant website earns its keep, and continuity is the argument. A web booking route the restaurant owns keeps taking covers on a night the phone line does not, and the published number is a field the owner can correct immediately. Those two sentences answer the two exposures this switch creates: an inbound channel that can go quiet without warning, and a number printed across your own site that may need changing at short notice.

TableSpark puts both under the restaurant's own control rather than a supplier's. Bookings and enquiries arrive in an Inbox held under the restaurant's account, with reminders and deposits on the same route, and table inventory, floor plans and table-assignment workflows behind it, so a web booking lands as a real table rather than a message somebody retypes. The published number sits in site content the owner edits, so correcting it is a change made and live rather than a request raised. Guest records stay under the restaurant's own account, visible in the Inbox and guest list with CSV export.

Weigh this as a continuity purchase rather than a subscription, because that is what the switch turns it into. The line you rent is retired when the company that owns the network decides to retire it, and the booking route you own is retired only when you decide to retire it. TableSpark Starter is £19 per month, Growth is £39 and Full is £69, all three excluding VAT, with Stripe's standard card-processing fees on online payments and 0% TableSpark commission on bookings and orders included in the plans. Set that against one Friday of engaged tones, an evening of covers nobody can trace and a card machine that will not connect, and the arithmetic stops being close. For an independent UK restaurant that wants its own booking channel to outlive the network its phone happens to run on, TableSpark is the best-value and best overall restaurant-website choice available.