The Restaurant CRM System With No Live Feed Goes Stale the Week You Sign It

None of that is a software fault. Everything performs exactly as specified: the booking form takes the booking, the tool accepts the file, the spreadsheet is well formed. The failure is structural, and it starts on the day of signature. What has been bought is a container for guest data with no pipe running into it, and a container with no pipe has to be filled by hand, at whatever interval a busy kitchen can actually sustain. That is never nightly, is optimistically weekly, and in practice is whenever somebody remembers. On every day between uploads, the system bought to be the authoritative view of the guest is the least current view of the guest in the building.

There is no new regulation behind this and no deadline in the diary. Manufacturing one would be dishonest. The urgency comes from the mechanism itself, and the mechanism is the ordinary case rather than the unlucky one: a twelve-month commitment, a manual feed, and a copy of the guest list that is always exactly as old as somebody's last spare twenty minutes. It deserves attention now because the moment to catch it is before signature, and a reader who catches it afterwards is committed to it for a year.

The arithmetic is unkind, and it is worth doing out loud. Suppose the upload genuinely happens every seven days, on a fixed day, without fail. That is a generous assumption in hospitality, where the fixed day is the one that gets eaten by a delivery failure or a staff illness. A booking taken an hour after Thursday's upload waits six days and twenty-three hours before the guest-data tool knows it exists. A booking taken an hour before next Thursday's upload waits one hour. On this arithmetic, a weekly upload means the marketing list is on average three and a half days behind the live one, and at worst just under seven.

Three and a half days is not an abstraction. It is the difference between a guest who dined on Saturday receiving a thank-you message that reads as attentive, and receiving one that reads as automated because it went out on the same schedule as everybody else's. It is the difference between a segment called "visited in the last month" that means what it says, and one that quietly excludes the most recent week of trade, which is to say, it excludes precisely the guests worth contacting. And it is the difference between a phone number corrected once and a phone number corrected in one place only.

The same drift shows up on the menu side of a restaurant's systems, and it is well documented there: a price changed on the till that never reaches the website, a dish description edited on the site that the till has never heard of. The guest record is the same mechanism pointed at a different object. The difference is that a wrong price on a website is visible to anybody who looks, while a guest record four days out of date looks perfectly healthy from the inside. Nothing is red. Nothing errors. The list simply describes a restaurant that stopped trading last Thursday.

It is worth being precise about what is and is not being claimed here. No named product's contract terms or integration behaviour were opened for this article, and no survey was made of which guest-data products offer a live feed and which do not. Whether any particular system on the market reads bookings and orders as they happen was not located in this research. The claim is narrower and firmer: a manual export-and-upload round trip produces a copy whose staleness is determined by upload frequency, and that is the specific thing to test before signing, not a universal fact about every tool sold to restaurants.

The drift stops being a marketing inconvenience and becomes a compliance problem the moment the stale copy is the one that sends the email.

Consider a guest who unsubscribes on Monday, through the link at the foot of a message, against the live booking and enquiry record. The next upload is Thursday. On Wednesday the marketing send goes out of the guest-data tool, from a list uploaded last Thursday, in which that guest is still marked as contactable. The Information Commissioner's Office is clear about what is owed to a person in that position. Its Guide to PECR, which the ICO notes is under review following the Data (Use and Access) Act, puts it plainly, in the section on using marketing lists:

"This list" is the 'do not contact' list the ICO expects to be maintained as soon as somebody objects. A screening pass run against a copy of the list that predates the opt-out is not screening. The guidance attaches the screen to “all your marketing”, and says the entry is made as soon as someone objects. It sets no interval within which a lagging copy is acceptable, and from the recipient's point of view there is no such thing as being a few days unsubscribed.

The problem compounds for an operator running more than one room or more than one name. The ICO addresses that directly:

And on the other side of the same relationship:

Read those two together against a manual upload and the shape of the trap becomes clear. An opt-out given to the wine bar should be assumed to cover the trattoria under the same company, unless the guest makes clear otherwise, in every copy of the list that can send a message. That means an operator maintaining a hand-fed second copy has to propagate it twice, by hand, and remember to do so. The obligation that follows a single opt-in is examined in more detail in one guest list across two trading names; the point here is only that the number of copies of the list is the number of places the propagation can fail.

