NAVAN

Hotel Change & Cancel Flow

How I eliminated the main source of support escalations by redesigning a fragmented, dead-end booking modification experience into a state-aware, self-serve flow.

Problem

A single modal can't handle 6 booking states.

The platform's original change/cancel UI was built for the simplest case: a refundable booking before check-in. It worked fine — until users did anything else.

What the data was showing: Hotel modification requests were coming through at a disproportionate rate via the CATI (call center) channel — not because users wanted to call, but because the UI gave them nowhere else to go.

What users experienced

  • Actions appeared without context — users couldn't tell if cancel was free or penalised until they were already mid-flow.

  • Post check-in? Hard stop. Non-refundable? Hard stop. No alternative paths, no explanation.

  • "Change" was a single action — masking three fundamentally different sub-flows with different rules, pricing, and supplier implications.

What the business was dealing with

  • Support agents were manually bridging every gap — explaining refund policies, processing changes by phone, re-booking on behalf of stranded travelers.

  • Manager approval and virtual CC flows were invisible to users — creating abandoned sessions and false support tickets ('nothing happened').

 

State first. UI second.

The core design insight was that the UI had been designed around actions before understanding states. I flipped this: the first deliverable was a complete booking state map, and nothing was wireframed until every state-action pair was defined.

Hotel Change Phases — the source of truth

Working with the PM, we created a swimlane diagram mapping every booking state across four tracks: user action timeline, hotel stages, booking actions, and travel agent actions. This resolved immediate ambiguity about what was and wasn't in scope, and continued to be referenced through development and QA.

 

Designing escalation as a feature

The non-refundable cancel path was the hardest design problem. The temptation was a hard stop with policy copy. Instead, I treated escalation as a product feature — three explicit paths with different effort/outcome tradeoffs:

  1. Cancel-Rebook

    • Platform handles cancel + new booking. Recovers cost in new reservation.

  2. Contact Support

    • Escalate to CATI (AI ChatBot) with full context pre-populated — no repeat data entry.

  3. Contact Hotel Directly

    • Traveler negotiates directly. Platform surfaces hotel contact details.

This approach kept users in the product longer, gave support teams warmer inbound contacts with full context, and reframed a policy constraint as a moment of genuine service.

 
 

Outcomes Summary

A pattern, not just a fix.

The redesign shipped in Q4 2022. Beyond resolving the immediate support volume problem, it established the design pattern for booking modification across all travel verticals on the platform.

  1. Targeted the #1 CATI escalation driver

    • Hotel modification contacts were the highest-volume support category. The redesign's self-serve escalation paths — Cancel-Rebook, Support with context, Contact Hotel — gave users exits that didn't require a phone call.

  2. Scalable pattern for other verticals

    • The state-aware action model — show only what's valid for the current booking state — was referenced when Flight and Car modification flows were redesigned in the following quarter.

  3. Team alignment artifact

    • The Hotel Change Phases swimlane became an org-wide reference used by product, engineering, and QA throughout development — and beyond. It reduced back-and-forth on edge cases to near zero during the build.

  4. Invisible states made visible

    • Manager approval and virtual CC authorization — previously invisible to users and a major source of abandoned flows — were given dedicated, status-tracked screens with clear next steps.

 
Next project