The Booking Feature Switched On At Setup, Never Opened Since

The first month does not settle. The room fills, a head chef leaves, the menu is rewritten, and the diary does what a diary does: it takes bookings. The extras stay exactly where they were put: enabled, configured just far enough to save, never opened again. What does not stay where it was put is the invoice. Each enabled module carries its own monthly line, and that line has no idea whether anyone has logged into it, so a module worked hard at every service and a module untouched since setup are billed identically. The difference never surfaces on a bank statement, because the statement shows one direct debit and that figure barely moves.

This is a quiet failure, which is why it lasts. A wasted £35 is not a crisis in any single month; it becomes one only in aggregate and only in retrospect, once the sum has been leaving the account for so long that it has stopped looking like a decision anyone made. It is also the exact amount that was not spent on the thing the restaurant did want, whether that was a second card reader or a photographer for the new menu.

The mechanic is not hidden. On the one UK reservation platform read for this article it is published, in plain figures, on the public pricing page, it simply does not appear in the place an owner looks, which is the invoice.

ResDiary, a hospitality reservation and table-management system operating in 60 countries, publishes an add-on card on its UK pricing page, the only prices the page carries, since the plan fees themselves are quoted on enquiry. Read today, the card prices each module as a flat monthly figure attached to the module, not to its use. Text messaging is one line on it:

Payment for orders and pre-orders is another, at the higher of the card's two rates:

The card lists nine modules and one bundle across two price bands. Gift Vouchers, ResPhone and Event Manager join Order & Pay at £35 per month each; Group Reservations, POS integration, PMS integration and CRM/Marketing join SMS at £10 per month each; a bundle of Order & Pay with Event Manager is £50 per month. The card's own footnotes then stack more on top of those flat fees: the listed prices are subject to 20% VAT, a surcharge of 1% applies for processing deposits and payments and 3% for gift vouchers, Stripe fees may apply, and SMS and Silverstreet fees apply. The page carries no plan price at all, the invitation is to find out which plan best suits the venue, so these add-on figures are not the whole bill, only the part of it that happens to be printed.

Read the structure rather than the numbers. Not one of those figures is a unit price. None of them is "per message", "per event", "per order" or "per till". They are subscriptions inside a subscription, and the only event that changes what a restaurant pays is a module being added to or removed from the account. Nor does the card offer that as a self-service toggle: it ends with an invitation to enquire about add-ons.

The card is equally explicit about when the money moves, and that timing is what turns an unused module from a mild inefficiency into a standing charge.

In advance, from the date of sign-up, not from the date of first use, the first message sent or the first event booked. The billing clock starts when the module is added during setup, at the moment when the restaurant is least able to judge whether it will use the thing: the diary is empty, and the only honest answer to "will you use SMS reminders?" is that it depends on a service pattern nobody has run yet.

The annual option sharpens the same point. A module prepaid for a year is money already taken, gone before any decision to stop it is even contemplated; whether any of it comes back mid-term is governed by the contract rather than by the pricing page, which states only when the money moves and was the only document read here. Either way, a decision taken in a few minutes during onboarding becomes a decision with a twelve-month tail, which is the opposite of how a restaurant thinks about cost: per cover, per service, per week.

Unopened modules aren't the product of carelessness. Three ordinary things keep them shut.

The first is that most of them need work before they do anything. An events module needs enquiry forms, packages and pricing built into it. A CRM module needs segments and a sending schedule. An SMS module needs message wording, timing rules and a decision about consent. Adding it takes a sentence in a setup conversation; making it earn its line is an afternoon nobody has, and one that never becomes urgent, because the module breaks nothing by sitting there.

The second is that nothing signals the gap. A reservation system tells an owner about a booking, a cancellation and a card decline. It has no reason to send an email saying that the events module has not been opened in eleven months, and none of them do. The absence of use produces no alert. What it produces is an invoice identical to last month's.

The third is who reads the invoice. In most independent restaurants the software bill is reconciled by whoever does the books, and the likeliest reason a steady £10 survives every review is that the reviewing eye is trained on amounts that changed rather than on lines that should never have existed, an explanation this research infers from the billing structure rather than from any study of how restaurants check their invoices.

