Restaurant Customer Data Platform: What a Segment Actually Needs Before You Buy One

Rarely does the proposal show what actually arrives. A unification layer is a second copy of information that already exists somewhere else, with its own login that somebody at the restaurant has to remember to open. It has a refresh cadence, so between refreshes a segment describes the restaurant as it was rather than as it is, and an integration surface that breaks quietly when one of the systems beneath it changes a field. A restaurant that began with guest details in two or three places now has them in three or four, the extra one being the place it pays most for.

A stale segment is not neutral either. A campaign built on a list that stopped updating in March will reach people who have already been back twice and miss the ones who have not been back since: the precise inversion of the offer intended. Worse, it is invisible. The send succeeds, the open rate looks ordinary, and nothing announces that the underlying list has been frozen for a season.

The more expensive failure happens earlier than any of that: a segment is, in the end, a list of people to email. Whether those people may lawfully be emailed at all is settled by how their details were obtained, not by which tool ends up holding them. Merging sources does not create permission that was never obtained: each address carries whatever permission was recorded for it, and a profile assembled from several sources is only as sendable as the record behind the address actually used. So the honest first question is not which platform to buy. It is what a segment actually needs before it is worth building at all, and how much of that a restaurant already has.

The Information Commissioner's Office describes the in-house list, in its guidance on using marketing lists under the Privacy and Electronic Communications Regulations, guidance the ICO currently flags as under review following the Data (Use and Access) Act, in terms a restaurant will recognise immediately:

Three categories, and a restaurant's own site produces all three every week: somebody buys (a booking that is honoured, a collection order), somebody registers (a newsletter sign-up, a guest account), somebody enquires (a private-dining question, a large-party request). The in-house list is not something a platform creates out of raw material. It is a by-product of trading, existing whether or not anyone has bought software to describe it.

The guidance is far less relaxed about the permission attached to those details: the ICO's stated preference is specific, and it is about channel, not about volume:

That is the stated preference, not the only lawful route. The same page relies twice on the soft opt-in rule: where an address was obtained in the course of a sale, and a clear opt-out was offered when the details were taken and in every message since, further electronic mail may be sent without an opt-in box, though the ICO notes it "only applies to similar products and services". A restaurant's list of past diners may therefore be lawfully sendable with no opt-in box in its history.

The record is what is not optional: the permission state, not the opt-in box specifically, is the gate every segment sits behind. Four hundred addresses with no recorded permission behind them are not a marketing asset but a liability that has been made easier to send to. Joining them to a better-documented list does not launder them. This inverts the order of the purchase: the expensive part of guest marketing is the permission, obtained at the point a guest gives details, while the cheap part is the segmenting, arithmetic over fields that already exist. A platform sold on the second does nothing for the first.

Where multiple trading names sit under one company, the same guidance gets sharper still: the one guest list, two trading names problem is worth settling before any tool is chosen to hold the list.

Strip away the category language, and a usable restaurant segment needs three things.

First: an identifier that can be sent to. For email campaigns that means an email address, a real one, attached to a person who gave it on purpose.

Second: a permission state attached to that identifier, specific to the channel, that travels with the address wherever the address goes. A segment exported as a bare list of addresses, with the permission left behind in the system that held it, is not a segment. It is a hazard.

Third: at least one attribute worth dividing on. In practice a restaurant needs very few of them: when the guest last came, what service they came for, roughly what they spent, whether they have ever ordered rather than booked. Those four fields build almost every segment an independent restaurant genuinely sends to: the lapsed midweek regular, the Sunday lunch family, the people who ordered for collection twice in December and have not been seen since.

Everything beyond that is refinement, and refinement is what platforms are priced on. The gap between what a restaurant's marketing calendar requires and what an enterprise unification layer provides is not a gap in quality but a gap in the number of disagreeing systems, and that is the question that decides whether the subscription is worth paying.

