Requests transferred between your venues

Booking platforms do not let a request die when a venue says no: they pass it on. If you run several venues on the same platform, that means one of your own venues declines and the request comes straight back to you, on another site, as a brand-new email.

Left alone, this reads as two unrelated requests from the same client, and someone answers twice. Joinways recognises the transfer, ties it to the request it came from, and tells you plainly which venue declined. This article explains what you see and what to do with it.

What Joinways detects

Platforms announce a transfer in their own words, in French, English or Spanish. Joinways reads those announcements and treats the email as a request for the venue receiving it, not for the one named inside, which is the venue that declined.

That distinction is the whole point: the venue mentioned in the body is never the venue of the new request. Getting it backwards would file the request against a site that has already said no.

What you see in the Inbox

• A Transferred badge on the card, so you know before opening it that this is not a fresh enquiry.
• A banner in the detail naming the venue that declined, when the platform says which.
• A link, Open the original request, straight to the request the transfer came from.
• A Transfer tab when the request already had other venues, so the whole story sits in one place.
• The declining venue shown struck through, which reads at a glance as a door already closed.

On the other side, the original request carries its own note, Transferred to another of your venues, with a link to the transfer. Whoever opens it later sees where the client went rather than an enquiry that seems to have stopped dead.

The venue is yours to choose

A transfer email rarely says which of your venues the platform has in mind. Joinways does not guess: the venue shows as To choose, and you pick it when you convert the request into an event.

If you open the request on the platform with the Chrome extension, the brief fills in what the email left out, including the venue concerned.

What happens to the original request

If the original request was still waiting in your Inbox, Joinways closes it as transferred. It does not stay in your pending pile pretending someone still has to answer it, and it does not disappear either: it keeps its history and its link to the transfer.

The transfer also inherits the original request's identity when both are yours, on the same platform, from the same client. That is how the two stay recognisably one request rather than two clients with the same name.

💡 Read the original request before replying. It usually holds the exchange that led to the refusal, and knowing why the other venue said no often changes what you propose.

How to handle one

1. Open the request and read the banner: it says which venue declined.
2. Follow Open the original request to see what was already said to this client.
3. Check the date and the guest count against the venue you have in mind, since the request was written for another one.
4. Convert it, choosing the venue as you go. From there it is an ordinary event.
5. Reply on the platform, where the client is waiting.

Edge cases

• Transfer from a venue that is not yours: the original request is not in your Inbox, so there is nothing to link to. The transfer is treated as an ordinary request.
• Platform does not name the declining venue: the banner says another venue declined, without the name. Everything else works the same.
• Several transfers in a row: each one links back to the request before it, so you can walk the chain.
• You decline too: answer on the platform. Joinways records what the platform then reports, it never declines on your behalf.

Best practices

• Treat a transfer as a warm request, not a cold one: this client has already described their project once.
• Never re-ask what the original request already answers. Clients notice, and it reads as two companies rather than one group.
• Pick the venue before writing your reply, so the capacity and the price you quote match the room you are actually offering.
• Keep the extension installed if you work across several venues on one platform: it is what fills in the brief the email leaves blank.

Troubleshooting

The request landed on the venue that declined

Cause: the email was not recognised as a transfer, usually a wording the platform has just changed. Solution: choose the right venue when you convert it, and tell us which platform it was so the wording gets added.

There is no link to the original request

Cause: the original never reached your Inbox, or it came from a venue outside your workspace. Solution: handle the transfer on its own, nothing is missing from it.

The original request is still open

Cause: it had already been converted or archived, so it was left as it was. Solution: nothing to do, the link between the two still holds.

Real-world example

A company asks for 150 people on a Saturday in June. Your city venue takes the request, sees the date is already booked and declines on the platform. Two hours later the platform sends the request to your country estate. The Inbox shows it as transferred, names the city venue, and links to the first exchange. Your colleague reads it, sees the budget and the brief already written out, picks the estate and replies the same afternoon, without asking the client a single question they have already answered.

FAQ

Does this work on every platform?

Detection is based on how platforms word a transfer, in French, English and Spanish, rather than on a list of platform names.

Why is the venue empty?

Because the email does not say which of your venues it is for. You choose at conversion, or the extension fills it in from the platform.

Is the original request lost?

No. It is closed as transferred, keeps its history and links to the new one.

Will I be notified of a transfer?

It arrives in the Inbox like any request. Transfers deliberately do not raise a separate notification, so a busy inbox does not get noisier.

Can I reply from Joinways?

For a platform request, answer on the platform: that is where the client reads you.

See also

• Understand the unified Inbox
• Process an incoming request
• The Chrome extension