> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Build the guest journey for travel and hospitality

> A vertical walkthrough that composes booking confirmations, check-in prompts, RCS itinerary change cards, multilingual concierge WhatsApp, pre-arrival voice, and post-stay surveys into one guest timeline, in build order.

# Build the guest journey for travel and hospitality

You run guest communications for a hotel group or a travel brand. A guest books on the web, gets a flight change mid-trip, asks the concierge for a dinner reservation in their own language, and leaves a review after checkout. Each of those moments lands on a different channel today, and your front desk re-assembles the story by hand. This guide composes the pieces Devotel Orbit ships for the guest journey (the journey builder, RCS itinerary cards, multilingual WhatsApp templates, cross-channel continuation, pre-arrival voice, and post-stay surveys) into one reference, in the order you should build them.

Each part has its own deep guide. This page is the program-level order of work; if you only need one mechanic, start from the linked guide.

> [!WARNING]
>
> This guide describes Devotel Orbit platform controls. It is **not legal
> advice.** The consent basis per message class, the quiet-hours policy per
> market, and the urgency exception you grant to itinerary changes are
> tenant-owned decisions: you choose them, you operate them, and your
> counsel reviews them.

## 1. Split the transactional lane from the promotional lane

Guest messaging fails on consent bookkeeping before it fails on delivery. Draw the lane line before you build anything:

| Lane | Examples | Consent basis |
| - | - | - |
| Transactional | Booking confirmation, check-in prompt, itinerary change, service recovery | The booking relationship and the channel opt-in the guest gave at booking |
| Promotional | Pre-arrival upsell, spa offers, loyalty pushes, win-back | Explicit marketing opt-in per channel |

