They watched Booking for five minutes: what a channel manager really does

Sunday evening. Two cabins booked for the coming week.

And on Booking, those same dates still open.

Five minutes later: still open.

That was the ticket we got from a small cabin accommodation that uses our booking engine. Short, polite and very reasonable: they knew it takes a few minutes, but was this normal, or should the sync be faster?

Then they did what anyone does with two cabins at stake. They closed the dates on Booking by hand.

Which meant, as they told us two days later, they couldn't check how long it would have taken on its own. They'd look again with the next booking.

I liked that ticket a lot. Not because something had gone wrong. Because it's exactly the question anyone looking for a channel manager for a small lodging should ask before signing. And almost nobody does.

What a channel manager for a small lodging promises (and the minutes it leaves out)

The pitch is simple. One availability for every portal. A booking comes in anywhere and the dates close everywhere else. No more selling the same room twice.

It's true. Our own product page says it, and adds two words that matter: "in minutes".

Not "instantly". Minutes.

I don't see that gap as a flaw of one particular tool. It's what happens when two systems run by different companies have to talk. Your engine tells the portal "these nights are gone", the portal processes it on its side, and in between there's a window. Small, but real.

For a hotel with forty rooms, a few minutes barely registers. For a place with a handful of cabins, where one cabin is a big slice of the month, five minutes staring at a screen feels like an afternoon.

A channel manager doesn't remove the gap between two calendars. It makes it short enough that you stop living in it.

Some setups make that gap much bigger. Linking calendars with an iCal link, for example, depends on when each portal decides to read it again, and that can be far longer than minutes. So I'd always ask how the connection works, not just whether it exists.

The second ticket was the interesting one

About ten days later the same client wrote again. This time about bookings that had come in from Booking.

When they opened one and added internal notes, the details they needed for the stay, the system wiped them. And they'd seen one of those bookings vanish from the calendar on a specific day.

In the same thread they mentioned something people outside the sector rarely know: the cards Booking gives them are virtual, and only let them charge the amount of the stay. Nothing else.

I'm not going into the technical side of each case here. What interests me is the question underneath both, because it's the one that catches small lodgings in their first months:

When a booking lives in two systems, which one gets the last word?

A booking that comes from a portal isn't entirely yours. Part of it belongs to the portal: dates, guest, price, changes, cancellations. When the portal sends an update, your system has to decide what to keep and what to overwrite. Your notes, your internal details, your "arriving late, leave the key in the box", need a place where the next update can't step on them.

Nobody explains that in the demo. In the demo everything syncs and everybody smiles.

What I'd ask before choosing one

If you run a small hotel, a few apartments or a rural house and you're comparing channel managers, these are the questions I'd put on the table. Not just to us. To anyone.

• How long does a booking take to close the other portals? A number, not "real time".
• How does it connect to each portal? A direct connection, or a calendar link that refreshes whenever it refreshes.
• If a portal changes or cancels a booking, what happens to what I've added? Notes, extras, check-in details.
• Who do I write to when something doesn't add up? And does that person know how your setup is built?
• How do I charge portal bookings? Virtual cards come with their own rules.

And one piece of advice that costs nothing: for the first few weekends, do what this client did. Watch. Time it. Write it down. Then you'll know your real gap instead of the brochure one.

What I liked most is that neither ticket was angry. Both were precise. "We waited five minutes." "On this day it disappeared." That's how you help whoever has to fix things. And it's the kind of client I'd want for any product: one who checks before assuming.

I've written before that integrating with big platforms is mostly waiting. And when we stopped customising our booking engine, part of the reason was this: every channel connection is a promise you keep again each time a portal changes something on its side.

I'm convinced a channel manager is worth it for a small lodging. But it's worth it when you know what happens in the minutes nobody shows you.

If you want to see how we've approached it, you can see a demo of Foxnice Booking (in Spanish).

P.S. The client was right to close it by hand. Trust the tool, sure. But on a Sunday evening with two cabins at stake, trust the button you can see too.