No. Re:amaze has no native, purpose-built integration with ResDiary, and no restaurant booking system appears anywhere in its integration list. Re:amaze is a multi-channel helpdesk for small and mid-sized e-commerce businesses, owned by GoDaddy. ResDiary is a reservations, table-management and yield platform used widely by independent restaurants and mid-market groups across the UK and Europe, usually on a flat monthly fee. Re:amaze can consolidate every channel an enquiry arrives on. It cannot see a single free table.
The short answer
Re:amaze will take a ResDiary-bound enquiry from email, chat, SMS or a social DM and give it an owner and a response time. It cannot act on it inside ResDiary. Checking which sitting has space, moving a party between sittings, applying the booking note and releasing a held table all still happen by hand, in ResDiary, by a person.
Re:amaze + ResDiary | |
|---|---|
Native integration | None |
Best available workaround | A custom build on Re:amaze's API and the ResDiary API |
What the workaround still can't do | Check availability, create or move a booking, or see how a change affects the rest of the service |
One clarification, because it can mislead. ResDiary runs its own customer support portal on Freshdesk. That is ResDiary buying a helpdesk for its own team, not a product integration, and it says nothing about whether a helpdesk can talk to your diary. The same is true of Re:amaze: it is not on ResDiary's partner list, and ResDiary is not on Zapier, so there is no low-code bridge between them either.
What actually happens to a booking enquiry
Give Re:amaze the credit it deserves first. Restaurants get booking requests on more channels every year, and a small group running Instagram, WhatsApp, a chat widget and a group mailbox has a genuine ownership problem. Re:amaze puts all of it in one queue, with assignment and response tracking, at a price a two- or three-site operator can carry. That is a real fix for a real problem.
Here is one enquiry, all the way through.
An SMS arrives asking to move a booking for eight from the early sitting to the late one, on a night the restaurant runs two sittings. Re:amaze queues it and assigns it.
An agent opens the conversation and reads it.
The agent opens ResDiary in another tab, because Re:amaze cannot see the diary.
They find the existing booking, check whether the late sitting has a table for eight, and work out what moving it does to the turn time on the table they would vacate and the one they would fill.
They move the booking in ResDiary, re-keying nothing but clicking through several screens, and update the note.
They switch back to Re:amaze and reply by SMS.
They close the conversation.
The guest replies: "Actually can we keep the early one but make it ten?" Ten at the early sitting is a different table entirely, and it may block the turn. The agent repeats steps 3 to 7.
Every enquiry is handled twice, in two systems, by a person moving between screens. Step four is the one that matters most on a ResDiary site, because ResDiary's whole value is yield: filling the right table at the right time. The person answering the message is making a yield decision without being able to see the yield. Re:amaze made sure the SMS was answered promptly. It has no view of whether the move cost you a cover. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing."
The sharper cost is the request that waits. A party of eight moving sittings is not a lost booking if you answer quickly. It becomes one if the message sits for four hours, because they will book elsewhere and cancel. 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."
What Re:amaze actually connects to
Re:amaze's integration list is a clear statement of who it serves: 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.
Not one restaurant booking system is in it. That is not a criticism so much as a description. Re:amaze is built and priced for e-commerce businesses, and an independent restaurant group is not the customer it was designed around.
The workaround here is more constrained than in the Zapier-enabled pairings. ResDiary has no Zapier connector, so the low-code route is closed even though Re:amaze offers one. Connecting them means a custom build against Re:amaze's API and ResDiary's partner API, which is gated, and that is a project with a budget and an owner rather than an afternoon's work. What it produces is enquiry data copied into a conversation, in one direction. It does not put availability in front of the person replying, and it does not let them move a party between sittings from the reply window.
Re:amaze's AI drafts replies, summarises conversations and runs chatbots, and much of that suite has carried a beta label. It is real and it is less mature than the AI in the pricier tools, and like all of them it works from past conversations and help-centre content. It can word the reply about moving sittings. It cannot tell you whether the late sitting has a table for eight.
One further gap matters for a group. Re:amaze supports managing 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, so a group with five ResDiary sites gets no view of which restaurant is slowest to answer or which is converting enquiries into bookings.
Why this matters for booking enquiries
A support conversation and a booking enquiry look alike and behave nothing alike. A support conversation is resolved by a reply. A booking enquiry is resolved only when the diary changes. On a site running two sittings, that difference is sharper still, because the right answer depends on what the change does to the rest of the night.
Re:amaze gets the message to a person fast, on whichever channel it arrived. It cannot move the table. The decision that actually protects your yield is made in a different system by someone toggling between tabs, which is exactly when mistakes and delays happen.
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 availability is checked while the reply is being written. This is what RevVue does, and it is easier to show than to describe.
Enquiries arrive already sorted by venue, so a group running different service patterns across its sites never answers one restaurant's question with another's shift times. The team works from one queue, by location, rather than one multi-channel queue that still treats every site the same.
Every enquiry tagged to its venue on arrival, so shift and service differences stay straight.
The AI drafts the reply in that venue's voice, grounded in its menus, its policies and its service times. The team approves or edits instead of composing the same availability answer from scratch.
The reply drafted in the venue's voice, with the team reviewing instead of re-keying.
Because it connects to the booking system, the AI does the step Re:amaze cannot: it checks what the diary will actually take and prepares the booking in the same thread. Routine requests clear on arrival, and the large parties, the ones that change the shape of a service, are acknowledged instantly and held for a person to place deliberately.
Large parties acknowledged and prepared, waiting for someone to decide where they fit.
And because every enquiry is tracked by location, the email channel gets the same scrutiny as the diary. Response times and conversion by site, next to the covers you are already managing, so the enquiries that never became bookings stop being invisible. Re:amaze reports on conversations, response times and volume per channel, and not one of those figures is a cover.
Response rate, volume and conversion by location, covering the enquiries the diary never saw.
An honest note on where RevVue is today
RevVue's ResDiary integration is on the roadmap and not live. That is the honest status. Groups run an email-only pilot now, which already delivers the inbox value shown above: location-aware routing, instant acknowledgement, AI-drafted replies, high-value bookings surfaced and held for a person, and reporting by location. The direct booking-system connection deepens it when it lands. 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."
If your enquiries currently arrive at all hours and sit until someone opens the laptop, handling booking enquiries 24/7 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 ResDiary?
No. Re:amaze has no native integration with ResDiary, and no restaurant booking system appears in its integration list. ResDiary is not on Zapier either, so there is no low-code bridge. Connecting them means a custom build against Re:amaze's API and ResDiary's gated partner API, and the result would still be enquiry data copied into a conversation rather than the ability to check availability or move a booking.
ResDiary uses Freshdesk for its own support. Does that mean helpdesks integrate with it?
No. That is ResDiary buying a helpdesk to answer its own customers, which is a purchasing decision rather than a product integration. It tells you nothing about whether your helpdesk can read your diary. No helpdesk appears in ResDiary's partner directory, and no booking system appears in Re:amaze's integration list.
Is Re:amaze a good choice for a restaurant group?
It is a fair, affordable answer if your problem is enquiries scattered across channels, and better still if the group sells vouchers or gift cards online, because Re:amaze is strongest on the e-commerce side. It is a poor answer if your problem is booking enquiries. It is built and priced for e-commerce businesses, it has no line into ResDiary, and it has no concept of which venue an enquiry belongs to.
What do ResDiary users use instead for booking enquiries?
Most keep a shared inbox alongside ResDiary and accept 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 ResDiary integration is on the roadmap, with an email-only pilot available now.
