Kiyo keeps the commercial journey understandable by separating inventory, reservation, payment and payout states. Each part stays connected, but one status never pretends to prove another.
Direct, desk-entered and connected OTA reservations meet on the same calendar. OTA reservations depend on an active channel connection and correct room and rate mapping; manual and direct bookings must be recorded in Kiyo to affect availability.
Room availability, rates and supported stay rules can be prepared in Kiyo and sent to mapped channels. The team can see what is open, closed or restricted before publishing a change instead of treating every OTA extranet as a separate source of truth.
A Kiyo property website or booking link can present available rooms and configured prices, then carry the guest through the connected checkout. Once confirmed, that reservation joins the calendar and can continue into confirmation email and My Page when enabled.
A confirmed reservation does not automatically prove that money was collected, and a successful payment does not prove that the payout has settled. Kiyo keeps the related references together so the team can reconcile each state without collapsing them into one green label.
A sellable room is not defined by price alone. Rate plans, minimum stays, closed dates and other supported restrictions determine which offer can be booked. Kiyo keeps those controls close to the calendar, while each connected channel still depends on what its mapping and API support.
The reliable daily workflow is to review arrivals and changes, check channel connection alerts, follow pending payments and resolve mismatched records. The goal is not to hide exceptions; it is to put them where the responsible person can see and act on them.
We use cookies to improve Kiyo. Privacy Policy
