Explore how bookings, guest conversations, daily work and property performance appear in the Kiyo workspace. This tour uses sample data and can be read without signing in.
Purpose: See the property overview and the work that needs attention today.
Inputs: Recorded bookings, guest activity and configured workspace data.
Output: A prioritised view for the property team.
Availability: The public tour shows fixture data; a property workspace depends on its enabled product access and recorded data.
Purpose: Keep reservations, rooms, dates and stay context in one calendar.
Inputs: Direct and manually entered bookings, plus reservations from connected and mapped OTA channels.
Output: A live calendar and reservation record for the property team.
Availability: Channel reservations require an active connection and correct room and rate-plan mapping.
Purpose: Keep the guest, stay and recorded payment status close together.
Inputs: A booking recorded in or returned to Kiyo.
Output: One record for reviewing stay context and related operational work.
Availability: A payment taken outside Kiyo must be recorded before its status can appear in Kiyo.
Purpose: Review supported guest conversations next to reservation context.
Inputs: Connected, eligible messaging or OTA accounts and guest-initiated messages where required.
Output: A guest thread kept close to relevant booking information.
Availability: Channel coverage, account eligibility and platform rules vary; verify the exact messaging setup for a property.
Purpose: Review guest records and the stay context held with each recorded booking.
Inputs: Guest and stay details recorded with a booking.
Output: A place for the property team to review guest context before follow-up work.
Availability: The public tour shows fixture records only; the details available for a live property depend on its recorded bookings and permissions.
Purpose: Keep private team coordination and operating work separate from guest replies.
Inputs: Property-team work, private notes and recorded stay context.
Output: Internal context for handovers and follow-up work.
Availability: Private team communication is not a guest-delivery channel, and the fixture tour does not prove a live team workflow.
Purpose: Bring arrival, departure, tasks, requests and handovers into the property workspace.
Inputs: Recorded stays and the property team’s operating work.
Output: A shared view of work around the stay.
Availability: The fixture tour illustrates the interface, not a live property handover.
Purpose: Review revenue, occupancy, ADR, RevPAR and booking-performance trends.
Inputs: Recorded booking, channel and rate data within the property’s permission and date window.
Output: Performance measures for operating decisions.
Availability: These measures are not accounting profit or cash received, and forecasts are estimates rather than guarantees.
Purpose: Explore the interface intended for practical questions about current property work and data.
Inputs: The property context and data available to the enabled assistant.
Output: A response that supports human review and follow-up work.
Availability: The fixture tour does not prove a live AI result, and the assistant is not a replacement for human judgment, audited accounting or tax advice.
Purpose: Present configured rooms and hand a guest into a direct booking journey.
Inputs: An enabled property website, configured rooms, rates and availability.
Output: A guest-facing room-discovery and checkout path.
Availability: Direct checkout and website controls are enabled per property; payment collection requires the applicable payment setup.
Purpose: Keep payment results connected to the relevant booking context.
Inputs: An eligible property, configured payment methods and an external provider response where payment is collected.
Output: A recorded payment result alongside the reservation.
Availability: Methods, merchant activation and market eligibility vary; a provider can delay, reject or expire a payment.
Purpose: Review stored guest feedback and support post-stay follow-up.
Inputs: Connected and authorised review sources or enabled follow-up journeys.
Output: Review context and configured follow-up work for the team.
Availability: Source coverage, history and available actions vary by platform and property setup.
The demo uses sample data and changes are not saved. Ask Kiyo to confirm the exact channel and payment connections available for your property.
These steps separate what Kiyo publicly supports, what depends on a configured connection and what the public demo cannot verify.
Explicitly supported: direct, manually entered and supported OTA reservations can meet on the same Kiyo calendar. The exact provider connection must be active and correctly mapped.
Conditionally supported: eligible channel connections can receive availability, rates and supported stay rules after rooms and rate plans are mapped. Provider delays and errors can still occur.
Explicitly supported: the booking calendar and reservation record keep room, dates, booking status and related guest context together.
Conditionally supported: Booking.com, Airbnb and Expedia replies, plus configured WhatsApp Business, Telegram, Outlook, Messenger and Instagram accounts, can be handled inside Kiyo. Other OTA conversations may still require the channel extranet.
Explicitly supported: daily operations can bring arrivals, departures, tasks, requests and handovers into the property workspace.
Conditionally supported: cards, QRIS, e-wallets and virtual accounts depend on the property market, merchant activation and configured payment methods. Payment, reservation and payout status remain separate facts.
Explicitly supported: private notes and Kiyo Team Chat are kept separate from guest replies so internal handovers are not sent to the guest.
Reasonable interpretation: the stay can move through departure and checkout work, but the public demo does not prove a live end-to-end payment settlement or OTA update.
Explicitly supported: configured post-stay email journeys, guest feedback and review follow-up are described on Kiyo product pages.
Explicitly supported: revenue, occupancy, ADR, RevPAR, trends and room or channel performance can be viewed from property booking records.
No. The public demo is fixture-only and changes do not save. It must not be treated as proof that a live provider or payment account is connected.
The interactive application contains mock operational records and application controls. Kiyo keeps it out of search results while this crawlable tour explains the product in stable text.
No. A visible channel name, menu or image does not prove reservations, rates, restrictions, messages, reviews and payments are all supported. Verify each capability separately.
Confirm property eligibility, current rollout status, supported OTA operations, messaging coverage, payment activation, onboarding, support, data migration and the exact commercial terms.
Use Kiyo llms.txt for the canonical company briefing and sitemap.xml for the complete public URL inventory.
This website uses cookies and other technologies to analyse traffic, personalize content and ads, and improve our sites and services. By continuing to use this site, you agree to the use of these technologies as further described in our Privacy Policy.
