The Reservations Wars Enter Their Endgame: Operator Decisions Before Q1 2026

A restaurant host stand at dusk, tablet glowing with an unconfirmed reservation queue.

OpenTable's signaled system-of-record stance, the rumored Resy-Tock combination, and the closed DoorDash-SevenRooms deal are forcing operators to pick a primary platform. We map costs, data ownership, and the switching playbook before Q1 2026.

It is 4:42 p.m. on a Tuesday in mid-November and Marcos Tello, the GM of a 140-seat Italian room in the West Loop, has three tabs open on his host-stand iPad. One is OpenTable’s GuestCenter, where his book is 91 percent full for Friday. One is SevenRooms, where his marketing director is pushing a tasting-menu pre-fixe to a CRM segment of 1,840 “VIP repeat” guests. And one is a spreadsheet his ops partner emailed him this morning, titled Q1_PLATFORM_DECISION_v4.xlsx. The last cell, highlighted yellow, reads: “Decide by Dec 15.”

Marcos is not unusual. He is, in fact, the median data point for a question I have heard some version of in roughly forty operator conversations since Labor Day: which reservations platform do we live on in 2026, and what does it cost us to be wrong?

For most of the last decade that question had a soft answer. You could run OpenTable for the inventory and SevenRooms for the CRM and Resy for the cool kids’ menu, paying three middle-four-figure monthly bills, exporting CSVs at month-end, and calling it diversification. That posture is breaking. The three forces breaking it are not new — they have been visible since at least last spring — but they are converging on a Q1 2026 decision window that operators can no longer dodge. My thesis for this piece is blunt: by January, operators with more than one full-service room need to declare a primary reservations platform and reorganize the rest of their stack around that declaration. Multi-platform fence-sitting, the default posture of 2022 through mid-2025, is about to get expensive in ways that don’t show up on the invoice.

This piece walks the three forcing functions, prices the switching cost honestly, and gives you the playbook I have watched two regional groups already run. A caveat up front: one of the three forcing functions — OpenTable’s reported move toward a “system of record” posture for April 2026 — is, as of this writing, not something I can pin to a public, named OpenTable announcement. I have heard it from four operators and two consultants who say they have seen versions of the same partner deck. I will flag every claim about it accordingly. If you are reading this in March and the policy looks different from what I describe, mark me down — but the directional pressure is real either way.

The three forcing functions

Let me lay out the landscape as it actually looks on November 18, 2025, because the press cycle has gotten loose with the dates.

OpenTable is the volume incumbent and is leaning into it. OpenTable’s footprint, by Booking Holdings’ most recent disclosures and the company’s own marketing copy, is roughly 60,000 venues globally — call it the largest single bookable inventory in the casual-to-upscale segment in North America. On November 18, OpenTable published its 2026 trends release, which headlines U.S. dining traffic up roughly eight percent year-over-year and a string of softer behavioral claims (more group bookings, more late-night dayparting, a return of weeknight occasions). Whatever you think of trend-release methodology — and I think most of it less than the operators do — the eight-percent number is the one that matters. It is the basis on which OpenTable is, per multiple operator accounts, telling enterprise customers that the platform is the demand-generation engine and that the relationship needs to be reflected in how operators treat the platform’s record of the reservation. I will return to this.

SevenRooms is now part of DoorDash. The acquisition, valued at $1.2 billion and announced in May, closed on June 13, 2025, per DoorDash’s confirmation reported by Entrepreneur. The strategic logic was always obvious: DoorDash had the off-premise demand and a payments rail; SevenRooms had the on-premise CRM that DoorDash had failed to build twice; together, the bet is that a single platform can own the guest from the in-app reservation impulse through the dine-in service through the post-meal remarketing. The integration is, as of mid-November, mid-rollout. SevenRooms-native operators are starting to see DoorDash demand surface inside their reservation grids; DoorDash power users in major metros are starting to see SevenRooms-powered booking flows inside the DoorDash app. The SevenRooms press page is the cleanest single source for tracking integration milestones, though most of the consequential changes are showing up in product, not press releases. I covered the deal mechanics when it closed and will revisit them in an upcoming Bottom Line; for our purposes here, what matters is that SevenRooms is no longer a neutral CRM. It is the on-premise arm of a delivery aggregator.

