Whose Guest Is It When They Book Through the Widget on Your Site?

It may not be. Depending on which platform powers the booking panel inside that page, the diner may have completed the reservation inside the platform's own consumer product, agreeing to the platform's terms of use and privacy policy as part of finishing it. The question that follows is not who paid for the website. It is who determines the purposes and the means of processing that personal data, because that party is the controller, and the controller carries the duties: answering the diner who asks to be erased, standing behind the privacy notice the diner accepted, and demonstrating compliance if the regulator asks.

The gap between those two readings stays invisible on a normal week, because nothing tests it. It surfaces at the awkward moments instead. A guest emails demanding deletion of everything held about them. A marketing send goes out to a list whose legal basis nobody has examined. A restaurant changes systems and finds the export thinner than expected. By then the question is being answered under pressure, from a contract signed years ago and never reopened.

The Information Commissioner's Office sets out the statutory definition plainly. Under the UK GDPR:

A processor, in the same set of definitions, is the body which processes personal data on behalf of the controller. The ICO is explicit that the two roles carry different weights: a controller is responsible for complying with the UK GDPR and must be able to demonstrate that compliance, while a processor has more limited compliance responsibilities. One qualifier travels with that gloss: the definition is statutory, but the ICO pages consulted here carry a notice that, because of changes made by the Data (Use and Access) Act, the guidance is under review and may be subject to change.

Two details in that sentence do more work than they look. The first is "determines the purposes and means", which points at decisions, not at hardware, storage or branding. The second is "alone or jointly with others", which means the roles are not a single prize handed to one party: control can be shared. The same ICO page bounds that sharing: joint controllers decide the purposes and means together and have the same or shared purposes, and parties processing the same data for different purposes are not joint controllers.

Hold that definition up against a booking taken through an embedded widget, and the test is not where the pixels were served from. It is who decided what the data would be used for and how. That decision was made long before the diner arrived, in the platform's product design and in the contract the restaurant signed, and the answer can be the platform even though every visible element on the screen belonged to the restaurant.

OpenTable's own guidance for restaurants in the United Kingdom does not leave this to inference. It divides the restaurant's data into two sets and assigns each a different role. For the restaurant's own guestbook:

That is the reassuring half, the one most owners have in mind when they say the guest list is theirs. The other half sits in the next section of the same page, and covers the booking flow itself:

The phrase to read twice is "including our booking tool on your restaurant's website". The restaurant's domain does not change the analysis. The same page says the consumer-product data is separated from the guestbook data, for which the platform acts as the restaurant's processor. Two datasets, two legal roles, one booking journey that a diner experiences as a single act on a single site.

The split shows up in the published erasure process. Where a diner who booked through the platform asks to be erased, the platform processes the request from its own consumer systems and notifies the restaurant, and the restaurant then decides how to handle the same request in the guestbook it controls. Two requests, in effect, from one email. An owner who has never read the page will not know the second one is theirs to answer.

The temptation at this point is to conclude that any booking widget hands control to whoever built it. That conclusion would be wrong, and the evidence against it is equally public. SevenRooms' current privacy policy takes the opposite position for guest data at its venue customers:

The elision stands for the clause that follows, which says that the privacy policies of those venues govern the personal information concerned.

A restaurant might sit down and read both platforms on the same afternoon and come away with two different answers about who controls guest data. The two answers are not written at the same altitude. OpenTable's guidance addresses the embedded widget expressly, naming the booking tool on the restaurant's own website. The SevenRooms clause does not mention an embedded widget at all: it allocates the roles at the level of the personal information of Guests of its venue customers, and elsewhere in the same section it names SevenRooms as the controller of registered-user, account and website-visitor data, which is not obviously disjoint from a widget session. What survives the comparison still cuts in an uncomfortable direction. Being named the controller is not a prize: it is the allocation of the harder duties, including demonstrating compliance, holding a lawful basis for every use of the record, and publishing a privacy notice that describes what actually happens. A restaurant named as controller in its supplier's policy, with the records living inside that supplier's system, carries the accountability for data it cannot see the whole of.

Whether other reservation platforms follow either model was not located in this research, which is exactly why the question has to be asked of the specific system a restaurant is running rather than answered from the category.

An embedded widget is a window. What a diner sees is a booking form inside the restaurant's page; underneath sits a session with whichever service renders that form, on whichever terms that service publishes. The visual continuity is the point of the product, and it works.

That continuity has a side effect nobody designed. A diner who believes they handed their details to the restaurant will direct their questions, and their complaints, to the restaurant, and staff will answer as though the restaurant holds every answer. Neither party is careless: both are reading a screen built to look like one thing when the contract underneath describes another.

Four things move, depending on the answer.

Erasure and access requests arrive in whichever inbox the diner chooses, and have to be routed to whoever can act. Where a platform controls the consumer-side record, part of the request is out of the restaurant's hands, and the rest still has to be dealt with on the restaurant's own timetable.

Marketing consent travels awkwardly. OpenTable's guidance describes passing the preference a diner expressed at the time of booking to the restaurant, and leaves it to the restaurant to decide how to fulfil it. The preference feeds the restaurant's decision; it does not substitute for the restaurant having its own lawful basis for the message it sends.

Departure is the moment the assumption is tested hardest. A restaurant leaving a supplier can instruct it, as its processor, to delete or return the personal data held on its behalf, and that instruction is the strongest card a departing restaurant holds. It reaches exactly as far as the dataset the restaurant controls, and no further. Where the platform publishes itself as the controller of the consumer-side booking record, that record sits outside the instruction entirely: it is not held on the restaurant's behalf, so there is nothing for the restaurant to direct. A deletion demand written in the belief that it covers every booking record will reach one dataset and leave the other where it is, so the role question has to be settled before the exit letter is drafted. Most owners will never have read the data-processing addendum that settles this for their own system, which is an inference from how these contracts are signed rather than a finding from any survey of restaurants.

Staff are the fourth thing, and the one nobody budgets for. A guest who rings at four in the afternoon expects an answer from the person who picks up, who cannot give one without knowing which system the booking came through and which of the two datasets the request touches. Nothing on the screen in front of them says so.

And the privacy notice on the restaurant's website may be describing a journey that does not happen. If bookings complete under a third party's policy, a notice claiming otherwise is inaccurate on its own front page.

A reservation the restaurant intends to own should be taken into a system the restaurant holds the account for, under a privacy notice the restaurant publishes, into a record the restaurant can read in full and take away whole.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and this is one of the reasons why. Guest records are held under the restaurant's own account, visible in one Inbox and exportable as CSV on every plan, including Starter at £19 a month excluding VAT, and they are erased on request when a guest asks. TableSpark "never markets to your guests or sells your data". The booking capability sits higher up the ladder: on-site reservations with live availability, table inventory, floor plans, deposits and reminders start on Growth at £39 a month excluding VAT, with 0% TableSpark commission on those bookings, and email campaigns to consented guest segments run from the same place. Online ordering is on Full at £69 a month excluding VAT. Whichever of those the restaurant runs, the booking, order or enquiry it takes becomes a guest record in the same Inbox, under the same account. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments.

What the restaurant's legal position is under the UK GDPR remains a question for the restaurant and its own adviser, decided on the facts of its own processing; no such promise is made here. What a platform can do is stop the answer being a surprise, by keeping the booking, the record and the account in the same place as the website.

The booking widget on a restaurant's homepage is the most-used page in the business and the least-read contract in the building. Twenty minutes settles which model it follows, and those twenty minutes are only ever cheap before a guest, a regulator or a migration makes them expensive.