One request, several of your venues

When a client contacts several of your venues at once, Joinways stacks the request into one card with a tab per venue, and can convert them all in one go.

Updated September 15, 2026

A client looking for a venue rarely writes to one. On a booking platform they tick three boxes; by email they put four addresses in the To field. If you run several venues, the same project therefore lands in your Inbox several times, once per site.

Handled as separate requests, that becomes three colleagues writing three different replies to the same person, sometimes with three different prices. Joinways recognises that it is one request and stacks it into a single card, with one tab per venue.

How the stack works

Joinways computes an identity for every incoming request, from the platform, the reference and the client. Requests sharing that identity are the same project, and the Inbox shows them as one card rather than several.

The card carries a tab per venue, and the detail repeats them under the title.
A line says plainly that this request went to several of your venues, with the count.
Switching tabs switches venue without leaving the request: same client, same brief, another site.
A request arriving while you are looking joins its stack straight away, without a refresh.

Stack or duplicate

Two things look similar and are not. A stack is the same request across different venues, and every branch is legitimate: each site has a real decision to make. A duplicate is the same request twice on the same venue, which is a copy you do not want.

That is why the Same request panel in the request detail only lists twins on the same venue, the ones you may want to merge. The other venues are in the tabs, not in that list.

Merging folds one request into another: nothing is deleted, the history follows. Use it on a genuine duplicate, never to collapse two venues into one.

Converting the whole stack at once

When you convert a request that has open sisters on other venues, the dialog offers to create an option for each of them in one pass. Same contact, same dates, same needs; each event keeps its own venue and they stay grouped.

Open the request and check the brief on the tab you are starting from.
Start the conversion and fill in the event once.
Tick the option to create one for the other venues of this request.
Confirm. You get one event per venue, each on its own site, all in the same group.

If a venue cannot be converted, Joinways says how many were left out rather than pretending everything went through.

💡 Convert the whole stack even when one site is your clear favourite. An option costs nothing, blocks nothing, and the day your first choice falls through the second is already prepared.

Answering well

The client knows they wrote to several of your venues, and they will compare the replies. Two things matter: that the replies are consistent with one another, and that each one genuinely speaks about its own site.

Agree who answers before anyone writes. The tabs make the overlap visible, which is the whole point.
Keep one voice for the group rather than three tones for the same brand.
Do not send the same price for two different rooms. Comparing is exactly what the client is doing.
When a site cannot take it, say so and point to the one that can, in the same message.

Edge cases

One venue declines: its branch closes, the others continue. If the platform then transfers the request onward, the transfer links back to it.
Client books one site: the other events stay as options until you close them. Nothing closes them for you.
Venue not identified: a request whose site is unclear shows as such and waits for you to choose at conversion.
Two requests that look identical but are not: check the dates and the guest count before merging. Two events for the same client in the same month are common.

Troubleshooting

The requests did not stack

Cause: they reached you by different routes, so Joinways could not see them as one request, typically one by platform and one by direct email. Solution: handle them side by side, and merge only if they are on the same venue.

The group conversion is not offered

Cause: the other branches are already converted, closed, or the request is not a stack. Solution: check the tabs; if a venue is missing, convert it from its own tab.

One venue was left out of the conversion

Cause: that venue could not take the event, often a plan limit or a lock. Solution: open its tab and convert it on its own once the blocker is cleared.

I merged two requests by mistake

Cause: merging folds one into the other. Solution: nothing was deleted, the history is intact. Open the merged request from the panel to find its content.

Real-world example

A company looks for 90 people in September and contacts your three venues on the same platform. The Inbox shows one card with three tabs. Your colleague opens it, sees at once that the loft is free, the rooftop is taken and the estate is too big, converts the stack in one pass, and replies once for the group: the loft with a price, the estate mentioned as a larger alternative, the rooftop ruled out honestly. The client gets a single coherent answer instead of three that contradict each other.

FAQ

Should I merge the venues of a stack?

No. Each venue has its own decision to make. Merging is for a genuine duplicate on one venue.

Does group conversion create duplicate events?

No. One event per venue, all in the same group, even if two people convert at the same moment.

Does each venue keep its own history?

Yes. The stack is a reading device: underneath, each venue keeps its own request, its own event and its own exchanges.

What if a venue was added later?

It joins the stack when it arrives, without you doing anything.

Can I answer all the venues in one message?

For a request that came by email, yes, and it is usually the better answer. For a platform request, reply on the platform, branch by branch.