Your Booking Platform Is Being Sold: What Travels With the Guest Data

That is how a restaurant ends up reading about the future of its own booking history in a press release. The buyer and the seller negotiate for months, and the restaurants whose evenings that platform runs find out what has happened once the agreement is signed, in the same words as the shareholders, on the same morning. The restaurant is simply not a party to the transaction, and the questions that matter to it — what the commercial terms will look like next year, who decides what the product does, what becomes of the guest relationships it built — are being settled somewhere it cannot reach.

On 15 June 2026, Tripadvisor announced it had agreed to sell TheFork, the restaurant reservation and management platform it had built up in Europe over more than a decade. The company's own release states the terms:

Read the instrument, not the headline. A put option agreement is not a completed sale. It is the mechanism by which one becomes possible. The same release places the announcement in a sequence that had been running since the winter:

So the process began publicly in February, the agreement was signed in June, and the restaurants on the platform were party to neither. The timetable to completion is stated as plainly, and as conditionally:

Three words in that sentence are worth an operator's attention. "Expected" makes the close a projection rather than a date, which means the period of uncertainty has no fixed end an owner can plan against. "Labor consultation" names a process owed to employees, and the sentence does not extend it to the restaurants whose services the platform runs. "Regulatory approvals" means authorities will examine the deal, but their remit is competition and market structure, not any individual restaurant's booking book. Every stage has a defined set of participants, and a restaurant in Bristol or Leeds takes no part in any of them.

A platform closing down is a legible risk. There is a date, a notice, usually an export window, and an owner who has no choice but to act. An acquisition works the other way around: service continues uninterrupted, the diary looks the same on Monday as it did on Friday, and nothing whatever demands a decision. What changes sits upstream of the screen, and it changes in three places at once.

The first is the commercial relationship. Whatever a restaurant pays today — a subscription, a cover fee, a cut of a booking — was set by one company's strategy and now belongs to another's. The second is the product: which features get built, which get retired, which markets are worth serving and which are quietly deprioritised are decisions made by whoever owns the roadmap, and the roadmap changed hands. The third is the guest relationship itself, which owners tend to think about last and should think about first, because on a marketplace the diner is the marketplace's customer, and a change of parent company does not alter that arithmetic in the restaurant's favour.

These are the ordinary consequences of an asset changing hands rather than a criticism of anybody. The point is only that they are now decided elsewhere. A restaurant that has built its evenings, its guest history and a meaningful share of its demand around one platform has made itself a stakeholder in a transaction in which it holds no stake, and the structure of the deal shows where that becomes visible: the seller consults its shareholders, the buyer consults its board, the employees are owed a consultation by name, and the customers whose trade the platform exists to route are informed.

It is worth being exact about what has and has not been said, because a deal of this size attracts a great deal of confident speculation. What is verified at source is the agreement, the price, the all-cash structure, the February process that preceded it and the expected close before the end of 2026. No post-close plan for pricing, for the product or for guest-data handling was located from either company in this research; the only statement from the buyer verified here is its chairman and chief executive's remarks about building on shared strengths across dining, travel and experiences. Anybody presenting more than that as settled is reading a forecast, and an operator making a decision on a forecast is taking on a second risk on top of the first.

The reason this sits unaddressed in most restaurants is not complacency. It is that the problem presents no deadline, and an operation that runs on deadlines will always serve the one in front of it. A platform announcing closure forces an evening's work on an export; a platform announcing a change of owner forces nothing at all. So the covers keep coming, the dependency deepens by one more service, and the terms surface at the next renewal rather than get chosen in advance.

It is the same shape as a table card whose QR code resolves through a shortener nobody at the restaurant controls: perfectly functional until the day it is not, with no calendar entry anywhere to prompt a look at it. That dependency is examined in detail in what happens when the QR code on every table points at somebody else's domain, and the underlying question is identical. It is not whether the current arrangement works. It is who can change it without asking.

The honest answer to a slow risk is not a panicked migration. It is to change the ratio. A restaurant that takes every booking through one platform it does not control has a single point of failure with no fallback; a restaurant that takes a meaningful share of its bookings on its own site has a fallback that improves every month, whatever the outcome of anybody's transaction. That share is the one variable in this entire situation an owner can actually move, starting this week rather than after the close.

