The guest pays on their own phone.
No card number read aloud to a machine, nothing sensitive on a recording. The link arrives by WhatsApp or SMS while the room is still held — and the confirmation follows the moment the payment clears.
Most systems that answer a hotel phone out of hours can take a name and a number. The difference here is what happens next: AllHourDesk holds real inventory, collects payment, and writes a confirmed reservation into your system of record — or gives the room back if payment never arrives.
Everything the agent can do reduces to these. Each one runs against your live back-end, not a copy of it.
A phone call and a payment happen on two different clocks. The guest is on the line; the card is charged a few minutes later, on their phone, after they've hung up. Between those two moments the room has to be genuinely unavailable to everyone else — and if the payment never lands, it has to go back on sale without anyone touching it.
The agent reads back live options. Nothing is reserved yet.
The guest picks one and the room is held in your back-end, with a deadline attached.
A secure payment link goes to the guest's phone by WhatsApp or SMS while they're still on the call. Card details are never spoken aloud.
Payment clears, the reservation is confirmed in your system, and the guest gets the confirmation code on the same thread.
No payment by the deadline and the hold is released automatically — the room goes back on sale without a human noticing it was ever gone.
The failure everyone worries about is the one where money is taken and the room isn't secured. That path is handled explicitly: the booking is either completed, refunded, or escalated to your team — never silently dropped.
No card number read aloud to a machine, nothing sensitive on a recording. The link arrives by WhatsApp or SMS while the room is still held — and the confirmation follows the moment the payment clears.
Hotels run wildly different systems — modern REST APIs, channel managers, and legacy XML connectors that disagree about basic things like whether a "hold" exists at all. All of it sits behind one internal interface, so adding a property doesn't mean rebuilding the product.
Apaleo is live and running real bookings today. Mews and other open-API systems follow the same integration path.
For properties pooling inventory across OTAs and direct channels.
OTA-XML style connectors, where capabilities vary. Where a system has no native hold, the platform simulates one and manages the risk explicitly rather than pretending it isn't there.
Your published number is on signage, on Google, on every past guest's phone. It doesn't change. Three ways to route it, in order of how much commitment they ask for.
Forward-on-no-answer means the AI is overflow and after-hours cover, not a replacement for your front desk. Your team keeps every call it wants.
European languages plus Arabic, detected from how the caller speaks rather than chosen from a menu.
Callers talk over the agent, change their minds, and trail off. Turn-taking is tuned so a "yeah" or "mm-hmm" doesn't derail the sentence.
Rates and room types come from tool calls against your inventory. If a lookup fails, the agent says there's a technical problem — it does not guess a price.
Every call leaves a transcript and a booking audit trail your team can read at handover.
Four regimes apply at once to a recorded, AI-answered, card-taking phone call in Europe and the Gulf. They shaped the architecture rather than being audited onto it afterwards.
The agent discloses that it's an AI at the start of every call, in the caller's language.
Recording, consent capture and retention are configurable per tenant and per country, because EU consent law is not uniform.
Payment happens on a hosted payment page. Card data never enters the call, our systems, or yours.
EU-hosted by default, with region partitioning for Gulf properties under Saudi PDPL.