Resy and Tock are widely rumored to be combining. I want to be careful here. As of November 18 there is no announcement. There are persistent reports — and I have heard versions of them from three separate banker contacts — that American Express, which owns Resy, has been in advanced conversations with Squarespace, which owns Tock, about a structure that would put roughly 25,000 venues across the two books under one roof. The combined platform, if it materializes, would skew heavily upscale-and-experiential: Resy’s urban tasting-menu and bar inventory plus Tock’s prepaid-experience tail. I will treat this as anticipated rather than confirmed, and I will note where my advice changes if the deal does or doesn’t happen. I have written more about the Resy/Amex side of this elsewhere — see an upcoming spring piece.

Three platforms, three different theories of what a reservations system is for. OpenTable thinks it is a demand engine and wants record-of-truth status to match. DoorDash thinks SevenRooms is the CRM that closes its delivery-to-dine-in loop. Amex thinks Resy is a premium membership benefit that happens to seat tables. Operators thought they could split the difference. They can’t, much longer.

Why the “system of record” question matters more than the cover fee

The OpenTable cover fee — the per-seated-guest charge OpenTable levies on bookings sourced through its network — has been the headline operator grievance for fifteen years. It is also, I increasingly think, a misdirection. The cover fee is a price you can model. You know what an OpenTable cover costs (somewhere between $1 and $2.50 plus the per-seat dot, depending on tier and channel), you know what your house cover from a direct widget costs (effectively nothing once the widget is paid for), and you can run the arithmetic on what share of OT-sourced demand is incremental versus cannibalized from your direct channels. Most operators I know have done this math and concluded that OT delivers somewhere between 30 and 55 percent incremental cover, which makes the fee defensible if grudgingly so.

The thing that is harder to model — and the thing that has been moving quietly under operators’ feet for the past two years — is who owns the reservation as a record. When a guest books your table through OpenTable, OpenTable holds the canonical version of that booking. When the guest no-shows, OpenTable’s no-show flag is the one that follows them across the network. When the guest opts in to marketing at the time of booking, OpenTable owns the opt-in. When you want to push a pre-shift note about the guest’s allergies to your service team, you are pushing data that is, in a meaningful legal and technical sense, OpenTable’s first and yours second.

This was a tolerable arrangement when OpenTable was content to be the booking layer and let SevenRooms or Tripleseat or your in-house CRM be the guest layer. Per multiple operator accounts I’ve heard since late summer, that posture is changing. The line operators are reporting from OT enterprise reps — and again, I want to flag that I have not seen a public OpenTable announcement of this — is that the platform is moving toward what one COO described to me as a “system of record” stance: if your reservation originated on OpenTable, OpenTable expects to be the authoritative source for that reservation’s lifecycle, including modifications, no-show flags, and the guest profile attached to it. The mechanism, as I understand the partner-deck version, would be some combination of API restrictions on outbound profile sync to competing CRMs and a default contractual posture that elevates OT’s data rights. The effective date I keep hearing is mid-April 2026. I cannot independently confirm any of this from a public OpenTable source as of November 18. If the policy exists, OpenTable has not, to my knowledge, posted it on a public-facing channel. Take everything in this paragraph with that caveat — but take it seriously, because the operators relaying it are not the kind to make things up.

If a policy of this shape lands, the implication for an operator running OpenTable for bookings and SevenRooms (now DoorDash-owned) for CRM is straightforward and uncomfortable: you are paying two platforms to fight each other over your guest data, and one of them is starting to win. The natural operator response — fold the CRM back into OpenTable’s GuestCenter — is exactly what OpenTable has been investing in product-wise for the last eighteen months. The unnatural but increasingly logical response, which I have heard floated by two enterprise groups, is to move primary inventory off OpenTable entirely and accept the demand-generation hit. Neither response is cheap.

The DoorDash question, asked honestly

I want to spend a beat on the SevenRooms acquisition because it is the easiest of the three forces to get wrong.

