How do you stop double bookings?
By holding availability in one place and taking a short-lived hold at the start of a booking rather than at the end. Every channel books against the same record, and where a channel manager sits in between, its failure modes are made explicit. Overbooking is nearly always an architecture problem rather than a staff one.
Will the front desk keep working if the internet goes down?
That is a requirement rather than a nice-to-have, and it shapes the design. Card terminals, the till and the door system should fail independently rather than together, with a local mode for the things that cannot wait, so a property keeps trading while a line is restored.
Can we change rates across all channels at once?
Yes, and doing it channel by channel is the thing this work is usually bought to end. Rates and offers are set once against the availability record and pushed outward, which removes both the time and the errors that come from maintaining the same number in five places.
Do guests need to download an app?
Usually not, and it is worth resisting. Check-in, keys and messaging can run in a browser, and asking a guest to install something for a two-night stay loses more people than it serves. An app earns its place where there is a repeat relationship, such as a loyalty programme.
We are seasonal. When should this work actually happen?
Gather the requirements during the season and build outside it. The peak is when every weakness is visible, so that is the time to stand at the desk and watch what goes wrong, and it is the worst possible time to change anything. We put a freeze around the busy period, agree in advance what counts as an emergency fix during it, and do the substantial work in the quiet weeks with enough margin to test properly before volume returns. That argues for planning a year ahead rather than starting the month before you open. Reporting takes the same shape, because comparing a week to the one before it means nothing in this business. The default comparison is the same period last year.
What happens if a payment succeeds and the booking does not?
It happens in every booking system ever built, and the difference between them is whether you find it before the guest does. Booking requests carry an idempotency key, so a retry or a double tap cannot create a second reservation. Payment and reservation are reconciled on a schedule, and the list of payments with no booking and bookings with no payment is read every morning by a person rather than generated and filed. The recovery path matters as much as the prevention. A booking should be rebuildable from the payment provider's record and the confirmation the guest received, because when somebody is standing at the desk holding that email, the email is the evidence and arguing with it is not an option.
Should we take direct bookings or just let the agents do it?
Both, and treating the agents as the enemy costs properties money. An online travel agent is a marketing channel with a commission attached, and for a property nobody has heard of it is the cheapest one available. Direct is not free either: you pay for the site, the payment processing, the support calls and the marketing that brings anyone to it at all. The sensible aim is to make direct the obvious choice for a guest who already knows your name, which usually means a booking path faster than the agent's rather than a discount that breaks a parity clause you signed. Watch contribution after commission and cost per channel rather than the channel mix on its own.
Can we do dynamic pricing?
Yes, and it needs guard rails long before it needs cleverness. A pricing engine wants enough history to learn from, which a new property does not have, and somebody who owns the rules, which is a job rather than a setting. Put a floor and a ceiling on every rate, cap how far a price may move in a day, and require a human override on the dates where a mistake is most public. A bank holiday rate that lands ten times too high ends up screenshotted and shared, and one ten times too low sells out the weekend that pays for your quarter. Log every automated change with its reason, so the morning after a strange night somebody can see what moved and why.
