One guest list, two trading names: what the ICO says a restaurant group should not assume

From inside the office that sent it, nothing improper has happened. Both rooms belong to the same limited company. There is one guest list, one login and one marketing tool, and her record sits in that list once, with one address on it. The box she ticked in March was, as far as the database is concerned, the company's box. From where she is sitting, a restaurant she has never dealt with has her email address and no explanation of where it came from.

That gap (between what the database knows and what the guest agreed to) is the whole of the problem, and it is an ordinary shape for a small UK group rather than an exotic one. A second site opens under a different name because the first did not suit the new street; a lease is taken over and the previous occupant's trading name is kept for its local following. Two names, one company. The names are held apart deliberately (on the fascia, on the menus, in every word said to a guest) and then put back together in the one place no guest is ever shown, which is the back office the marketing is sent from.

The consequence is not a preference-centre argument. A guest who cannot account for an email does not write to the brand that sent it; she writes to the one she remembers, or she reports it, and the entity she names is the company rather than the fascia. The group has meanwhile spent its second brand's first impression on an unexplained message.

The Information Commissioner's Office publishes guidance on using marketing lists inside its guide to the Privacy and Electronic Communications Regulations, and it sets itself this exact question: can one company use one list for multiple trading names? The answer opens without hedging.

The load-bearing word is assume. The guidance doesn't say a group may never run one list across two names: the paragraph that follows explains how to do precisely that. The assumption is the error, and the assumption is what a shared record quietly encourages: the record carries the guest's address, her allergy note and her booking history, but no memory of which fascia she was standing under when she gave them.

The reason the guidance gives for the rule is one line:

That is a test rather than a sentiment, and it is measured from the guest's side of the counter. What the owner knows about the corporate structure is not the question; what the guest could reasonably have understood herself to be agreeing to is. A group whose marketing depends on the two names feeling like two independent restaurants has, by its own design, made it harder to argue that a guest of one understood she was consenting to the other.

The same guidance also warns that the soft opt-in is a thin rope to hang this on, because the soft opt-in only reaches similar products and services, and a group whose second site is a different kind of restaurant, in a different neighbourhood, at a different price, has made that argument harder for itself rather than easier.

The single guest list is the part of a multi-site platform that earns its place, and for service it is the whole point. A regular who eats at both rooms should be recognised at both; an allergy noted once should not have to be repeated; a booking history that spans the group beats two partial ones. None of that is what the guidance quoted above addresses, because none of it is a marketing send. PECR reaches a good deal further than marketing (the same ICO guide runs on into cookies and similar technologies, security of services, traffic data and location data), but the marketing rules bite at the moment a message goes out, and the trading-names answer is about that moment.

That is not a clean bill of health for the pooled record. Whether one entity may hold two fascias' guests in a single list at all, and what each set of guests was told when their details were taken, is a question for data-protection law (fairness, transparency and purpose limitation under the UK GDPR), which this article does not reach and which nothing located in this research addresses. An owner should not read what follows as clearance to pool two lists and treat the send as the only remaining question.

What the source does support is narrower: the shared send is what produces the June email. The failure is a category error inside the software, where a convenience designed for the host stand is applied unchanged to the campaign tool because both sit behind the same login. A group deciding between platforms, having settled the pooling question separately and on its own data-protection advice, is then asking whether the pooling can be undone at exactly one point (the moment a message goes out) and whether the platform's defaults make that separation the easy path or the awkward one. That distinction runs through the whole of the build-or-buy question for guest data.

Having ruled out the assumption, the ICO sets out how one list across several names can work:

Two recommendations, and they pull in opposite directions. The first is expressly conditional on the group's own choice: if you want to use one list for all your trading names, every name the group might send from should be listed clearly at the point the guest opts in. The second runs the other way and is deliberately asymmetrical: a single objection should be assumed to silence every name in the group unless the guest makes it clear otherwise.

Neither is a command, but together they give a direction of travel. Consent does not travel between brands by default. An objection is assumed to. Separate on the way in; joined on the way out.

