ResDiary gives you more control over automated guest email than most reservation platforms. Confirmations, reminders, cancellation notices and post-dining feedback are all fully brandable, the timing is yours to set, and you can switch any of them off entirely. Its marketing tools trigger sends the moment a booking is placed. What none of that touches is the inbound enquiry: the party of 12 asking about a Saturday, the guest wanting to move sittings, the question about the set menu. Those still get typed by a person.
What ResDiary automates today
Credit where it is due, and ResDiary earns it on control rather than volume. Where some platforms give you a fixed set of messages, ResDiary hands you the schedule and the styling.
Automated message | What you control |
|---|---|
Booking confirmation | Full branding, terms and conditions, images and logo |
Booking reminder | Whether it sends at all, and how long before arrival, by email or SMS |
Cancellation confirmation | Wording and branding |
Post-dining feedback | Whether it sends, and when after the visit |
Marketing triggers | Sends fired automatically when a customer places a booking |
Two things stand out. Every message can be customised to your venue's brand and messaging rather than looking like the software sent it, and the reminder schedule is genuinely tunable, which matters because the right reminder window for a two-sitting Saturday is not the right window for a Tuesday lunch.
If your no-shows are high on a ResDiary site, the fix is usually configuration: reminders off, sending too early, or terms not carried in the confirmation. That is worth checking before you buy anything else.
What ResDiary does not automate
Every message above is triggered by a booking that already exists. That is the whole design: a record appears, a clock runs, a template sends.
A booking enquiry has no record. It is a message from someone asking you to create one, and the answer depends on what the diary will take. So nothing triggers, and these stay manual:
A party of 12 asking about a Saturday that the widget will not take online.
A guest wanting to move from the early sitting to the late one.
Questions about the set menu, corkage, dietary requirements or accessibility.
Amendments arriving as a reply to a confirmation email, which land in a mailbox rather than in ResDiary.
Anything arriving by WhatsApp, Instagram or a website contact form, which ResDiary never sees.
There is a sharper version of this problem on a ResDiary site specifically. ResDiary's core value is yield: filling the right table at the right time across sittings. The enquiries that need a human are exactly the ones with yield consequences, a large party, a sitting change, a long booking on a tight turn. The person answering is making a yield decision in a mailbox, without the yield tools in front of them.
What actually happens to an enquiry ResDiary cannot answer
Here is one enquiry at a group running ResDiary well.
An email arrives at the restaurant address on a Sunday: a party of 12 for a Saturday in three weeks, asking for the early sitting and whether there is a set menu.
It sits. ResDiary never sees it, because it is not a booking.
On Monday a manager opens the mailbox and reads it.
They open ResDiary in another tab and check whether 12 can be seated at the early sitting on that Saturday, and what it does to the turn on that table.
They work out whether the group should be pushed to the late sitting to protect the turn, which is a revenue decision made from a mailbox.
They reply by hand with the options and the set menu.
If accepted, they create the booking in ResDiary, re-keying the name, date, sitting, party size and the menu note.
The guest replies: "Can we do 16 and stay later?" Sixteen on a tight turn is a different answer. Steps 4 to 7 run again.
Automation only resumes at step seven. Everything before it is manual, about 30 hours after the enquiry landed, and the decision that actually protects your yield was made by someone toggling between a mailbox and a diary. One operations director described that mailbox as "a black hole, no KPIs, no response rate, nothing." ResDiary reports on the covers you seated. It cannot report on the party of 12 you never replied to.
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."
Why the gap exists
The split is transactional versus conversational, and it is structural rather than an omission.
Transactional automation needs a record, an event and a template. ResDiary gives you unusually good control over all three, which is why its confirmation and reminder tooling is strong.
An enquiry offers none of them. There is no record, because creating one is the request. There is no event, because an email on a Sunday is not a state change in the diary. And no template fits, because the answer depends on live availability across sittings, this venue's menu and what the change does to the rest of the service.
There is a second reason specific to yield-led systems. ResDiary is built to help you decide what to accept. An enquiry has to be interpreted before that machinery can be pointed at it: someone has to read free text, work out the party size, date, sitting and constraints, and only then can the diary help. Reservation platforms start after that interpretation step. Nothing in the stack performs it.
Closing the gap needs something that reads the message first, works out which venue and which sitting it concerns, then checks the diary and drafts the reply.
What automating the enquiry side looks like
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.
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 the mailbox cannot: it checks what the diary will actually take and prepares the booking in the same thread. Routine requests clear on arrival, including on a Sunday, 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 already manage, so the enquiries that never became bookings stop being invisible.
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 rest: location-aware routing, instant acknowledgement out of hours, AI-drafted replies in each venue's tone, large parties held for a person, and reporting by location. The direct connection deepens it when it lands. The UK AI is in pilot.
Before adding anything, check your ResDiary configuration. If reminders are off or your confirmation carries no terms, that is a cheaper win than any new tool.
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 arrive at all hours and wait until someone opens a laptop, handling booking enquiries 24/7 is the most relevant read next, and if you are weighing a helpdesk for this, does Zendesk integrate with ResDiary 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 ResDiary automate?
ResDiary automates booking confirmations, booking reminders, cancellation confirmations and post-dining feedback emails, and its marketing tools can trigger a send when a customer places a booking. All of it is customisable to your venue's brand and messaging, you choose how long before arrival reminders and SMS go out, and you can disable any of them.
Can ResDiary answer inbound booking enquiries automatically?
No. Every ResDiary automation fires from a booking that already exists. An enquiry comes from someone with no reservation, so there is no record to trigger from and no template that fits, because the answer depends on live availability across sittings, the menu and what the change does to your turn times. Large parties, sitting changes and dietary questions are all still answered by a person.
Why is this worse on a yield-led system?
Because the enquiries needing a human are the ones with the biggest yield consequences: a large party, a sitting change, a long booking on a tight turn. ResDiary exists to help you make those calls well, but the enquiry has to be read and interpreted before any of that machinery can be pointed at it. So the revenue decision gets made in a mailbox, without the yield tools in view.
How do you automate the enquiry side?
You need something that reads the message first, works out which venue and sitting it concerns, checks what the diary will take and drafts a reply in that venue's voice for a person to approve. That is RevVue. Its ResDiary integration is on the roadmap, with an email-only pilot available now covering routing by location, out-of-hours acknowledgement, AI-drafted replies and reporting on enquiries the diary never saw.