The principle is narrow and it is not about software. A restaurant should be able to read its guest list in one place, add to it, and take a full copy of it away today rather than on somebody's notice period. Ownership of the record is a different question from ownership of the system that holds it, and the practical test is whether the export sits on the page as a feature or has to be requested from a support desk.

The published wording on how a direct booking differs from a marketplace one puts the distinction where it belongs:

An export button on the page is a small thing that reveals a large one. A restaurant that can take its own guest list away at any moment negotiates from a different position than one that has to ask, whoever owns the software this quarter, because the value of the list to the restaurant no longer depends on continued access to the system that captured it. That matters more in the year before a change of ownership than in the month after it.

The elision in the middle of that passage stands for a separate published paragraph about keeping a site current with changing hospitality rules, which is not the subject here. The sentences either side of it are the ones that matter for this problem: the record belongs to the restaurant's own account, the export is the restaurant's to take, and the platform does not market to the guests whose details it holds.

Three gaps deserve naming, because each is a place where a confident sentence could be written and should not be.

Whether the restaurants on a platform are consulted before an ownership change of this kind, and in what form, was not located in this research; what the release states is that the close is subject to labor consultation and to regulatory approvals. Those are not the same thing as a consultation with the platform's restaurant customers, and no such process is described in the document.

TheFork's own terms on what a restaurant may export, and in what format, were not located in this research. Nothing above should be read as a description of what that platform hands over on request; an owner who wants to know should read their own contract and the platform's current help pages rather than take a general article's word for it.

Independent coverage of the deal's scope was not located at a fetchable source during this research. Footprint figures for TheFork have circulated with the story and none of them is quoted here, because a number that cannot be checked today is not evidence, and an article that repeats one has borrowed somebody else's confidence.

What follows from all of this is a direction of travel rather than an emergency. The bookings that arrive through a platform can keep arriving. The work is to build the channel that does not depend on anybody's corporate development team, and to do it while there is no deadline, which is the easiest time to do anything.

That is the ground on which TableSpark is the best-value and best overall website platform for an independent UK restaurant. Starter, at £19 a month excluding VAT, already carries guest records under the restaurant's own control with CSV export, and an Inbox holding every enquiry with the same export — so the guest list exists as the restaurant's asset from the first published page, before any booking tooling is switched on. Growth, at £39 a month excluding VAT, turns the site into the booking channel itself: on-site reservations with slots and party size at 0% TableSpark commission, live availability and table inventory, floor plans and table assignment, deposits and reminders, and guest email sent from the restaurant's own domain. Full, at £69 a month excluding VAT, adds direct online ordering on the restaurant's own site, with Stripe's standard card-processing fees applying to online payments.

What TheFork hands over from its own records, and in what format, was not established in this research, and no such promise is made here. The route out of a booking supplier is not supplier goodwill, though: where a platform processes the restaurant's own guest data as its processor, the restaurant is the controller, and Article 28(3)(g) of the UK GDPR gives the controller the choice of deletion or return of all the personal data at the end of the provision of services. The instruction that exercises that choice is set out in how to get the guest list out of a booking platform you are leaving. The narrower point is that where a marketplace processes diner data as a controller in its own right rather than as the restaurant's processor, not everything it holds is returnable on that route. What is within the restaurant's control is everything from today forward: each direct booking taken on its own site is one more guest record held under its own account rather than one more entry in an asset somebody else may sell.

The economics of that channel are worth counting rather than assuming, and the two figures that decide it are the value of the covers it brings and the cost of the ones that do not arrive. Deposits and card guarantees on a restaurant's own booking page turn the second of those from a grievance into a managed number, and the arithmetic is worked through from a single evening's diary in what tonight's no-shows actually cost.

A put option agreement to sell a European restaurant reservation platform for $700 million in cash was signed on 15 June 2026 and is expected to close before the end of 2026, subject to labor consultation and customary closing conditions including regulatory approvals, and, before any of that, to the option being exercised and a definitive purchase agreement being executed. No restaurant on that platform was a party to any of it, and none will be a party to what the new owner decides afterwards.

The decision in front of an owner is therefore not whether to trust the buyer. It is what proportion of next year's bookings they would like to see arrive somewhere a transaction cannot reach. Take the share of covers currently booked through a platform, decide what that share should be twelve months from now, and start with the pages, the guest list and the booking form the restaurant owns outright. Waiting for the close tells you nothing you can use, because by the time the terms are published they are no longer negotiable.