No. Re:amaze has no native, purpose-built integration with OpenTable, and no restaurant booking system appears anywhere in its integration list. Re:amaze is a multi-channel helpdesk built for small and mid-sized e-commerce businesses and owned by GoDaddy. OpenTable is the front-of-house diary and the consumer network that fills a large share of your covers. Re:amaze will make sure a booking enquiry is never missed on any channel. It will not tell you whether you can seat the party.
The short answer
Re:amaze can take an OpenTable-bound enquiry from email, chat, SMS, WhatsApp or a social DM and put it in one queue with an owner and a status. It cannot act on it inside OpenTable. Checking the floor plan, holding the table, applying the guest's notes and no-show history: all of that still happens by hand, in OpenTable, by a person.
Re:amaze + OpenTable | |
|---|---|
Native integration | None |
Best available workaround | A Zapier or custom-API bridge that copies enquiry data into a conversation |
What the workaround still can't do | Check availability, create or amend a booking, read the guest's OpenTable profile or no-show history |
There is a particular irony in this pairing. OpenTable is the most automated system in the matrix when it comes to outbound email: confirmations, reminders with confirm and cancel buttons, waitlist updates, feedback surveys and birthday campaigns all fire without a person touching them. All of that automation points outwards, at bookings that already exist. The messages arriving inwards, from someone who has not booked yet, are the ones that still need a human and a second browser tab.
What actually happens to a booking enquiry
Give Re:amaze its due first. Enquiries for a restaurant group do not politely arrive on one channel. They come by email to the group address, by WhatsApp to the number in the website footer, by Instagram DM, and through a chat widget. Re:amaze pulls all of that into one place with assignment and response tracking, at a price a small group can carry. If your current failure mode is "nobody was watching the WhatsApp on Sunday," this fixes it.
Here is one enquiry, all the way through.
A WhatsApp message arrives on the number in the website footer asking whether the group's newest site can seat 14 for a work lunch in a fortnight. Re:amaze pulls it into the queue and assigns it.
An agent opens the conversation and reads it.
The agent opens OpenTable in another tab, because Re:amaze cannot see the diary.
They pick the right venue, check whether 14 can be seated at that time, look at whether it means combining tables in the window section, and check what else is already booked around it.
They create the booking in OpenTable, re-keying the name, date, time, party size and the note that it is a work lunch needing one bill.
They switch back to Re:amaze and write the reply on WhatsApp.
They close the conversation.
The guest replies two days later: "It is 17 now, and can we do 12.30 instead of 1?" Seventeen at 12.30 is a different table plan. The agent repeats steps 3 to 7.
Every enquiry is handled twice, in two systems, by a person copying the same fields between screens. Re:amaze guarantees the WhatsApp message was seen. It has no idea whether a cover resulted, because it never sees the diary. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing." Adding channels to that inbox adds visibility of messages, not of bookings.
The sharper cost is the enquiry that quietly goes elsewhere. A 14-cover work lunch is worth several hundred pounds and the person organising it is messaging three restaurants at once. 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." Re:amaze did not cause that. The delay is structural whenever the reply and the booking live in different software.
What Re:amaze actually connects to
Re:amaze's integration list is a clear statement of who it was built for: Shopify, BigCommerce, Magento, WooCommerce, WordPress, Stripe, Google Workspace, Slack, Jira, Aircall, JustCall, RingCentral and Pipedrive, plus Zapier. More than 5,000 e-commerce brands across more than 100 countries use it, and it rates highly on the Shopify and BigCommerce app stores.
No restaurant booking system appears in that list. It is worth being fair about why. Re:amaze is built and priced for e-commerce, and a restaurant group is not the customer it was designed around. The missing diary integration is the product working as intended for a different market, not a gap it forgot to fill.
Both Re:amaze and OpenTable are on Zapier, so a bridge is buildable here. Re:amaze's connector authenticates with the API credentials in its settings and offers triggers for new conversations and messages plus actions to create contacts and add messages. Build it and be honest about the result: an enquiry or an OpenTable event can create or update a conversation with a tag and an owner. That is routing, one direction. It does not let the agent read the floor plan, see that this guest no-showed twice last year, hold a table, or write the booking from the reply window.
Re:amaze's AI drafts responses, summarises conversations and powers chatbots, and a good part of that suite has carried a beta label. It is a real feature set and a less mature one than the AI in the more expensive platforms, and like all of them it is grounded in conversation history and help-centre articles. It can help word the reply to a 14-cover request. It cannot tell you whether 14 will fit.
One further gap matters for a group. Re:amaze can manage multiple businesses in one place, which sounds like multi-venue support. It separates brands rather than the availability behind them, and its reporting counts conversations rather than covers. For a group with six sites on one OpenTable account, there is still no concept of which venue's diary a given message needs to be answered from.
Why this matters for booking enquiries
A support conversation and a booking enquiry look alike and behave nothing alike. A support conversation ends when a good reply is sent. A booking enquiry ends only when a table is held. Everything between those two definitions is the problem.
Re:amaze is a strong answer to the question "where did that message go." It is no answer at all to "can we take them." The transaction still lands on a person, in a second system, one enquiry at a time. That is the work that costs you covers, and it is untouched by adding another channel to the queue.
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 one multi-channel queue that still treats every site the same.
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 Re:amaze 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. Re:amaze reports on conversations, response times and volume per channel, 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 deepens it when it lands, and it does not gate the value available 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."
Because a large share of these messages arrive from the network and from third-party sites, automating third-party booking emails is the most relevant read next, and shared inbox software for restaurants is the wider category view. To see what the AI would have said to a real enquiry your team received last week, book 20 minutes.
Frequently asked questions
Does Re:amaze integrate with OpenTable?
No. Re:amaze has no native integration with OpenTable, and no restaurant booking system appears in its integration list. Because both tools are on Zapier you can build a bridge that copies enquiry or booking data into a conversation, but it moves information one way only. It cannot check availability, create or amend a booking, or read the guest's OpenTable profile and no-show history.
OpenTable already sends automated emails. Why is an inbox still needed?
Because OpenTable's automation is outbound and transactional. It confirms, reminds, updates the waitlist and asks for feedback on bookings that already exist, and it does that well. None of it answers an inbound question from somebody who has not booked yet, which is where the large parties, the private hire and the awkward requests all live. That inbound conversation is the part that still runs on people.
Is Re:amaze a good choice for a restaurant group?
It is a defensible, affordable choice if your problem is scattered channels, and stronger still if the group runs an online shop for vouchers or gift cards, because the Shopify side is where Re:amaze is best. It is a poor fit if your problem is booking enquiries. It is built and priced for e-commerce businesses, it has no line into any diary, and it has no concept of which venue an enquiry belongs to.
What do restaurant groups use instead for booking enquiries?
Most run a shared inbox alongside OpenTable and absorb the double-handling, because no general-purpose helpdesk 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.
