Retry Failed Bookings
Turning dead-end booking failures into self-serve recovery — so travelers fix what they can themselves, instead of waiting on a support ticket.
01 — Overview
ITILITE is a B2B travel & expense platform. When a booking fails at checkout — a card declined, a fare changed, a seat sold out — the default was to silently raise a request to our internal support team (SRC). This project replaced that dead end with guided, self-serve recovery: detect the failure, tell the traveler exactly what broke, and let them fix and retry inline.
Deterministic error mapping
Every failure is classified as user-resolvable (payment, membership, fare, availability) or not. Only the ones a traveler can actually fix are surfaced for retry — the rest fall back to SRC.
Leg-level recovery
In a multi-leg trip, confirmed legs stay confirmed while only the failed legs drop to a retryable state — travelers never lose a good booking to fix a bad one.
Inline resolution
Fixes happen where the error appears — swap a card, update a membership, accept a new fare — with a live fare-expiry timer so retries don't stale out.
Email + session continuity
A failure email links straight back to the exact page needing action, so travelers can complete a booking even after the session ends.
02 — Problem
A failed booking meant waiting on support
Every failure — even one the traveler could fix in ten seconds — routed to an internal team. That meant slow resolutions, no context for the user, and a growing ops load. The data was clear: most failures didn't need us at all.
No context, no path
Travelers saw a generic failure and were left waiting for an agent to investigate and reach back out.
All-or-nothing trips
One failed leg could jeopardize the whole trip, even when the other bookings had gone through cleanly.
Avoidable ops load
Deterministic, user-fixable errors made up the bulk of SRC tickets — expensive to resolve, easy to prevent.
03 — Design
Three surfaces, one recovery loop
The guiding principle: if only the traveler can fix it, tell them exactly what to fix. If we have to fix it, handle it silently or escalate.
Post-booking summary
The moment after checkout. Confirmed and failed legs are split into clear sections with a trip-level status up top, so a traveler instantly sees what went through and what needs attention.
Inline error resolution
Fixes happen exactly where the error is. A membership name mismatch, a declined card, an increased fare — each resolves in place without bouncing the traveler back through the whole flow.
Trip dashboard (L2)
Even after the session ends, the trip stays recoverable. The dashboard flags every failed leg with its reason and a direct path to complete the booking — reachable straight from the failure email.
04 — Impact
Business impact
of failures made self-serve
The four addressable error categories — payment, fare, availability, membership — that no longer require support.
Self-booking (SBT) rate target
Fewer trips falling out of the self-serve flow into assisted handling.
of failed legs self-resolved
Target share of failures a traveler completes on-platform, most within a single retry.
support tickets deflected
A projected 3%+ cut in total support volume by removing deterministic, user-fixable failures.
Targets defined from Q1 2026 failure analysis across ~25,000 booking legs. Phased rollout — wallet and US card customers first, expanding to approval-flow and IL-card accounts.