Take the published card at face value and do the sum the invoice never does. Model a basket of five modules: SMS, POS integration, PMS integration and CRM/Marketing at £10 each, with Event Manager at £35, chosen here to make the arithmetic concrete rather than observed at any restaurant. That is £75 a month before VAT. Over a year it is £900, and £1,080 once the card's stated 20% VAT is added. The footnotes then sit on top of that £1,080 wherever the starred modules are actually used: Stripe fees, SMS and Silverstreet fees, and the 1% and 3% surcharges. It is roughly a service's worth of covers in a small dining room, paid annually, for software nobody has opened.

No published case of a specific restaurant's unused add-on spend, and no survey of how commonly these modules go unopened after setup, was located in this research. What the pricing structure establishes is the mechanism, not its frequency: a flat per-module fee, billed in advance, with no relationship whatsoever between the charge and the use.

What an owner can establish, in an afternoon, is whether it has caught them.

Two related costs are easy to confuse with this one. Deposit-taking is the clearest case: on the card read here it is not a monthly module at all, credit card guarantee and payment sit among the plan's included features, with a percentage surcharge on processing instead, so it is a rate to audit rather than a line to cancel, and the uncomfortable detail underneath it is how long a card authorisation actually holds. The same habit of never opening a settings panel costs far more on the menu than on the invoice, which is the subject of what each week of delay in repricing costs.

This does not need an adviser. It calls for the invoice and the account settings side by side.

Start with the most recent invoice, not the bank statement, and read every line rather than the total. Write down each module's name and its monthly figure. If the invoice shows only a single sum, the itemisation is in the billing section of the account.

Then, for each module on that list, answer one question with a date rather than an opinion: when did someone last open this and do something in it? Not "do we use it", "when". An events module that took a genuine enquiry last month is working. An events module whose last activity was the configuration saved during setup is a subscription to a plan.

Then sort the list into three piles. Working modules stay. For modules nobody has touched since setup, and that nobody can name a service for in the next quarter, the cancellation request goes in today, not after a meeting, because the next charge is already in advance, and on a system where add-ons are added and removed through the provider rather than a settings screen, starting that request early is the only way to stop the next one. The awkward pile is the middle one: modules the restaurant genuinely intends to use but has not built out yet. Those get a date and an owner, and if the date passes twice, they move to the cancelled pile. A module kept on the strength of an intention is paid for with money and justified by optimism.

Finally, check the renewal shape. A module on an annual prepayment has already been paid for the year ahead, and what happens to that money if it is stopped early is a question for the contract rather than the price list, so the renewal date is a diary entry that belongs in the calendar the moment it is identified, and the contract is worth reading before the date arrives rather than after.

The structural fault is not that add-on modules are priced. It is that the price is attached to enabling a module rather than to the work it does, so the restaurant carries the cost of optionality it has not yet used and may never use. A restaurant already runs on that principle everywhere else: nobody buys a year of stock for a dish that might go on the menu in the spring.

The alternative is a plan whose tier already contains the service tools that tier is for, so that using one is a decision about how the restaurant operates rather than a change to the invoice.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and its plans are built that way. A site starts at £19/mo, excluding VAT, on Starter. Bookings and table operations start at £39/mo, excluding VAT, on Growth, and Growth carries on-site reservations against the restaurant's own tables and floor plan with 0% TableSpark commission, live availability and table inventory, deposits and reminders, POS connections through Stripe Terminal card readers, and email campaigns to consented guest segments — inside the plan price rather than as separately metered lines. Direct online ordering is on Full at £69/mo, excluding VAT. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments. A plan only starts when the site is published to its live address, it can be cancelled at any time, and plans change up or down with changes prorated — so a capability that turns out not to suit the room is a plan change, not a twelve-month tail.

What no platform can decide is which of these a particular restaurant should actually be running. Whether deposits suit a room that turns tables twice a night, and whether text reminders fit the way a guest list behaves in that town, are judgements for the restaurant; no such promise is made here. What the billing structure can do is stop charging for the answer before the question has been asked.

The invoice sits in an inbox and the settings panel sits behind a login, and the two have probably never been read on the same evening. Read them together once. Name every line, date every last use, and act on what has no date, then put a reminder in the calendar to do it again in six months, because the next system and the next helpful list of extras work exactly the same way.

A module a restaurant actively chose and actively uses is worth its line. One that was switched on during setup and never opened since is not a feature. It is a standing order.