Travel & Hospitality · Playbook
The travel and hospitality playbook. Built in the builder, answered by your booking and loyalty systems.
Ten journeys, each drawn below as it runs. The decision comes from your reservation, property and loyalty systems or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Offer the upgrade the night it is free.
A confirmed booking with arrival tomorrow asks your property system whether a better room is free and the guest is not already upgraded, then sends one WhatsApp with Upgrade or Keep my room; a tap books it in your system.
- Decides
- your property system and the rate you set.
- Aim
- empty rooms sold without a call from the desk.
Built in the journey builder
Offer the upgrade the night it is freeTRAVEL & HOSPITALITYYour property system answers before any guest is offered a room.
Campaign Start · APIArrival tomorrow (from your PMS)
API CallBetter room free tomorrow? Ask your PMS
Free, not upgraded
Nothing free
WhatsApp FlowWhatsApp: Upgrade / Keep my room
Upgrade
Keep my room
No reply
API CallYour PMS books the upgrade
Message · WhatsAppConfirmation, new room on the booking
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- empty rooms sold without a call from the desk.
- Trigger
- arrival tomorrow (your PMS)
- Events and identifiers
- arrival tomorrow (your PMS). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- better room free? not upgraded? (your PMS) · your PMS books it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- empty rooms sold without a call from the desk. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 02Illustrative journey
Turn three searches into one booking.
A session with the same route searched three times and no booking checks consent, asks your system for the fare now, and sends one WhatsApp with a tap to book; one reminder if the fare is about to change, and silence otherwise.
- Decides
- your fare rules.
- Aim
- searches that end in a booking with you, not elsewhere.
Built in the journey builder
Turn three searches into one bookingTRAVEL & HOSPITALITYA session rule, a consent check, the fare your system quotes now, one reminder before it changes.
Campaign StartSame route searched 3 times, no booking
Check Channel ConsentCheck WhatsApp consent
API CallFare now, from your system
WhatsApp FlowWhatsApp with a tap to book
Tapped
No reply
Event CheckBooked?
Yes
No
Message · WhatsAppOne reminder before the fare changes
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- searches that end in a booking with you, not elsewhere.
- Trigger
- session rule: same route 3 times, no booking
- Events and identifiers
- session rule: same route 3 times, no booking. Captured by the SDK or web tracker as the session runs, tied to the identified contact. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- fare now (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- stop when booked. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- searches that end in a booking with you, not elsewhere. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 03Illustrative journey
Sell the bag on the booking, not the calendar.
A long-haul booking with no bag added asks your system whether bag space is free, then sends one WhatsApp with Add a bag or No thanks; a tap adds it to the booking and confirms.
- Decides
- your system and the ancillary price you set.
- Aim
- ancillaries sold before the airport, not at the desk.
Built in the journey builder
Sell the bag on the booking, not the calendarTRAVEL & HOSPITALITYYour system confirms the space before the bag is offered; the same shape sells the lounge and the late checkout.
Campaign Start · APILong-haul booked, no bag (your system)
API CallBag space free? Ask your system
Free
Full
WhatsApp FlowWhatsApp: Add a bag / No thanks
Add a bag
No thanks
No reply
API CallYour system adds it to the booking
Message · WhatsAppConfirmation
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- ancillaries sold before the airport, not at the desk.
- Trigger
- long-haul booked, no bag added (your system)
- Events and identifiers
- long-haul booked, no bag added (your system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- bag space free? (your system) · your system adds it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: the journey ends. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- ancillaries sold before the airport, not at the desk. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 04Illustrative journey
Get the guest checked in before they reach the airport.
Check-in opening sends a push and Inbox message, waits six hours, asks your system whether the guest has checked in, and sends the link by WhatsApp if not, with SMS for the unread.
- Decides
- your system's check-in status.
- Aim
- shorter queues at the desk, fewer missed flights.
Built in the journey builder
Get the guest checked in before they reach the airportTRAVEL & HOSPITALITYA push when check-in opens, a wait, a check with your system, then the link on the guest's channel.
Campaign Start · APICheck-in opens (from your system)
Push + InboxPush and Inbox: check in now
Wait TimeWait six hours
API CallChecked in? Ask your system
Yes
No
End
WhatsApp FlowWhatsApp with the check-in link
Tapped
No reply
End
Message · SMSSMS with the same link
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- shorter queues at the desk, fewer missed flights.
- Trigger
- check-in opens (your system)
- Events and identifiers
- check-in opens (your system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- checked in? (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- yes: stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- shorter queues at the desk, fewer missed flights. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 05Illustrative journey
Give a disrupted guest the options, not a queue.
A delay past your threshold sends the options as buttons; the guest's choice goes to your system to rebook or refund and the confirmation follows on the same thread. No reply, and the journey calls.
- Decides
- your system; the guest.
- Aim
- fewer calls in a disruption, with guests answered inside the window you set.
Built in the journey builder
Give a disrupted guest the options, not a queueTRAVEL & HOSPITALITYThe guest chooses; your system rebooks or refunds; nobody dials.
Campaign Start · APIDelay past two hours (from your ops)
WhatsApp FlowWhatsApp: Next flight / Refund
Next flight
Refund
No reply
API CallYour system rebooks
Message · WhatsAppNew boarding pass
End
API CallYour system refunds
Message · WhatsAppRefund confirmed
End
IVR CallVoice call with the options
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- fewer calls in a disruption, with guests answered inside the window you set.
- Trigger
- delay past two hours (your ops)
- Events and identifiers
- delay past two hours (your ops). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- your system rebooks or refunds. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- fewer calls in a disruption, with guests answered inside the window you set. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 06Illustrative journey
Keep the tier before it lapses.
A tier that ends in thirty days asks your loyalty system how far short the guest is, sends one message that says what keeps the status, waits, checks for the booking, and reminds once with ten days left.
- Decides
- your loyalty rules and the tier date your system holds.
- Aim
- tiers renewed by a stay, not by a soft landing.
Built in the journey builder
Keep the tier before it lapsesTRAVEL & HOSPITALITYYour loyalty system names the gap; one message, one wait, one reminder, and the outcome written back.
Campaign Start · APITier lapses in 30 days (your loyalty system)
API CallHow far short? Ask your loyalty system
One stay short
Already kept
Message · WhatsAppOne message: what keeps the tier
Wait TimeWait 20 days
Event CheckStay booked?
Yes
No
End
Message · WhatsAppOne reminder, ten days left
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- tiers renewed by a stay, not by a soft landing.
- Trigger
- tier lapses in 30 days (your loyalty system)
- Events and identifiers
- tier lapses in 30 days (your loyalty system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- one stay short? (your loyalty system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- tiers renewed by a stay, not by a soft landing. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 07Illustrative journey
Catch the guest whose stays are getting further apart.
A guest entering At Risk on your stay windows gets one message from the brand, not an offer; a reply becomes a task for guest relations, and silence waits sixty days before Lost.
- Decides
- your RFM windows.
- Aim
- the drifting guest heard from before the next trip is booked elsewhere.
Built in the journey builder
Catch the guest whose stays are getting further apartTRAVEL & HOSPITALITYOne message from the brand, not an offer; a reply reaches a person.
Segment EntryRFM At Risk, on your stay windows
Message · InboxOne message from the brand, not an offer
Reply
No reply
API CallTask to guest relations (your system)
End
Wait TimeWait 60 days
Segment EntryRFM Lost
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- the drifting guest heard from before the next trip is booked elsewhere.
- Trigger
- segment entry: RFM At Risk (your windows)
- Events and identifiers
- segment entry: RFM At Risk (your windows) · RFM Lost. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- yes: task to guest relations (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- the drifting guest heard from before the next trip is booked elsewhere. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 08Illustrative journey
Bring back the guest with no stay in a year.
A guest entering Lost has their last stay and property looked up in your system, then gets one Story on what has changed there, and an offer on their channel only if they read it.
- Decides
- your RFM definitions and your offer rules.
- Aim
- a return stay, asked for once.
Built in the journey builder
Bring back the guest with no stay in a yearTRAVEL & HOSPITALITYA look-up of the last stay, then one Story, then an offer only if they read it.
Segment EntryRFM Lost: no stay in twelve months
API CallLast stay and property? Ask your system
StoryStory on what changed since their stay
Event CheckRead?
Yes
No
Message · WhatsAppOffer on their channel
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- a return stay, asked for once.
- Trigger
- segment entry: RFM Lost
- Events and identifiers
- segment entry: RFM Lost. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- last stay and property? (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- a return stay, asked for once. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 09Illustrative journey
Hear about a bad stay before the review site does.
Checkout asks for a rating with buttons; a low score becomes a task for the property in your system and an apology on the same thread, a high one gets a thank-you and a link.
- Decides
- the reply; your service rules.
- Aim
- the complaint heard by you first.
Built in the journey builder
Hear about a bad stay before the review site doesTRAVEL & HOSPITALITYOne rating by button; a low score reaches the property the same morning.
Campaign Start · APICheckout (from your PMS)
WhatsApp FlowWhatsApp: How was your stay? 1 to 5
1 to 3
4 or 5
No reply
API CallTask to the property (your system)
Message · WhatsAppApology, and a person follows up
End
Message · WhatsAppThank you, with a link
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- the complaint heard by you first.
- Trigger
- checkout (your PMS)
- Events and identifiers
- checkout (your PMS). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- low: task to the property (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- the complaint heard by you first. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 10Illustrative journey
Say the gate or the room is ready, privately.
A ready event goes by push and Inbox to app users over our own network, with SMS for anyone who has not read it; guests without the app get the SMS straight away.
- Decides
- your channel order, per message type.
- Aim
- fewer desk queues, and the notice read where it was sent.
Built in the journey builder
Say the gate or the room is ready, privatelyTRAVEL & HOSPITALITYPush and Inbox over our own network for app users; SMS for the unread; one record per message.
Campaign Start · APIGate change or room ready (your system)
ConditionApp user?
Yes
No
Push + InboxPush and Inbox over our own network
Delivery StatusRead in ten minutes?
Yes
No
End
Message · SMSSMS for the unread
End
Message · SMSSMS
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- fewer desk queues, and the notice read where it was sent.
- Trigger
- gate change or room ready (your system)
- Events and identifiers
- gate change or room ready (your system). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- one record per message. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- fewer desk queues, and the notice read where it was sent. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
Where a step says your system decides, the journey calls your system and branches on its answer. xNotify carries the journey; it does not become the model.