What the guidance leaves an owner to decide after that is a design question rather than a legal test, and what follows is the shape this article would insist on, not a specification the ICO has issued. Three parts of it are worth settling before signing anything.

The first is that a group intending to send across names from one list should name every one of them in the sign-up wording at each site, which, for a group that intends to open a third room, means naming a restaurant that doesn't exist yet. The practical resolution is to accept that the opt-in a guest gives at the door of one restaurant belongs to that restaurant, and to build the sending around that fact rather than around the database.

The second is that a send should be addressable to the guests of one name only, not filterable in principle, after an export and a spreadsheet, but addressable as the ordinary way the tool works, because the moment the separated send is the difficult one, somebody under time pressure will do the joined one instead. The segment is where this is decided, which is why what a segment actually needs is a sharper question for a group than how much guest data a platform can hold.

The third is the mirror image: suppression has to travel. An objection recorded under one trading name should be assumed to silence every other name unless the guest says otherwise, which means it has to reach every sending list, and the exception has to be recordable when a guest asks to keep hearing from one of them. That requires the opposite of separation: one place where an objection is known, applying across names otherwise held apart. A group that answers the first two by running two disconnected systems has satisfied the consent half of the guidance and departed from what the opt-out half recommends, and will not find out until a guest who unsubscribed from one brand is emailed by the other.

There is a line above all of this, on the guidance page itself:

It's worth reading carefully, since it is neither an expiry date nor an excuse. Today's wording is the standard the ICO is publishing today, and a group emailing across two trading names this month is doing so against it. What the notice adds is a planning constraint: the platform decision should not rest on an architecture that only works if this paragraph never moves. A setup that can send to the guests of one name, all names, or any combination (and that applies an objection across all of them) survives a tightening and a loosening alike. Whether the trading-names section itself is among the parts under review is not stated on the page; the notice points readers to the ICO's "Plans for new and updated guidance" page for what is being updated and when, and that page was not read in this research.

The principle underneath all four is simple enough to state: guest data should be pooled for service and separable for sending, in one system the owner controls, rather than in two that agree only when somebody remembers to make them.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, and it holds this shape rather than bolting a second tool onto the first. Guest records sit under the restaurant's own account with CSV export on every plan, including Starter at £19 a month excluding VAT, so the list is the restaurant's to inspect and take away from the first day it exists. Email campaigns to consented guest segments begin at Growth, £39 a month excluding VAT. Multi-site operation is the Full plan at £69 a month excluding VAT, described on the pricing page as "Manage up to five restaurant sites under one login and bill", with each restaurant keeping its own menu, hours and bookings, and cross-site guest export alongside it. Bookings and orders taken through the site carry 0% TableSpark commission, with Stripe's standard card-processing fees applying to online payments.

What is not claimed here matters as much as what is. Whether a consent or refusal state is held against a particular sign-up form is a question for the Information Commissioner's Office and the restaurant's own data-protection adviser. No such promise is made here. An owner running two trading names should ask the four questions above of any platform, including this one, and treat a demonstration as the answer rather than a feature list.

No published ICO example or enforcement action about a hospitality group's shared guest list was located in this research. The guidance quoted above is generic to any single entity trading under several names; it was not written with restaurants in mind, and nothing located here shows how a regulator has applied it to one. Whether the Data (Use and Access) Act review will change the trading-names section specifically is not stated on the page and cannot be established before that review concludes.

Two inferences in this article go further than the source does, and both should be named. Whether a group that lists both trading names clearly at the point of opt-in has thereby satisfied the informed-consent test for a guest who did not read the second name carefully is an inference from the guidance's own recommendation rather than a position any decision located in this research has tested. The four-part design set out above goes further still, and is the stronger of the two: it would overclaim to read the guidance as legally requiring a multi-site CRM to separate consent records by trading name in software, when it states an assumption a group should not make and a recommended practice, not an architecture.

None of which changes the operating instruction, which is the least demanding part of the guidance to follow. Do not assume. Send under the name the guest gave her address to, and treat an objection under one name as silencing all of them unless she says otherwise.