Keep the lanes separate in your workspace: separate audiences, separate senders where your sender registrations differ, and separate message classes in [consent and suppression](https://docs.orbit.devotel.io/compliance/consent-management.md), so a guest who opted out of marketing still receives the room-change notice. The split is yours to draw; the platform enforces the classes you configure at send time.

Quiet hours follow the same split. Set guest-local quiet hours per market with [quiet-hours configuration](https://docs.orbit.devotel.io/guides/quiet-hours-configuration.md), and decide which events are urgent enough to cross them. A workable default: promotional sends always wait for the window, while an itinerary change that affects tonight's stay (flight rebooking, room move, cancellation notice) is classified transactional-urgent and sends immediately. A spa discount is not urgent. Write that policy into your class configuration, not into a per-send judgement.

## 2. Booking confirmation and check-in prompt journey

Build the backbone on the [journey builder](https://docs.orbit.devotel.io/guides/campaign-journey-builder.md) with [segment-triggered journeys](https://docs.orbit.devotel.io/guides/segment-triggered-journeys.md):

```text theme={null}
booking.confirmed → confirmation (guest channel of record)
                    ├─ check-in window opens (T-24h) → check-in prompt (CONFIRMED / LATE)
                    │     ├─ CONFIRMED → checked_in event → pre-arrival voice (§5)
                    │     ├─ LATE → late-checkout offer (promotional lane, consent-gated)
                    │     └─ no reply → one reminder at T-4h, then end
                    └─ itinerary.change event → §3
```

Rules that keep it defensible:

* Emit one event per stay-state change (`booking.confirmed`, `checked_in`, `itinerary.change`, `checked_out`) from your property-management system with a stable `stay_id`, and key every condition on it so a rebooked stay is never reminded by the old run.
* Keep the keyword set to two words. Every extra keyword is a misspelling you will support.
* The confirmation goes to the channel of record from the booking; do not move a guest to WhatsApp on the first touch without their WhatsApp opt-in.

## 3. Itinerary change as an RCS rich card, with SMS fallback

When `itinerary.change` lands, send the change as an [RCS rich card](https://docs.orbit.devotel.io/guides/rcs-rich-card-builder.md): the new dates or gate, and the actions the guest can take (Confirm the change, View the new itinerary, Call the front desk). With [SMS to RCS upgrade](https://docs.orbit.devotel.io/guides/sms-to-rcs-upgrade.md), capable devices receive the card on the same number you already use for SMS.

Wire the [fallback chain](https://docs.orbit.devotel.io/guides/fallback-chains.md) so a device that cannot render RCS gets a plain SMS with the same confirmation keyword and a short link to the itinerary. Two rules:

* The fallback is a new send: it passes the same consent, quiet-hours, and suppression checks as the card, in the same transactional class.
* Key the card and its fallback to the same `stay_id`, so a guest who confirms on SMS ends the RCS retry and a guest who confirms in the card never gets the SMS.

## 4. Multilingual concierge on WhatsApp, with front-desk handoff

Set the channel up with [WhatsApp getting started](https://docs.orbit.devotel.io/guides/whatsapp/getting-started.md), then let [template auto-localization](https://docs.orbit.devotel.io/guides/template-auto-localization.md) render each concierge template in the guest's locale from their profile, with your default locale as the fallback when the profile has none. The guest replies free-form in their language and the conversation stays on WhatsApp.

When a request needs a human (a billing dispute, a special accommodation, anything the guest asks twice), hand the thread to the front desk with [Inbox setup](https://docs.orbit.devotel.io/guides/inbox-setup.md): the masked conversation, the guest profile, and the stay context arrive as one queue item an agent can act on without asking the guest to repeat anything. Because Orbit continues a conversation across channels, a guest who starts on WhatsApp and calls from the lobby the next day lands on the same timeline: [continue conversations across channels](https://docs.orbit.devotel.io/guides/continue-conversation-across-channels.md). That single timeline is the buyer problem named in the [industries overview](https://docs.orbit.devotel.io/guides/industries-overview.md), and it is the part your front desk will feel first.

## 5. Pre-arrival voice confirmation and itinerary IVR

For stays you want confirmed by voice (group bookings, high-season arrivals, airport pickups), add a pre-arrival call from [your first outbound voice call](https://docs.orbit.devotel.io/guides/first-outbound-voice-call.md) with an [IVR flow](https://docs.orbit.devotel.io/guides/build-ivr-flow.md):

* Press 1 to confirm the arrival time.
* Press 2 to hear the itinerary read back (room type, pickup time, special requests).
* Press 0 for a front-desk callback.

Capture the digit outcome as an event on the same `stay_id` (`voice.confirmed`, `voice.callback_requested`) so the journey can end the SMS reminders for voice-confirmed guests and open a ticket for callback requests. Schedule calls inside the calling window your market allows and plan around the platform's outbound voice guard window rather than against it.

## 6. Post-stay survey on its own consent basis

After `checked_out`, the stay relationship is over and the consent math changes. Run the survey as its own class with its own basis in [consent and suppression](https://docs.orbit.devotel.io/compliance/consent-management.md): booking consent bought you the stay conversation, not a feedback request. Then pick the capture per guest:

* [Surveys and voice-of-customer](https://docs.orbit.devotel.io/guides/surveys-voc.md) for the one-question SMS or WhatsApp flow, sent inside quiet hours and capped at one per stay, never re-sent on non-response.
* [Post-call surveys](https://docs.orbit.devotel.io/guides/post-call-surveys.md) for one-touch IVR capture when the stay included a voice interaction (a callback or a concierge call), attached to the same `stay_id`.

Treat responses as guest data with the retention posture you chose for the rest of the journey.

## 7. Monitoring, rollout, and troubleshooting

Watch the journey the way you watch any flow: per-message outcomes in the [delivery log](https://docs.orbit.devotel.io/guides/delivery-log.md) (sent, delivered, read, fallback fired), and step-by-step conversion plus dead ends in [flows analytics](https://docs.orbit.devotel.io/guides/flows-analytics-reading.md). Two readings pay for themselves weekly: the RCS-to-SMS fallback ratio (a sudden rise means a device-coverage or sender change, not a change in guest behaviour) and the no-reply rate on the T-24h check-in prompt (the knob that decides whether the T-4h reminder earns its send).

### Rollout checklist

The canonical sequence is the [production go-live checklist](https://docs.orbit.devotel.io/guides/go-live-checklist.md); this is the travel annotation of it:

| Go-live area | Travel addition |
| - | - |
| Sandbox sign-off | Run the booking, itinerary-change, and survey paths against sandbox numbers, including the RCS fallback and no-reply branches. |
| Sender readiness | SMS senders registered for both lanes; WhatsApp templates approved in every locale you serve; RCS enabled on the SMS sender. |
| Webhooks | Stay-state events signed, idempotent, and deduplicated on `stay_id`. |
| Guardrails | Guest-local quiet hours set per market, the urgency exception written into class configuration, frequency caps set for the promotional and survey lanes, suppression lists loaded. |
| Handoff | Inbox queue staffed for WhatsApp handoffs and voice callback requests; cross-channel stitching verified for one test guest on two channels. |
| Ops | Weekly delivery-log and flows-analytics reading; the fallback ratio reviewed as an incident queue. |

### Troubleshooting

| Symptom | Check |
| - | - |
| Itinerary card falls back to SMS for most guests | Review device coverage and sender enablement in [SMS to RCS upgrade](https://docs.orbit.devotel.io/guides/sms-to-rcs-upgrade.md); confirm the fallback SMS carries the same keyword and the same lane class in [fallback chains](https://docs.orbit.devotel.io/guides/fallback-chains.md). |
| WhatsApp concierge template undelivered in one locale | Check template approval status and locale coverage in [template auto-localization](https://docs.orbit.devotel.io/guides/template-auto-localization.md); confirm the default locale is set for profiles without one. |
| A checked-in guest still gets the T-4h reminder | Confirm the `checked_in` event carries the same `stay_id` as the booking event and the reminder condition exits on it. |
| Guest replies on another channel and the desk sees a new thread | Verify cross-channel continuation is enabled for the channels involved ([continue conversations across channels](https://docs.orbit.devotel.io/guides/continue-conversation-across-channels.md)) and both numbers resolve to the same contact. |
| A promotional offer sent inside quiet hours | The send was classified outside the promotional class; review the lane split in [consent and suppression](https://docs.orbit.devotel.io/compliance/consent-management.md) rather than widening the urgency exception. |
| Pre-arrival call never connects | Check the schedule against the calling window and the callback digit routing in [build an IVR flow](https://docs.orbit.devotel.io/guides/build-ivr-flow.md). |
| Survey replies are empty | One question, sent once, inside quiet hours; confirm the survey class has its own consent basis in [consent and suppression](https://docs.orbit.devotel.io/compliance/consent-management.md). |

## See also

* [Industries overview: Travel & hospitality](https://docs.orbit.devotel.io/guides/industries-overview.md)
* [Travel and hospitality messaging buyer explainer](https://docs.orbit.devotel.io/blog/travel-hospitality-messaging-buyer-explainer-2026)
* [Devotel Orbit for travel and hospitality](https://orbit.devotel.io/en/travel-hospitality)
* [Journey builder](https://docs.orbit.devotel.io/guides/campaign-journey-builder.md)
* [RCS rich card builder](https://docs.orbit.devotel.io/guides/rcs-rich-card-builder.md)
* [Continue conversations across channels](https://docs.orbit.devotel.io/guides/continue-conversation-across-channels.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.