Skip to main content

​
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.
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: Keep the lanes separate in your workspace: separate audiences, separate senders where your sender registrations differ, and separate message classes in consent and suppression, 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, 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 with segment-triggered journeys:
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: 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, capable devices receive the card on the same number you already use for SMS. Wire the fallback chain 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, then let template auto-localization 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: 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. That single timeline is the buyer problem named in the industries overview, 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 with an IVR flow:
  • 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: booking consent bought you the stay conversation, not a feedback request. Then pick the capture per guest:
  • Surveys and voice-of-customer 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 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 (sent, delivered, read, fallback fired), and step-by-step conversion plus dead ends in flows analytics. 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; this is the travel annotation of it:

​
Troubleshooting

​
See also