Direct bookings

Last updated: 2026-08-20

A guest calls and asks whether anything is free this weekend.

Four steps sit between that question and a paid reservation, and most systems fail at exactly two of them. This page is about those two.

The sequence

Asking. Hunzi queries availability, rate and room category directly in the PMS while the guest is on the line. Not from an extract synchronised overnight, but from the system your front desk is looking at.

Holding. The matching room is reserved before money is discussed. Why that is a step of its own is the next section.

Paying. The guest gets a payment link bound to that specific reservation. On the phone Hunzi can stay on the line and wait for the payment to arrive rather than hanging up and hoping.

Confirming. The booking counts as complete only once the payment is in.

Why holding is a step of its own

ibelsa has no tentative reservation status. There is no "provisionally noted" state there that could be left to lapse after ten minutes.

That is not a detail. Without that state you have a gap of several minutes between "guest wants the room" and "guest has paid", and in that gap the same room can be sold a second time, at the desk or on the phone.

So we hold the room on our side, for 15 minutes. Long enough for a guest to receive the link, find their phone and enter a card. It was five minutes at first, and that was too short: guests ran into an expired reservation in the middle of checking out.

If nobody pays, the reservation lapses and the room is free again. There is nothing to tidy up.

What stops a room being sold twice

Two things, and both live in code rather than in an instruction to the language model.

A booking is not completed while no paid reservation exists for it. That is a check with two conditions, standing in front of the commit. It does not depend on a model remembering a rule.

A retry does not create a second booking. If holding a room does not answer, Hunzi tries again. It does not simply hold again: the system reconciles how many rooms are already held for this conversation and creates only the shortfall. A second attempt at the same room finds one and creates none.

Creating the reservation itself, by contrast, is never retried. A connection dropped after the PMS processed the create but before it answered would otherwise produce a second reservation. Reads are retried, because they change nothing. The distinction is deliberate: a double booking costs more than a repeated question.

That distinction matters, because the obvious implementation breaks precisely here. "On error, try again" is the line that sells the same suite twice on a full weekend.

The reservation exists before the money

You should know this before you see it in the PMS.

An ibelsaPay payment link hangs off an open folio, and a folio only exists once the reservation has been created. So the order is: create the reservation, leave the folio open, generate the payment link, attach the payment.

In practice that means a reservation appears in your system before the money has arrived. It is not paid, and it is identifiable as such. We write this down because an unpaid reservation in the PMS looks like a fault without the explanation, and because the alternative would be to tell you an order of events the system does not have.

When it is nearly sold out, Hunzi does not book

This is the part that surprises most people.

If free stock in a category falls below a threshold you set, Hunzi does not complete the booking. It holds no room, it takes no money, and it does not retry. The guest is told that only a few rooms are left and is sent to your property's own website to book there directly.

For a vendor that would like to look good on completed bookings, that is the wrong decision. For a property that does not want to lose the last three rooms of a sold-out weekend to an automated flow, it is the only right one.

Without portal commission

A booking made through this path is a direct booking. It arises in conversation with your property, it runs through your payment service provider, and it lands in your PMS. There is no third party taking a percentage.

That is explicitly not a promise that your portal share falls. What we can tell you is where this particular booking came from.

Limits

What the PMS cannot do, Hunzi cannot replace. The missing tentative status is the example on this page. We work around it visibly instead of pretending it is there.

Payment confirmation comes from outside. Hunzi learns about the payment when the payment service provider reports it. If that service is disrupted, the booking waits rather than confirming itself.

Groups and special cases belong on the phone. Long stays, corporate allocations, contracts with negotiated rates: those are conversations, not forms. Hunzi recognises them and hands over to a person instead of inventing a rate.

The difference

A booking form on your website waits for somebody to fill it in.

The 8pm call, the "got anything free?" on WhatsApp, the Sunday evening email: those are the enquiries that stall today at a front desk that has just gone home, and that are booked through a portal by the next morning.

This page describes the path by which they become a paid reservation in your own system instead, while the guest is still on the line.