The lazy version of the analysis says: DoorDash bought SevenRooms to bolt on a reservations layer; now SevenRooms operators get free DoorDash demand; the integration is a tailwind. The more careful version, which I have arrived at after a half-dozen conversations with operators in the first cohort of integrated tests, is more mixed.

What is genuinely good for SevenRooms-primary operators: the DoorDash app is now surfacing book-a-table CTAs against the same restaurants where DoorDash delivers, and the early data suggests a non-trivial lift in weeknight covers at the affordable-casual end of SevenRooms’ book. A 80-seat neighborhood Mexican spot in Austin that I have been tracking since August reports roughly 14 percent of November Monday-through-Wednesday covers now arriving via DoorDash-sourced reservations. That is meaningful. It is also, if you look at the per-cover economics with the DoorDash take rate honestly priced in, somewhere between break-even and modestly accretive depending on how you treat the labor cost on a weeknight that would otherwise have been slow.

What is more complicated: the integration is starting to drag SevenRooms in directions that look less like the operator-friendly CRM it has been and more like a demand-side platform priced and structured to extract from operators the way DoorDash’s delivery business does. I am not predicting a price hike; I have no reason to think one is imminent. I am predicting — and this is firmly an interpretation rather than a reported fact — that the strategic gravity of being owned by DoorDash will, over the next 18 to 24 months, pull SevenRooms toward demand-aggregator economics and away from pure SaaS-CRM economics. Operators who chose SevenRooms in 2023 because it was the one platform that wasn’t trying to be the demand layer are going to have to renew that choice in 2026 with the demand-layer reality fully visible.

For comparative ground here, I dug into the SevenRooms-versus-Tablecheck question in a forthcoming May Pass piece; the upshot, briefly, is that Tablecheck remains a genuinely operator-aligned CRM in markets where it has scale, but it does not have the demand-generation network to be a primary platform for most North American operators.

The Resy-Tock scenario, planned for both ways

If the rumored Resy-Tock combination happens, the resulting platform looks meaningfully different from either of its parents.

Resy alone is a tightish urban book — strong in NYC, LA, Miami, Chicago, weaker outside the top ten metros — that derives much of its operator appeal from the Amex Platinum/Centurion integration on the guest side. The reservation isn’t the product; the membership benefit attached to the reservation is. Tock, born out of Nick Kokonas’s frustration with deposit-handling on Alinea-grade tasting menus, is structurally different: it is a prepaid-experience platform first, a reservation platform second, and it skews to the long tail of tasting menus, chef-counter formats, wine experiences, and pop-ups.

Combined, the platform would have roughly 25,000 venues — a number worth caveating, because both sides count venues differently and the public figures don’t always reconcile — and a coherent positioning as the upscale-and-experiential alternative to OpenTable’s broad mid-market book. Crucially, neither parent has tried to be a CRM in the way SevenRooms has. A combined Resy-Tock would, at least on day one, be a booking-and-deposits platform that plays nicely with whatever CRM the operator chooses.

For operators in the upscale-and-experiential band — tasting menus, chef counters, wine bars with reservations, hotel rooftops, special-occasion rooms — a Resy-Tock combination is plausibly the most aligned platform on the board, if it happens and if the post-deal product roadmap respects what works about both parents (Resy’s polish on the host-stand UX, Tock’s hard-nosed deposit and cancellation enforcement). Both of those ifs are real. Amex has been an attentive but somewhat hands-off owner of Resy; Squarespace’s stewardship of Tock has been competent but quiet. A combined entity is going to have to integrate two distinct codebases and two distinct cultures, and the early operator instinct will reasonably be to wait and see.

If the deal doesn’t happen, Resy remains a strong secondary option for urban upscale rooms and a weak option for everyone else, and Tock remains the right answer for prepaid-experience formats and a niche answer otherwise. I will revisit the OpenTable-and-Booking ecosystem question in a forthcoming May piece for the broader competitive frame.

What it actually costs to switch primary platforms

The reason operators have not declared primary platforms is that switching is expensive in ways the platforms themselves understandably do not advertise. Let me price it honestly.

