No. Front has no native, purpose-built integration with OpenTable, and the available workarounds still cannot check availability or create a booking inside the conversation. Front is a collaborative shared inbox and customer-operations platform. OpenTable is the front-of-house diary and the consumer reservation network that fills covers, used by everyone from independents to large groups. Front handles the message well. It has no idea what a table is.
The short answer
Front can receive an OpenTable enquiry as a conversation. It cannot do anything with it in OpenTable. Checking the diary, holding a table, seating a large party, adding a note to the reservation: all of that still happens by hand, in OpenTable, by a person.
Front + OpenTable | |
|---|---|
Native integration | None |
Best available workaround | A Zapier or custom-API bridge that copies enquiry text into a conversation |
What the workaround still can't do | Check availability, create or amend a reservation, seat a party, read the guest's dining history |
Front is not short of integrations. Its App Store carries more than 160, across channels and messaging, voice, CRM and e-commerce, project management, knowledge, productivity, and dedicated categories for logistics and maritime and for travel. Front does build vertical integrations. It has just never built one for hospitality.
What actually happens to a booking enquiry
Front's strengths make the gap more obvious, not less. It is genuinely good at the inbox part: shared visibility, assignment, internal comments beside the message, SLA rules and response-time reporting. A group running bookings through Front has fixed accountability. It has not fixed booking.
Here is the real journey of one enquiry when Front and OpenTable do not talk to each other.
An enquiry arrives from a guest who found the restaurant on OpenTable, asking whether 12 people can come for Sunday roast, whether that needs a set menu, and whether there is space for a buggy. The message lands in the shared inbox as a Front conversation.
An agent picks it up and reads it.
The agent opens OpenTable in another tab, because Front cannot see the diary.
They check Sunday for 12, work out whether that is one table or two, look at what the kitchen can take at that sitting, and check where a buggy can go without blocking a service route.
They create the reservation in OpenTable, re-keying the name, date, time, party size and the buggy and menu notes from the email.
They switch back to Front and write the reply.
They archive the conversation.
The guest replies: "Two more have said yes, so 14, and can we push to 1.30pm?" Fourteen changes the table plan and 1.30 may be a different turn. The agent repeats steps 3 to 7.
Every enquiry is handled twice, in two systems, by a person copying the same fields between screens. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing," because the work happened in tabs and conversations that no report could see. Front will tell you response times to the minute. It cannot tell you how many of those responses became covers.
The sharper cost is the enquiry you never hear about again. A guest who found you through the OpenTable network has a page of alternatives in the same postcode, so a slow reply is not a delay, it is a lost Sunday table. A roughly 40-venue entertainment group lost a single booking worth £40,000 because the enquiry arrived outside working hours and nobody replied in time. A three-site pizza group put it more bluntly about a 30 to 40 cover enquiry: "It just sat there. No one saw it. They went somewhere else." Front did not cause those losses. Routing bookings through a system that cannot book anything is what makes the delay inevitable.
What Front actually connects to
Front is the most interesting case in this comparison, because it cannot be accused of ignoring verticals. Its App Store has dedicated categories for logistics and maritime and for travel, built for a customer base in freight forwarding, shipping and travel operations. Front is entirely willing to build deep, industry-specific connections. It has chosen freight over hospitality. Search the App Store for OpenTable and you will find nothing.
The realistic workaround is Zapier, and Front supports it properly, with a caveat worth knowing up front: Front's Zapier integration can only reach shared inboxes, because the OAuth token is scoped that way. Enquiries sitting in an individual mailbox need a Front API token and Webhooks by Zapier instead. OpenTable is on Zapier too, so the zap is buildable, and OpenTable's deeper API access is partner-gated.
Then look at what you have built. An enquiry can raise a Front conversation, and an OpenTable event can post an update into one. That is notification, one-directional, treating a reservation request as a message. It does not let the agent see the diary, hold a table, create the reservation, or read what the guest ordered last time. Front AI is a capable suite: Copilot drafts and answers from past conversations, help content and connected systems, Autopilot resolves routine requests, and Smart QA and Topics analyse the queue. It is all grounded in conversations and knowledge, with no line into a reservation system. Copilot can write a lovely reply about Sunday roast. It cannot see whether Sunday has a table for 12.
Why this matters for booking enquiries
A support conversation and a booking enquiry look similar and behave nothing alike. A support conversation is resolved by a reply. A booking enquiry is only resolved when a table is held in the diary. That difference is the whole problem.
The shared inbox can write a polished reply. It cannot book the table. The transaction, the part that actually earns the cover, still lands on your team, one enquiry at a time. Front gives you the best-organised version of the old workflow: everyone sees the enquiry, everyone knows who owns it, and the booking still gets typed into another system by hand.
What it looks like when the tool is built for booking enquiries
The gap closes when the inbox and the diary are one surface, so an enquiry that arrives by email is worth the same as one that arrives through the network. This is what RevVue does, and it is easier to show than to describe.
Every enquiry is tagged to the venue it is for the moment it lands. A group with sites in several cities stops relying on whoever recognises the address in the signature, and the team works from one queue, by location, rather than tags standing in for venues.
Enquiries arrive already sorted by venue, so nothing waits to be forwarded.
The AI drafts the reply in that venue's voice, using its menus, its policies and its own answers to the questions guests keep asking. The team reviews and sends instead of retyping the same explanation about set menus for the fourth time that week.
A drafted reply the team approves in one click, instead of writing the same answer again.
Because it connects to the booking system, the AI takes the step Front cannot: it checks availability and prepares the booking in the same thread. The everyday requests resolve on arrival, and the large parties and private-hire enquiries are acknowledged immediately and queued for a person, so the slowest reply is no longer the biggest booking.
The bookings worth a person's time, acknowledged instantly and prepared for approval.
And because every enquiry is tied to a location, email covers become countable. You can see response times and conversion by site next to the covers the network sends you, and compare the two honestly for the first time. Front reports on conversations and response times, which tells you nothing about how many tables those conversations produced.
Volume, response rate and conversion by location, sitting alongside the covers the network delivers.
An honest note on where RevVue is today
RevVue's OpenTable integration is in active development. That is the honest status. For now, groups run an email-only pilot that already delivers the inbox value shown above: location-aware routing, instant acknowledgement, AI-drafted replies, high-value bookings surfaced, and reporting by location. The direct booking-system connection will deepen that when it lands, but it does not gate the value you get today. The UK AI is in pilot.
This is the move the Brasilia Group made, off a horizontal helpdesk and onto an inbox built for the job. Their founder, Nikolaos Kiosses, put it plainly: "The transition from Zendesk to RevVue has been a game changer."
The wider category view is in shared inbox software for restaurants. Since a good share of these enquiries arrive from the booking network rather than your own site, automating third-party booking emails covers that specific problem. To see what the AI would have said to a real enquiry your team received last week, book 20 minutes.
Frequently asked questions
Does Front integrate with OpenTable?
No. Front has no native integration with OpenTable, and no restaurant booking system appears in the Front App Store. Because both tools are on Zapier you can build a bridge that turns an enquiry or a booking event into a Front conversation, but it only moves information one way. It cannot check availability, create or amend a reservation, or read the guest's dining history.
Can I connect Front and OpenTable with Zapier?
Loosely, with a caveat. Front's Zapier integration can only access shared inboxes, because the OAuth token is scoped that way, so enquiries in an individual mailbox need a Front API token and Webhooks by Zapier instead. Either route gives you notification rather than capability. The agent still opens OpenTable in another tab to check the diary, seat the party and create the reservation. OpenTable's deeper API access is partner-gated.
Why does Front integrate with logistics and travel tools but not booking systems?
Because Front has picked its verticals and hospitality is not among them. Front's App Store carries dedicated categories for logistics and maritime and for travel, reflecting a strong base of freight, shipping and travel-operations customers. That shows Front will build deep vertical integrations when it decides a market matters. It has not made that decision for restaurant booking systems.
What do restaurant groups use instead for booking enquiries?
Most run booking enquiries through a shared inbox and live with the double-handling, because no horizontal tool solved the booking side. A purpose-built option is RevVue, which is location-aware and whose AI checks availability and prepares the booking inside the conversation. Its OpenTable integration is in active development, with an email-only pilot available now.
