Resy automates transactional guest email reliably. Every booking, change and cancellation generates an automated email, reminders and pre-visit questionnaires go out on schedule, post-visit feedback is collected, and segmented sends handle birthdays and thank-yous. Resy's partners report no-show rates below 3%, which is a fair measure of how well that machinery works. What none of it does is answer the guest who could not get what they wanted online, and at a Resy-type restaurant that is a large share of your inbound.
What Resy automates today
Give Resy proper credit. Its transactional email is dependable and consistent, delivered through Twilio SendGrid, and the guest experience around a booking is smooth.
Automated message | What triggers it |
|---|---|
Booking confirmation | A reservation being made online |
Change and cancellation notice | The guest amending or cancelling |
Reminder | A scheduled window before the visit |
Pre-visit questionnaire | Ahead of arrival, to collect preferences |
Post-visit feedback | The visit completing |
Segmented sends | Birthday offers, thank-you notes and invitations to experiences |
One limitation worth knowing before you plan around it: customisation of confirmation, change and cancellation emails is available to Platform 360 and Full Stack partners, and Resy's automatic SMS language and timing are standardised. So the wording flexibility you get depends on your plan, in a way that is not true of ResDiary or Tock.
Guest data also flows automatically between Resy and connected CRMs, so visit history, preferences and frequency reach your marketing tools without manual exports.
What Resy does not automate
Every message above is triggered by a reservation that already exists. That is the pattern across this whole category, and Resy is no exception.
An enquiry has no reservation behind it. It is a message from someone asking for something the system did not give them, and at an in-demand restaurant it is usually one of these:
A request to be told if anything opens up on a date that is fully booked.
A large party the online book will not take.
Questions about the counter, walk-in policy, the tasting menu or dietary requirements.
Private events and buyouts.
Amendments sent by replying to a confirmation email, which land in a mailbox rather than in Resy.
Instagram DMs and WhatsApp messages, which never touch Resy at all.
There is a pattern specific to reservation-led restaurants. Your online book converts the easy demand automatically. What lands in your inbox is, almost by definition, the demand the system already turned away: the people who wanted a table and could not get one. Those are motivated guests, and they are the ones waiting on a human.
What actually happens to an enquiry Resy cannot answer
Here is a realistic journey at a restaurant running Resy.
A guest who missed the online release emails on a Tuesday night asking to be told if anything opens for two on Saturday, and whether the bar counter is walk-in.
It sits. Resy never sees it, because it is not a reservation.
On Wednesday someone opens the mailbox and reads it.
They open Resy in another tab, check Saturday for any two-tops, look at how long the notify list already is, and confirm the counter's walk-in policy for that night.
They add the guest to the notify list by hand, or make a private note to watch for a cancellation.
They reply, explaining there is nothing now and that the counter takes walk-ins from six.
They close the conversation, or leave it open as a reminder, where it becomes clutter.
On Thursday a cancellation appears. Nothing connects it to the guest who asked, because the mailbox and the book have no shared memory. The table goes to whoever refreshes the app first.
Step eight is the specific loss here. Nobody made a mistake. The reply was accurate and reasonably quick. The opportunity evaporated because the request and the availability lived in two systems that never spoke, and the person who could have matched them had moved on. One operations director described that mailbox as "a black hole, no KPIs, no response rate, nothing."
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." For an in-demand restaurant the loss is rarely one big booking. It is a steady drip of motivated guests who asked, waited and stopped asking.
Why the gap exists
The line is transactional versus conversational, and Resy sits firmly on the transactional side by design.
Transactional automation needs a record, an event and a template, and Resy's version is deliberately standardised. That standardisation is why it is reliable at scale and why no-show rates are low, and it is also why the wording is locked down on some plans.
An enquiry breaks all three conditions. There is no record, because the guest is asking you to make one. There is no event, because an email at 11pm is not a state change in your book. And a template cannot answer it, because the reply depends on live availability, the notify list, the counter policy and sometimes a judgement about whether to squeeze a two-top in.
There is a second factor at a restaurant like this. Much of the inbound is not answerable at the moment it arrives, because the honest answer is "nothing right now." A useful system would keep watching and come back when something changes. Nothing in a reservation platform's automation is built to hold an unresolved request open against future availability, because the platform only knows about bookings that exist.
What automating the enquiry side looks like
The gap closes when the inbox and the diary are the same surface, so the enquiry is answered and booked in one place instead of two. This is what RevVue does, and it is easier to show than to describe.
Enquiries are tagged to the right venue as they arrive, so a group with several restaurants stops triaging by hand. That matters more when demand is high, because the enquiries that arrive by email are usually the ones the online book already turned away.
One queue, sorted by venue, for the enquiries that never fitted into the online book.
The AI drafts the reply in that venue's voice, using its menus, its policies and the answers it gives most often. Guests who write after missing a slot want a real answer about alternatives, and the draft already contains them.
A drafted reply in the venue's voice, ready for the team to approve or adjust.
Because it connects to the booking system, the AI does the step the mailbox cannot: it checks availability and prepares the booking inside the conversation. Everyday requests are handled on arrival, at 11pm as readily as at 11am, and the high-value ones, the celebration tables and large parties, are acknowledged instantly and held in a queue the team works.
High-value enquiries acknowledged and prepared, waiting for a person rather than for attention.
And because every enquiry is tracked by venue, you can finally see the demand that never made it into the book: response rates, volumes and conversion by site, which is the part a reservation platform cannot show you because it never had the record.
Enquiry volume, response rate and conversion by location, including the demand the book never recorded.
An honest note on where RevVue is today
RevVue's Resy integration is on the roadmap and not live, and Resy's closed API is the reason it sits where it does: there is no self-serve developer portal and no Zapier listing, so a connection depends on partner access. That is the honest status. Restaurants run an email-only pilot now, which already delivers the rest: routing by location, instant acknowledgement out of hours, AI-drafted replies in the venue's tone, high-value enquiries held for a person, and reporting by location. 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 lot of this demand arrives from the network and third-party sites, automating third-party booking emails is the most relevant read next, and if you are weighing a helpdesk for this, does Zendesk integrate with Resy answers that directly. To see what the AI would have said to a real enquiry your team received last week, book 20 minutes.
Frequently asked questions
What email does Resy automate?
Resy sends an automated email whenever a guest books, changes or cancels online, plus reminders, pre-visit questionnaires and post-visit feedback requests. It also supports segmented sends such as birthday offers, thank-you notes and invitations to experiences. Confirmation emails are delivered through Twilio SendGrid, and Resy's partners report no-show rates below 3%.
Can I customise Resy's automated emails?
Partly, and it depends on your plan. Customising confirmation, change and cancellation emails is available to Platform 360 and Full Stack partners, while Resy's automatic SMS wording and timing are standardised across the board. That is a narrower degree of control than platforms like ResDiary or Tock offer, so it is worth confirming what your plan includes before you build a process around it.
Why do enquiries pile up at an in-demand restaurant?
Because the online book converts the easy demand automatically, so what reaches your inbox is largely the demand the system already turned away. Those guests are motivated and their questions need judgement: whether anything might open up, whether the counter takes walk-ins, whether a two-top can be squeezed in. None of that can be answered by an automation triggered from a booking that does not exist.
How do you automate the enquiry side?
You need something that reads the message, works out which venue it concerns, checks availability and drafts a reply in that venue's voice for a person to approve, and that keeps an unresolved request open against future availability. That is RevVue. Its Resy integration is on the roadmap, with an email-only pilot available now covering routing by location, out-of-hours acknowledgement and reporting on demand the book never recorded.