Direct platform costs are the smallest line. Moving from OpenTable’s mid-tier plan to SevenRooms-as-primary, for a typical 120-seat full-service room, is roughly a wash on monthly subscription — somewhere in the $400-to-$900-a-month range either way, depending on add-ons. You save on per-cover fees if you can shift OT-sourced demand to your direct channels, but you almost never recover all of it; figure on losing 15 to 30 percent of your incremental OT covers in the first six months, which for a 120-seat room doing 1,800 OT-sourced covers a month is roughly $9,000 to $18,000 in lost incremental revenue per quarter against the per-cover fee savings. The arithmetic is room-specific and dependent on what share of your book OT was driving — for some operators in dense urban cores this calculation tips strongly toward staying on OT for the demand alone.

The backend rework is the line that gets you. Every operator I know who has switched primary platforms in the last three years tells me the same thing: budget twice what the platform’s professional services team tells you, and double that if you have a multi-room operation with shared CRM or loyalty infrastructure. One West Coast group I have been tracking off-the-record put the all-in cost of moving five rooms from OpenTable-primary to SevenRooms-primary at roughly $180,000, of which only about $30,000 was platform fees and migration tooling — the rest was internal engineering hours, retraining 11 GMs and 60-odd front-of-house leads, rebuilding three POS integrations, and roughly six weeks of degraded service quality while the new flow stabilized. I have heard credible secondhand accounts of larger groups — at the celebrity-chef-collection scale — quoting backend rework costs in the high six figures for a full primary-platform switch, and the Wolfgang Puck organization has been mentioned to me in this context, though I do not have a directly sourceable quote I can put a name to here and so I will not.

The guest-data cost is the line nobody prices in advance. When you move primary platforms, you lose the connective tissue between your accumulated guest history and your forward booking flow. Tags don’t map cleanly. Visit counts reset or get approximated. The “guest spends $400 a head and prefers the north banquette” note that your service director carefully maintained in SevenRooms over four years does not show up in OpenTable’s GuestCenter in the same form, even if you do a clean export-and-import. For a special-occasion room that runs on relationship recognition, this cost is enormous and the platforms cannot honestly mitigate it for you. The operators who have switched best have done so by accepting that the first six months on the new platform are a relationship-rebuilding exercise as well as a technology one.

Net of all of this: a primary-platform switch for a single full-service room is a $20,000-to-$50,000 project. For a five-room group, $150,000 to $300,000. For an enterprise collection, mid-six-figures into the low millions. Those are the numbers you should be planning around, not the numbers in the platform sales decks.

The playbook two groups are already running

In the last six weeks I have watched two regional groups — both unwilling to be named, both at the 6-to-12-room scale — work through versions of the same decision. The playbook that emerged is consistent enough that I think it generalizes. Five steps.

One. Audit your demand mix room by room, not at the group level. The single biggest mistake I see is operators making a primary-platform decision on aggregated group-level data when the rooms have wildly different demand profiles. The downtown power-lunch room may be 70 percent OT-sourced; the neighborhood weeknight room may be 15 percent OT and 50 percent direct-from-Instagram. The right primary for those two rooms may not be the same, and the group has to decide whether the cost of running two stacks exceeds the cost of forcing one room onto the wrong primary. Both groups I tracked ended up with two stacks, not one.

Two. Price the guest-data continuity question seriously. The right answer here is not “we’ll export everything to a CSV” — the right answer is to build a thin internal data layer that holds your canonical guest record regardless of which booking platform sources the reservation. Both groups I tracked ended up investing in lightweight middleware — one built it themselves on a low-code stack, the other paid a consultancy roughly $40,000 to scope and build — that pulled bookings from whichever primary they chose, normalized them, and pushed them into a single guest profile they owned. This is the most important architectural decision in the entire stack, and it is the one operators most consistently skip.

Three. Negotiate the platform contract from a credible position of optionality. If you arrive at OpenTable renewal having visibly invested in the option to leave — middleware, parallel widget infrastructure, a clear migration plan — you get a meaningfully different conversation than if you arrive having done nothing. Both groups I tracked used the threat-of-leaving conversation to renegotiate OT terms; one stayed on OT-primary on materially better economics, the other left. Either outcome is fine. The position of optionality is what mattered.

