Post-booking is the trust product
Checkout wins one transaction. What you do during a schedule change, a cancellation and a refund decides whether there is a second one.
Nobody has ever chosen a travel brand because the checkout was smooth. People leave one because a refund went quiet for a week and then an agent asked them to forward the confirmation email that the brand’s own system had sent them.
Almost every travel product is staffed as though the opposite were true. Search, selection and checkout get three teams, a conversion dashboard and a weekly experiment calendar. Everything after the confirmation screen gets a shared inbox and a policy document. The graph rises toward conversion and the customer, organisationally, disappears.
The traveller’s experience is only beginning. Between booking and fulfilment, suppliers move schedules, plans change, documents have to be found and money sometimes has to reverse direction. The brand that made the sale becomes most visible at exactly the moment its original promise is under pressure.
Post-booking is not a support appendix. It is the trust product. Checkout is the invoice.
Trust is legibility, not apology
Customers do not expect a travel company to control the weather, an airline’s operation or a hotel’s overbooking decisions. They expect it to know what happened and to make the next step clear.
In an exception, trust comes from five answers:
- State: what is confirmed, changed, pending or cancelled?
- Consequence: which parts of the trip are affected?
- Choice: what can the traveller do now?
- Money: what will be charged or returned, and what is still pending?
- Ownership: who is taking the next action?
An apology that ships without those five answers is decoration. A plain, unstyled screen that carries all five feels remarkably calm. Tone is the last thing to work on, not the first.
A booking is not a receipt
A receipt is static. A travel order is a living record holding several supplier commitments, multiple travellers, payment movements and independent fulfilment states, every one of which can change without anyone at your company touching a keyboard.
Systems that store the order as the frozen output of a checkout form pay for that later, usually in the support tool. Model it as a lifecycle instead: stable identifiers, component-level status, a chronological event history, the terms accepted at purchase, and a link from every service action to its financial consequence. Keep the current truth and the path that produced it.
OnArrival’s platform treats booking as a lifecycle spanning discovery, transaction, service and settlement. That framing matters because a change is never an isolated support action. It mutates the same object that powers the itinerary, the notifications, the supplier instructions and the finance records. The travel order lifecycle guide describes that state model in detail.
Rehearse the unhappy paths first
Feature lists are how post-booking gets sold. Scenarios are how you find out whether it exists. Pick real journeys and walk them end to end with the people who will own them at 2am.
| Scenario | Product must explain | System must coordinate |
|---|---|---|
| Supplier changes a flight time | New time, affected connection, available choices | Event ingestion, order update, re-shop or escalation |
| Traveller cancels a hotel | Penalty, refund amount, remaining trip | Policy interpretation, supplier cancellation, ledger update |
| One bundle component fails | What is still confirmed and what happens next | Component states, rollback or recovery, communication |
| Refund is in progress | Amount, method, current stage and next expectation | Supplier recovery, payment movement, reconciliation |
| Traveller changes one passenger | Eligibility, price difference and documents | Supplier rules, order mutation, payment and audit trail |
The bundle-failure row deserves the most respect and usually gets the least. When one component fails after the others have already committed, recovery is a compensation saga across suppliers who never agreed to coordinate, and the travel cart essay walks that commit-and-compensate sequence step by step. Post-booking inherits whatever the commit left behind, so both have to write to the same journal.
The goal is not to automate every edge case. It is that no edge case can exist without a safe state, a visible owner and a route forward.
A supplier webhook is not a customer experience
It is an input. Between the webhook and the traveller sits the work most teams underbuild: deduplicate repeated messages, preserve ordering where it matters, attach the event to the correct booking component, then let policy decide whether to notify, offer self-service, act automatically or open a human task.
For flights, OnArrival describes schedule-change webhooks and ranked re-accommodation options in the Flights product. Receiving the change is the easy half. The valuable half is binding it to an order state the customer can act on. A well-formed event carries everything that binding needs:
{
"event_id": "evt_5c90a1",
"type": "schedule.changed",
"sequence": 3,
"occurred_at": "2026-08-03T04:18:00Z",
"order_id": "ord_82f4c7",
"item_id": "itm_flight_outbound",
"change": {
"segment": "BLR-DXB",
"old_departure": "2026-08-21T08:05+05:30",
"new_departure": "2026-08-21T11:40+05:30",
"delta_minutes": 215
}
}The event_id powers deduplication, sequence restores order when retries arrive backwards, and the order_id and item_id pair pins the change to the exact component whose fare rules and policy apply. From there, the path from webhook to updated order should be short and inspectable:
Bound the automation on purpose. A low-risk update can be accepted by policy; a multi-segment itinerary with an ambiguous supplier response needs a person. Both paths read the same event history, so the human does not begin by reconstructing the trip from screenshots.
A button that might work is worse than no button
Customers want control. They do not want a lever with an unknown outcome. Before exposing an action, the product has to know:
- Whether the action is allowed right now
- The exact or bounded financial effect
- Which trip components it changes
- Whether confirmation is immediate or asynchronous
- What happens when the supplier times out
- How the action retries without running twice
That last one is not a nicety. Change, cancel and refund have to be idempotent: a nervous double tap on a train with bad signal must not cancel the hotel twice.
Where certainty is not available, say so and create an inspectable pending state. Honest waiting beats false confirmation, and it costs one contact instead of three.
Support needs a cockpit, not another inbox
If an agent has to ask the traveller to forward the confirmation, the support tool cannot read the order. That is an architecture problem wearing a training problem’s clothes.
The workspace should hold the order’s state, timeline, traveller messages, supplier references and money movements in one view. A good handoff from automation to a person carries:
- Why automation stopped
- Actions already attempted and the responses they returned
- Allowed next actions and the policy behind them
- The customer’s latest choice
- Time sensitivity and downstream trip dependencies
- A named owner and a resolution status
This is where product and operations stop being separate functions. Every repeated manual pattern is a specification for a policy, a tool or a self-service flow. Every automated path stays observable by the people accountable for its outcome.
“Refunded” is five different facts
It can mean a supplier approved it, a ledger entry exists, a payment instruction went out, or the customer’s bank finally displayed the credit. Collapsing those into one word is how a resolved refund turns into three more contacts.
Use states that match what the system actually knows. Attach the refund to the original order and payment. Show the amount, the destination and any component-level penalty. Tell the customer when the state changes, not only when the process begins.
| Refund state | What the system knows | What the customer should see |
|---|---|---|
calculated | Policy produced an amount and a penalty | The exact figure, before they commit |
approved | Supplier or policy agreed to return it | Amount, destination and expected timeline |
instructed | A payment instruction was submitted | “Sent to your original payment method” with a date |
settled | The processor confirmed the movement | Completion, with a reference they can quote |
failed | The instruction bounced | A concrete next step, never a dead end |
The travel-aware model on the Payments page connects customer collection, supplier settlement, refunds and reconciliation. Shared context is the whole point: support should never promise money that finance cannot trace. For the mechanics, continue to One booking, many money movements.
Deflection is the wrong metric
Deflection scores a customer who gave up exactly the same as a customer you helped. Self-service rate has the same blind spot. Both of them look excellent during the week your manage-booking page is broken.
Measure resolution instead:
- Time from supplier event to customer-visible state
- Share of exceptions with a named next action
- Completion rate by service action
- Repeat contacts on the same order and issue
- Time spent in ambiguous or pending states
- Refund state agreement across product and finance systems
- Manual interventions caused by missing context
Then review the failures as product work, not agent coaching. Most of what gets filed as a support quality problem is a state model that could not answer question two.
The post-booking readiness checklist
Before calling a travel experience production-ready, verify that:
- Every booking component has a current, inspectable status.
- Supplier events are retried, deduplicated and attached to the order.
- The customer can reach manage-booking from the itinerary and the confirmation.
- Cancellation and change consequences appear before commitment.
- Pending actions cannot vanish between automated and human queues.
- Support sees the same state the customer sees, plus the event history.
- Refund states correspond to real money states.
- Reduced connectivity and travel-day use have been considered.
- Communications state the next action, not just the problem.
Acquisition earns attention. Checkout earns revenue. Resolution earns permission to be chosen again.
