Hotels, resorts & cruise

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.

Request a Demo

The problem

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 · goal tree

From a flight number to “you’re checked in.”

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.

Guest shares a flight number
One reply in the thread
Flight 90 minutes late
Tracked live from takeoff
Car re-timed
Small car firm, now a node
Room held, staff re-timed
Housekeeping and welcome team
Person
Ten minutes out
Concierge on shift meets the car
Walks in checked in
No queue at the desk
Complete Waiting Alert Person = a decision sent to a human

Illustrative scenario.

Across the stay

Smooth the stay. Fix it before they notice.

The same machinery that runs the arrival runs the rest of the stay — one thread, one message, at a moment the guest can still act on it.

Departure

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.

  1. The night before, one question in the thread: what time should we be ready?
  2. She’s leaving early, around 5:30. The car and the bell desk are booked.
  3. A reminder goes out thirty minutes before.
  4. The moment she leaves, every system knows.

Booked to leave at eleven, gone by half past five — the room reaches housekeeping hours earlier.

An open evening

“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. We were standing in the building and still missed it.

  1. The network sees the guest’s evening is open.
  2. It knows what’s on in the building tonight, and what the guest has enjoyed before.
  3. The concierge approves the suggestion.
  4. One message that afternoon: the music, and a table downstairs afterwards.

Revenue that stays in the building — arriving as service, not a pitch.

An early arrival

The room wasn’t ready. The welcome was.

A guest is arriving two hours early after a run of late check-outs. Their room won’t be ready on time.

  1. The car service reports the early arrival.
  2. The concierge offers the lounge and takes the luggage.
  3. Housekeeping’s queue is re-ordered without disturbing other arrivals.
  4. When the room is ready, the guest is told they’re checked in.

Something went wrong — and the guest remembers how well it was fixed.

Illustrative scenarios. Hotels in our scenarios are independent properties; times are examples.

No app to download

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 have open 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.
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).

Where it runs

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 — and they stay exactly where they are.

Trust & guardrails →

How to start

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.

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.

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.

Run: later, together

Beyond guests and staff: property-wide pricing and inventory, supply chain, city partners and the wider network. Not where we start.

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.

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.

The Miami skyline at sunset, seen from a cruise terminal across the water
Photo: Joe deSousa, CC0

Embarkation day

Met at the car door, by name.

The line knows a VIP couple sails on Saturday. It doesn’t know how they are getting to the pier — so the first thing they meet is a queue.

  1. Two days out, one question in the thread: how are you arriving?
  2. One reply: the flight, and the car already booked.
  3. The network watches the flight and links the car.
  4. Ten minutes out, the concierge is alerted and meets the car.

The first thing a VIP meets is a person, not a queue.

A tender port · the weather turns

Replaced, not refunded.

The tender window closes at eleven. Guests hold tickets ashore, and a popular excursion is lost to the weather or already sold out.

  1. The bridge’s call reaches the excursion desk, the shore operator and dining at once.
  2. Comparable tours from local operators the line already works with have seats.
  3. Each affected guest gets an alternative in the thread, held for them.
  4. Tenders, dining and crew re-plan around the new day.

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.

  • Decides locally when the satellite link drops, and reconciles when it comes back.
  • 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.

Illustrative scenarios.

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 Talk to us →