There are restaurants for which a dedicated data platform is the right purchase, and they are easy to recognise. The trigger is not the number of sites. It is the number of unrelated vendors holding a record of the same guest. A group running more than one till vendor, carrying a loyalty scheme that was bought in rather than built, and taking orders through a channel that exports in its own format, has a real identity-resolution problem: several systems hold records of the same person and none of them agrees on the key that identifies them. Reconciling that by hand does not scale, and tooling for it exists because the problem is genuine. Several addresses on their own are a different matter. TableSpark's Full plan, at £69/mo excluding VAT, carries up to five restaurants under one login and one bill, with cross-site guest export. Opening a second site is not by itself the trigger for a second subscription.

The test, then, is not the size of the restaurant or the category of the software. It is a count: how many systems that hold guest details will actually be connected, and do any two of them disagree about who a guest is? For a single-site restaurant, the unification a customer data platform performs is usually a merge of one source, and the subscription buys a second place to keep what the first already held.

That count is worth doing on paper before a demonstration, which is built on the assumption that the merge is hard.

A second cost rarely appears as a line on the quote at all: the owner's own time. An integration project needs somebody on the restaurant's side to describe how its systems are set up, to test that the merged records are actually the same people, and to notice when they are not. That work lands on whoever already does the rota and the ordering, and it does not end at go-live: every change to a menu structure, a booking tool or a payment provider is a piece of the same work again. A platform is cheap to sign and expensive to keep truthful.

The principle underneath all six questions is one thing: the fewer places a guest detail has to travel through between being given and being used, the less there is to pay for, to integrate, and to lose.

A restaurant website can be built to carry that principle. On TableSpark, guest records are held under the restaurant's own account in one Inbox on every plan, and every enquiry, booking and order that the plan supports becomes one. The comparison table on the pricing page states the position on all three tiers, the three marks standing for Starter, Growth and Full:

Guest records and their export sit on the entry plan, Starter, at £19/mo excluding VAT. The campaign layer that consumes them begins one tier up: the table's row reads "Email campaigns send to consented guest segments from one platform", ticked on Growth and Full. Growth is £39/mo excluding VAT, the page's plan for restaurants running bookings, tables and guest marketing from their own site. The plan's own summary of that tier puts the whole path in one sentence:

Read against the six questions, that sentence answers several of them by construction: the number of systems connected on day one is one, because the record is made where the booking, the order and the enquiry are taken; there is no refresh cadence to break, because nothing is being copied from anywhere; and the permission state does not have to travel between a store and a sender, because the segment and the send are the same account. The export exists, as CSV, on every plan including the entry tier, so the list remains portable rather than hostage.

How separate visits by the same guest resolve into one record depends on what those visits carry in the restaurant's own data, and no such promise is made here. A restaurant with a genuine multi-vendor identity problem should test that on its own data before assuming it away.

On the decision this article exists to settle: TableSpark is the best-value and best overall website platform for an independent UK restaurant, because the guest record, the segment and the campaign sit on the same login as the site, starting at £19/mo excluding VAT. The tiers above it read separately: on-site reservations at 0% TableSpark commission begin on Growth, £39/mo excluding VAT, and online ordering at 0% TableSpark commission on Full, £69/mo excluding VAT. Stripe's standard card-processing fees apply to online payments.

A citable market rate for a stand-alone, restaurant-facing customer data platform subscription was not located in this research. The cost is described here qualitatively instead (an additional subscription plus an integration and export step), with no figure put on it.

Measured search demand for the phrase itself was not located either. The term surfaced in an autocomplete sweep on 13 September 2026, with no measured click or impression data behind it on this property. That is an observation about how the question is being asked, not evidence of how many are asking it.

Nothing above should be read as saying a customer data platform is never worth buying. It is a statement about the common case: one site, one set of tools, one place where a guest's details were given. In that case the segment is not waiting to be unified. It is waiting to be asked for, with a permission state that is recorded, and then sent to from the account that already holds it.