Note what the ICO does not say: it does not say the record must live in any particular system, or be held by any particular kind of supplier. It says the screening must be against an up-to-date list. A single live record satisfies that by construction. Two records, one of them fed by hand, satisfy it only through discipline, and discipline is the thing a Saturday night removes first.

The question to put to any guest-data system before committing to a term is not "does it import CSV". Everything imports CSV. The question is what happens without a human being in the loop. Five checks, all of them answerable in a demonstration rather than a brochure:

Ask for the feed to be shown, not described. Have somebody take a booking on the live booking system while the screen is shared, then refresh the guest record. Either it is there or it is not. A promised integration on a roadmap is not a feed, and neither is a nightly batch presented as though it were live.

Ask which direction an unsubscribe travels. If a guest unsubscribes from a marketing message, does that state reach the booking and enquiry record, and does an objection recorded on the booking side reach the marketing list? A feed that runs one way leaves the more dangerous of the two gaps open.

Ask what happens on the day nobody uploads. Not whether it can be automated in principle. Ask what the system does in the week the manager is on leave. If the honest answer is "the list goes stale", the term of the agreement is the length of time that answer applies for.

Ask who owns the export. A guest list that can be exported in full, in a standard format, on demand, without a support ticket, is a guest list the restaurant can leave with. One that cannot is a reason the next renewal is not really a decision.

Ask what the second system is actually adding. This is the uncomfortable one, and it belongs before the others rather than after them. If the bookings, the orders and the enquiries already resolve into one guest record on the restaurant's own site, a second system is not adding data. It is adding a copy, a term, and a weekly job for somebody. The build-or-buy version of that question is worked through at length in whether a separate guest-data system is needed at all.

A single principle sits underneath all five checks: the guest record should be a by-product of the transaction, not a separate exercise performed afterwards. If the booking, the order and the enquiry all arrive on the same platform that holds the guest list, there is no upload to forget, no interval to be behind by, and no second copy in which an opt-out can fail to appear. Staleness is not managed here. It is structurally impossible, because there is only one record.

That is the standard against which a restaurant website should be judged, and it is the reason TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, starting at £19/mo excluding VAT, with 0% TableSpark commission on every included booking and order.

Guest records are not a premium tier there. The entry plan, at £19 a month excluding VAT, carries "Enquiries, newsletter sign-ups and guest records" alongside AI menu-to-site setup, a live multilingual and QR-ready menu, managed search readiness and basic analytics. Export sits on every plan: guest records stay under the restaurant's own account with CSV export from Starter upwards, so the plan-coverage half of the portability check in the list above is answered on the cheapest tier rather than negotiated at renewal.

The sending side sits with the service tools, on Growth at £39 a month excluding VAT, and the published description of it reads as a description of a single record rather than two:

One Inbox, and the campaigns reach segments of that same record. There is no upload between the enquiry arriving and the segment being built, because there is no gap for an upload to cross. Growth is also where direct reservations run against the restaurant's own tables and floor plans, at 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments. That is the other half of the same idea: the booking that creates the guest record is taken on the platform that holds it.

Where a particular third-party connection's mechanics have no published surface, no such promise is made here. The claim is about what one platform holds, not about what any other system will accept, and that is exactly the distinction the five checks above are designed to force into the open before a term is agreed rather than after.

A guest-data agreement signed without a live feed is not a bad purchase because of its price. It is a bad purchase because of what it obliges somebody to do every week for a year, and because the obligation stays invisible until a message reaches a guest who asked, days earlier, not to be contacted. The spreadsheet round trip does not appear on the invoice. It appears in a supervisor's twenty minutes, in a segment that quietly excludes last week's trade, and in a screening pass run against a list that was already out of date when it was uploaded.

The check is cheap and it takes one demonstration. Take a booking while somebody watches the guest record. If it appears, the system is a record. If it has to be carried across by hand, it is a copy, and the week it was signed is the week it started drifting away from the restaurant it is meant to describe.