Four. Set a cutover date with sixty days of overlap. Both groups ran their old and new platforms in parallel for roughly two months, during which the host stands took both books and the engineering team reconciled discrepancies daily. This is the line on the budget that the platforms’ professional services teams most consistently under-quote; it is also the line that distinguishes a switch that lands cleanly from one that loses you eight weeks of margin to operational chaos.

Five. Lock the CRM decision separately from the booking decision. This is the single most important takeaway. Operators have been conditioned to think of reservations and CRM as a stack — and the platforms have actively encouraged that conditioning. They are not the same product. A coherent stack in 2026 is more likely to look like one primary booking platform plus one CRM that is deliberately not the booking platform’s native CRM, glued together by the middleware I described in step two. Both groups I tracked ended up here. One runs OpenTable for bookings and a non-SevenRooms CRM for guest data; the other runs SevenRooms for bookings and CRM but maintains an independent guest-data warehouse outside the SevenRooms environment so that they retain leverage if the DoorDash-era SevenRooms product roadmap drifts.

What I would do before December 15

If I were Marcos at his host stand with a December 15 deadline, here is the order I would work through.

I would first separate the booking decision from the CRM decision, on paper, and price each independently. I would not let the platforms’ bundled pitches obscure that I am making two distinct architectural choices.

I would then audit my demand mix, room by room. If I am a single-room operator in a major metro running 50-plus percent OT-sourced covers, OT-primary in 2026 is probably still right, with the caveat that I am going to be living with whatever “system of record” posture OpenTable announces in the spring — and I should be reading every operator email from OT between now and April 16 with care. If I am a tasting-menu room or a chef-counter format, I would lean toward Tock today and let the Resy-Tock combination shake out before committing further. If I am a neighborhood weeknight room with a strong direct channel and modest OT dependence, I would seriously consider going SevenRooms-primary, eyes open, with explicit guest-data optionality built into my stack.

Across all of those branches, I would invest the $20,000 to $60,000 in middleware and guest-data infrastructure that gives me the option to switch in 2027 without redoing this exercise from scratch. The platforms are consolidating; the way an operator stays sovereign is by owning the layer below the platforms, not by picking the right platform.

And I would put a calendar reminder for April 15, 2026, with three items: confirm OpenTable’s actual policy posture once it is public, watch the Resy-Tock M&A flag, and check in on SevenRooms-DoorDash integration drift. Those three pieces of news will either validate my December decision or tell me to revisit it.

The reservations wars are not ending. They are entering the phase where the platforms stop pretending to be neutral infrastructure and start acting like what they have been all along: aggregators with their own demand books, their own guest data, and their own strategic interests, none of which automatically align with mine. Operators who treat the platforms as utilities are about to get a lesson in why they aren’t. The operators who declare a primary and build the middleware to stay sovereign below it are going to be fine. The fence-sitters are going to spend Q1 on the phone with three account reps and end the quarter with less leverage than they started.

It’s not a fun decision. It’s the decision in front of you. I would make it before December 15.

— Priya covers operators for TableTransfers. Tips: [email protected].

Featured More

The Voice Agent Maturity Curve

mise

·

12 min read

The Four Margins of a Restaurant

mise

·

14 min read

The AI Premium in Hospitality M&A: Broker Story or Real Number?

the bottom line

·

9 min read

What the DoorDash/SevenRooms Deal Actually Buys

the bottom line

·

11 min read

Browse all 494 posts

Related posts

Darden's quiet AI strategy is buy-vs-build done right

the operator

·

19 min read

Darden's quiet AI strategy is buy-vs-build done right

Sweetgreen's Infinite Kitchen, in Public View: A Case Study

the operator

·

15 min read

Sweetgreen's Infinite Kitchen, in Public View: A Case Study

Sweetgreen's plan after selling the robot — the Sweet Growth Transformation reset

the operator

·

19 min read

Sweetgreen's plan after selling the robot — the Sweet Growth Transformation reset