Post-booking is the trust product
Checkout wins a transaction. What happens during a change, cancellation or refund decides whether the customer will trust you with the next trip.
Travel products are often designed as funnels. Search becomes selection, selection becomes checkout, and checkout becomes a confirmation screen. The graph rises toward conversion and then, organisationally, the customer disappears.
The traveller’s experience is only beginning.
Between booking and fulfilment, suppliers change schedules, plans evolve, documents need to be found and money may need to reverse direction. The brand that made the sale becomes most visible when the original promise is under pressure.
That is why post-booking is not a support appendix. It is the trust product.
Trust is created by legibility
Customers do not expect a travel company to control the weather, an airline’s operation or every hotel decision. They do expect the company to know what happened and to make the next step clear.
In an exception, trust comes from five forms of legibility:
- 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?
A polished apology without these answers is decoration. A plain interface with them can feel remarkably calm.
A booking is not a receipt
A receipt is static. A travel order is a living record that can contain several supplier commitments, travellers, payment movements and fulfilment states.
Model the order accordingly. It needs stable identifiers, component-level status, a chronological event history, the terms accepted at purchase, and links between each service action and its financial consequence. The system should preserve both current truth and how it arrived there.
OnArrival’s platform treats booking as a lifecycle spanning discovery, transaction, service and settlement. That framing matters because a change is not an isolated support action. It updates the same object that powers the itinerary, notifications, supplier instructions and finance records. The travel order lifecycle guide describes that underlying state model in detail.
Design the unhappy paths first
Post-booking quality is easiest to judge with scenarios, not feature lists. Choose real journeys and rehearse them end to end.
| 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 particular respect. When one component fails while others have already committed, recovery is a compensation saga across suppliers, and the travel cart essay walks that commit-and-compensate sequence step by step. Post-booking inherits whatever the commit leaves behind, so both need to write to the same journal.
The purpose is not to automate every edge case. It is to ensure every edge case has a safe state, a visible owner and a route forward.
Events should become decisions
A supplier webhook is not a customer experience. It is an input.
An effective event pipeline deduplicates repeated messages, preserves ordering where it matters and attaches the event to the correct booking component. Then policy decides whether to notify, offer self-service, take an automatic action or create a human task.
For flights, OnArrival describes schedule-change webhooks and ranked re-accommodation options in the Flights product. The valuable part is not merely receiving the change. It is connecting that change to an actionable order state. A well-formed event carries everything that attachment 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 pipeline is a short, inspectable path from webhook to updated order:
Good automation is bounded. A low-risk update might be accepted by policy. A complex itinerary or ambiguous supplier response may require a person. Both paths should use the same event history, so the human does not begin by reconstructing the trip.
Self-service needs a confidence boundary
Customers value control, but a button is not self-service if the outcome is uncertain.
Before exposing an action, the product should know:
- Whether the action is allowed now
- The exact or bounded financial effect
- Which trip components it changes
- Whether confirmation is immediate or asynchronous
- What happens if the supplier times out
- How the action can be retried without running twice
That last point matters. Change, cancel and refund operations should be idempotent: a nervous double tap or network retry must not create a second action.
When certainty is not available, the interface should say so and create an inspectable pending state. Honest waiting is better than false confirmation.
Support needs an operating cockpit, not another inbox
A support agent should not ask the traveller to forward the confirmation that your system created. The workspace should make the order’s state, timeline, traveller messages, supplier references and money movements visible together.
The ideal handoff includes:
- The reason automation stopped
- Actions already attempted and their responses
- Allowed next actions and relevant policy
- The customer’s latest choice
- Time sensitivity and downstream trip dependencies
- A clear owner and resolution status
This is where product and operations converge. Every repeated manual pattern is evidence for a better policy, tool or self-service flow. Every automated path should still be observable by the people accountable for its outcome.
Refunds are communication products
“Refunded” can describe several different moments: a supplier approved it, a ledger entry was created, a payment instruction was submitted, or the customer’s bank displayed the credit. Collapsing them into one label creates avoidable anxiety.
Use states that reflect what the system actually knows. Attach the refund to the original order and payment. Show the amount, destination and any component-level penalty. Keep the customer informed when the state changes, not merely 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. That shared context is essential: support should not promise money that finance cannot trace. For the financial mechanics, continue to One booking, many money movements.
Measure resolution, not deflection
Self-service rate and contact deflection can be useful, but they are incomplete. A customer who gives up is not a successful automation.
Add measures such as:
- Time from supplier event to customer-visible state
- Share of exceptions with a named next action
- Successful completion rate by service action
- Repeat contacts for the same order and issue
- Time spent in ambiguous or pending states
- Refund state accuracy across product and finance systems
- Manual interventions caused by missing context
Review failures as product work, not only agent coaching.
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 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.
