No. Re:amaze has no native, purpose-built integration with DesignMyNight, and no restaurant or bar 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. DesignMyNight is the UK discovery, booking and enquiry platform that bars, pubs and late-night venues use to fill packages and parties. This pairing is harder than most, because there is no Zapier route between them at all.
The short answer
Re:amaze will collect a DesignMyNight enquiry from whichever channel it arrived on and give it an owner and a status. It cannot act on it inside DesignMyNight or Collins, the venue-side software behind it. Checking what is free, holding an area, applying the package and taking the deposit: all of that still happens by hand, by a person, in another system.
Re:amaze + DesignMyNight | |
|---|---|
Native integration | None |
Best available workaround | A custom build on Re:amaze's API and the DesignMyNight API |
What the workaround still can't do | Check availability, hold an area, apply a package or take a deposit inside the conversation |
Worth being precise about the workaround, because it is weaker here than in some other pairings. DesignMyNight is not on Zapier. Re:amaze is. That asymmetry means there is no low-code bridge to build: any connection is a development project against two APIs, commissioned and maintained by you, for a result that still cannot hold a booth on a Saturday night.
What actually happens to a booking enquiry
Start with what Re:amaze does well, because for this kind of venue it is genuinely relevant. Late-night and experiential venues get booking enquiries on every channel a person can think of: Instagram DMs at midnight, WhatsApp, the chat widget, the group email address, and Facebook. Re:amaze pulls all of that into a single queue with assignment and response times, cheaply. For a three-site bar group that is a real improvement over five people checking five apps.
Here is one enquiry, all the way through.
A live-chat enquiry arrives on a Friday evening asking about bottomless brunch for 11 the next morning, mentioning one guest who cannot eat gluten. Re:amaze puts it in the queue and assigns it.
An agent opens the conversation and reads it.
The agent opens DesignMyNight in another tab, because Re:amaze cannot see what is bookable.
They check whether the venue has an 11-cover brunch slot left in the morning, which area it would sit in, whether the package minimum applies at that size and what the kitchen can do about the gluten-free cover.
They create the booking, re-keying the name, date, time, party size, the package and the dietary note, and set up the deposit request.
They switch back to Re:amaze and reply in the chat.
They close the conversation.
The guest replies an hour later: "Make it 14, and can two people just have drinks?" Fourteen changes both the area and the package minimum. The agent repeats steps 3 to 7.
Every enquiry is handled twice, in two systems, by a person copying the same fields between screens. Step eight is the one that hurts most for this kind of venue, because a bottomless brunch party changes size three times before it arrives, and every change is a full re-run of the workflow. Re:amaze made sure the chat was answered. It cannot report on whether the brunch was booked. One operations director described the inbox behind this workflow as "a black hole, no KPIs, no response rate, nothing."
The sharper cost is the party that books somewhere else. A group of 11 for bottomless brunch tomorrow is asking two or three venues at once, and they will take whichever answers first. 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." That is a Friday-night enquiry answered on Monday, and for a late-night venue Friday night is the whole business.
What Re:amaze actually connects to
Re:amaze's integration list says plainly 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 in more than 100 countries use it.
No bar or restaurant booking system appears in it. That is fair enough on Re:amaze's part. It is built and priced for e-commerce businesses, and a late-night venue group is not the customer it was designed around.
The workaround question is where this pairing is genuinely more constrained than most. DesignMyNight has no Zapier connector, so the usual low-code bridge is unavailable. Connecting the two means a custom build against Re:amaze's API and DesignMyNight's, which is a development project with an owner, a budget and ongoing maintenance. And the honest part is what you get at the end of it: enquiry data copied into a conversation, one direction. It still would not let an agent see Saturday's availability, hold the booth, apply the package or trigger the deposit 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 is grounded in past conversations and help-centre content. It can draft a friendly answer about bottomless brunch. It cannot tell you whether tomorrow's late sitting has 11 spaces.
One more gap matters for a group. Re:amaze supports managing multiple businesses in one place, which sounds like multi-venue support. It divides brands rather than the availability behind them, and its reporting counts conversations rather than covers, so there is no view of which of your bars is slowest to answer a party enquiry.
Why this matters for booking enquiries
A support conversation and a booking enquiry look alike and behave nothing alike. A support conversation is finished by a good reply. A booking enquiry is finished only when something is held in the diary. For a venue selling packages and areas rather than tables, that gap is wider still, because the answer depends on capacity, minimum spend and what the kitchen can absorb.
Re:amaze makes sure the message reaches a person quickly. It cannot hold the booth. The commercial part of the job stays manual, in another tab, and stays slow at exactly the hours these venues take their enquiries.
What it looks like when the tool is built for booking enquiries
The gap closes when the enquiry and the booking sit in one place, so a package question can be answered and held in the same reply. This is what RevVue does, and it is easier to show than to describe.
Enquiries are routed to the right bar or venue automatically, which matters when a group runs several late-night sites with different licences, layouts and last entry times. Nobody quotes the wrong venue's closing time, because the team works from one queue, by location, rather than one multi-channel queue that still treats every site the same.
Each site gets its own queue, so the answer always matches the venue that was asked about.
The AI drafts the reply in that venue's voice, grounded in its packages, its minimum spends and what the space can actually hold. Package enquiries are long and repetitive, and the draft arrives with those details already in it.
The package answer drafted in the venue's voice, waiting for one-click approval.
Because it connects to the booking system, the AI does the step Re:amaze cannot: it checks what is free and prepares the booking inside the conversation. Straightforward requests are handled as they arrive, and the ones carrying a deposit or a whole-space hire are acknowledged instantly and held for a person to work properly.
Deposit-carrying and large-party enquiries, acknowledged and prepared for someone to finish.
And because everything is tracked per site, you get the numbers a booking widget never produced: how fast each venue replies, how many enquiries convert, and which site is quietly losing its Friday nights. Re:amaze reports on conversations, response times and volume per channel, which is a different question from how many Saturday bookings you won.
Response rate, volume and conversion per site, including the enquiries that never converted.
An honest note on where RevVue is today
RevVue's DesignMyNight integration is in active development. That is the honest status. For now, venues 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 that 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 party and package enquiries are the highest-value threads a late-night venue handles, triaging high-value group bookings 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 Design My Night?
No. Re:amaze has no native integration with DesignMyNight, and no bar or restaurant booking system appears in its integration list. DesignMyNight is also not on Zapier, so unlike some pairings there is no low-code bridge available. Connecting them means a custom build against both APIs, and that build still could not check availability, hold an area or take a deposit inside the conversation.
Can I connect Re:amaze and DesignMyNight with Zapier?
No. Re:amaze has a Zapier connector, but DesignMyNight does not, so there is nothing on the other side to connect to. Any integration is a bespoke development project against Re:amaze's API and DesignMyNight's, with a budget and ongoing maintenance, and the outcome is enquiry data copied into a conversation rather than the ability to book.
Is Re:amaze a good choice for a bar or late-night group?
It is a fair, affordable choice for the channel problem, and late-night venues have that problem badly, with enquiries arriving by DM, WhatsApp and chat at all hours. It is a poor fit for the booking problem. It is built and priced for e-commerce businesses, it has no line into DesignMyNight or Collins, and it has no concept of which venue an enquiry belongs to.
What do late-night venues use instead for booking enquiries?
Most keep a shared inbox next to DesignMyNight and accept that every enquiry is handled twice. A purpose-built option is RevVue, which is location-aware and whose AI checks availability and prepares the booking inside the conversation. Its DesignMyNight integration is in active development, with an email-only pilot available now.
