# Hotels, Resorts & Cruise — Otonoma The guest experiences one stay; the stack experiences eight bookings. Otonoma's network overlays hotel, resort and cruise systems so they act as one — running in the operator's own cloud, replacing nothing. ## The guest experiences one stay. The stack experiences eight bookings. Rooms, dining, spa, transport, entertainment and the front desk each run their own system, and a guest's day crosses all of them. The network overlays those systems — it replaces none — so they can finally act on each other, from the moment a guest shares a flight to the moment they leave. ## It isn't a staffing problem. It's an integration problem. At one landmark hotel we visited, the systems that run the building didn't talk to each other. The team bridged the gaps with printouts, verbal hand-offs, text messages and a row of browser tabs at the front desk. The data existed. The notifications didn't. - **Inside the house.** For a resort, the fragmentation is less between companies than inside the property: rooms, housekeeping, dining, spa, golf, retail and events, each on its own system — and now service robots, too. - **Off the property.** The car company, the restaurant down the street, the show, the airline — often a small firm with no link at all to the property management system. - **Bridged by people.** Every gap between systems is covered by someone's memory, a phone call or a spreadsheet. It works — until the day is busy, or the right person is off shift. ## Arrival: from a flight number to "you're checked in" *Illustrative scenario.* The guest shares a flight in an ordinary messaging thread. From then on, one node tracks it live, books the car against it, holds the room against release and checks the guest in. When the flight is ninety minutes late, the car, the room and the staff re-time themselves. For a very important person (VIP), the concierge team needs to know when the guest is ten minutes out — even when the car company is a small firm with no link to the property management system. The car firm joins the network as a node, spreadsheet and all. If the usual concierge is off that day, the workflow adapts to whoever is on shift. The goal tree: 1. Guest shares a flight number — one reply in the thread. 2. Flight 90 minutes late — tracked live from takeoff. 3. Car re-timed — the small car firm is now a node. 4. Room held, staff re-timed — housekeeping and the welcome team. 5. Ten minutes out — the concierge on shift meets the car (a decision sent to a person). 6. Walks in checked in — no queue at the desk. ## Smooth the stay. Fix it before they notice. *Illustrative scenarios. Hotels in our scenarios are independent properties; times are examples.* ### Many guests never really check out. They just leave. No one tells the hotel, so the room sits, housekeeping never gets the call, and the folio, the thank-you and the next booking don't happen. Instead, the night before, one question goes out in the thread: what time should we be ready? She is leaving early, around 5:30; the car and the bell desk are booked and a reminder goes out thirty minutes before. The moment she leaves, every system knows. Booked to leave at eleven, gone by half past five — the room reaches housekeeping hours earlier. ### "We didn't know the band was playing." As guests at one hotel, we missed live music in the lobby — a weekly fixture, listed on the hotel's own website — and went out for dinner. The network can see a guest's evening is open, knows what's on in the building and what the guest has enjoyed before, and — with the concierge's approval — sends one message that afternoon: the music, and a table downstairs afterwards. Revenue that stays in the building, arriving as service rather than a pitch. ### The room wasn't ready. The welcome was. A guest arrives two hours early after a run of late check-outs. The car service reports the early arrival; the concierge offers the lounge and takes the luggage; housekeeping's queue is re-ordered without disturbing other arrivals; and when the room is ready, the guest is told they're checked in. ## Meet guests in the thread they already use Hotel apps struggle to get used. Messaging doesn't ask guests for a new habit — it builds on one they already have. The higher-end the guest, the truer that gets: the most valuable guests already live in messaging and are the least likely to download another app. Text messaging, rich messaging and the chat apps guests already use reach everyone who can receive a message, with nothing to install. > Only 19% of guests had downloaded a hotel's app — and just 4% of check-ins happened in one. Source: J.D. Power 2017 North America Hotel Guest Satisfaction Index, a study of more than 63,000 guests, [as reported by the Professional Convention Management Association (PCMA)](https://www.pcma.org/new-study-shows-hotels-struggle-with-mobile-app-adoption/). ## Your cloud. Your guest data. Your keys. The first question an operator asks is where this runs and who holds the guest data. The answer is structural, not a promise. - **Overlay, never replace.** Nothing gets ripped out. The property management system, reservations, housekeeping, dining and the rest stay exactly where they are, on site or in the cloud. What changes is that they can act on each other. - **In your own cloud.** The node deploys into the operator's own cloud, beside the systems it orchestrates. Guest data never leaves your estate, and your team keeps the keys. The integrations you build are your intellectual property. - **Around regulated systems.** Regulated gaming systems and cardholder data are out of scope. We orchestrate around them, never through them. More: [Trust & guardrails](https://www.otonoma.com/trust) ## Crawl, walk, run — and the first step pays for itself inside one stay Be suspicious of anyone claiming the whole value pool on day one. The pools sit at different depths and need different permissions, so we start where the data is already on property and a win is measurable quickly. 1. **Crawl: guest operations.** Arrival orchestrated before the guest reaches the desk. Folio and checkout in the thread they already read. Dining and spa booked without a phone call. 2. **Walk: revenue and workforce.** Upsell that arrives as service rather than a pitch. Staff hours returned to the floor. Guest value tracked across stays, not just within one. 3. **Run: later, together.** Beyond guests and staff: property-wide pricing and inventory, supply chain, city partners and the wider network. Not where we start. Two first engagements that pay for themselves inside one stay: - **Arrival orchestration.** The guest shares a flight; the network tracks it, books the car, holds the room and checks them in, with anything ambiguous escalated to a named host. Measured in rooms held rather than released, transfers attached, and time at the desk. - **Departure, folio and late checkout.** The folio arrives in the thread, late checkout goes to the guests it suits, and nobody queues to settle a bill. Measured in staff minutes per departure, late-checkout take-up, and the queue at the desk. Then the arc: one property and a few systems, then more systems, then more properties, then out from the property into the city. ## Cruise: we know the sailing. Not the arrival. *Illustrative scenarios.* A voyage is a plan made weeks earlier by people who won't be aboard to fix it. It is close to perfect when the gangway comes up and wrong by the second night — not through anybody's fault, but because the systems aboard and ashore can't act on each other. ### Met at the car door, by name The line knows a VIP couple sails on Saturday, but not how they are getting to the pier — so the first thing they meet is a queue. Instead, two days out, one question in the thread: how are you arriving? One reply gives the flight and the car. The network watches the flight, links the car, and alerts the concierge when the car is ten minutes out. The first thing a VIP meets is a person, not a queue. ### Replaced, not refunded At a tender port the weather turns and the window closes at eleven; a popular excursion is lost or already sold out. The bridge's call reaches the excursion desk, the shore operator and dining at once. Comparable tours from local operators the line already works with have seats, and each affected guest gets an alternative in the thread, held for them. Replaced, not refunded — and the guest was never sold to. ### Ship and shore, federated Every system a ship needs runs aboard, and the ship spends much of its life with a thin or broken link to shore. So the ship gets its own node in the hull, headquarters gets one in the cloud, and operators ashore get their own. There is no central server and no shared database. - The ship decides locally when the satellite link drops, and reconciles when it comes back. - The network overlays what is aboard and ashore — the shipboard property system, reservations and guest records stay where they are. - Hotel and guest operations only. Navigation, propulsion and engine systems stay on their own isolated network; we don't go near them. ## Work with us One stay, as the guest experiences it — with your people at the center. We are working with a small number of hotels, resorts and cruise operators to build it. Several prototypes are in operation today. - [Request a demo](https://www.otonoma.com/demo-request) - [Contact us](https://www.otonoma.com/contact) - [Travel & Hospitality overview](https://www.otonoma.com/travel)