Making Booking Outcomes Clear: Reducing Support Queries by 25.8%

Background

The Thank You page is the first screen users see after completing payment. Although it appears at the end of the booking flow, it is not simply a confirmation screen. It must communicate whether the booking was successful, pending or failed; show important journey and traveller information; explain what happens next; and provide recovery options when something goes wrong.

In discussions with the Product Manager for the trains funnel, we concluded that the page needed to distinguish payment failures from IRCTC failures, prioritize the PNR over the internal booking ID and support shared modules such as Manage Booking, cashback and cross-sell. Business goals, formal research and success metrics were still open in the initial brief.

I designed for the trains funnel first, and the system was then rolled out across trains, buses and cabs.

My role and ownership

I owned the experience from the initial audit through state definition, information architecture, user flows, interaction design and implementation review.

I began by reviewing the existing post-booking flow and identified eight usability gaps related to hierarchy, status visibility, action clarity and content density. I then mapped the system outcomes and organized them into five top-level states.

Through this process, I found that the page did not simply need a cleaner interface. It needed clear rules for what information should appear, in what order and under which booking condition. I used these findings to build a reusable system rather than designing separate screens without shared logic.

Impact

Following launch, booking-status and confirmation-related support queries decreased by 25.8% compared with the pre-launch baseline.

The main problem was not the number of booking states. It was the way information was organized.

On the existing page, booking confirmation, journey details, actions, policies, customer support and promotional content had similar visual importance. Users had to scan through multiple cards to answer three basic questions:

• Did my booking go through?
• What exactly was booked?
• What should I do next?

This became especially difficult when a booking was pending, waitlisted or unsuccessful.

The business goal

The business wanted to keep customers within the Goibibo ecosystem by introducing My Trips, return journeys and other relevant services after booking.

However, showing these modules too early or too prominently risked competing with the confirmation task. The challenge was to create space for business opportunities without reducing trust or making essential booking information harder to find.

Solution: A state-aware system that covers every booking state

I redesigned the page as a modular, state-aware system rather than one fixed layout.

The system first identifies the booking outcome and then changes the message, information order and actions shown to the user. Successful users see their confirmation and ticket details before related services. Pending users receive clear expectations and notification options. Failed users see the reason, payment or refund information and the safest recovery action.

How I approached research

Because this was an existing transactional product, I focused on evaluative research rather than broad exploratory research.

I used an experience audit to understand where the interface was visually and structurally difficult to scan. I reviewed booking-related support queries because they showed which questions users could not answer on their own. I also mapped payment, IRCTC and booking responses with the product flow to understand what the system knew at each stage and which actions were safe to offer.

Research Insights

This research helped me identify three important findings:

• Users needed booking status before any secondary information.
• Pending and failed bookings required different messages and actions.
• Cross-sell was most useful after the user’s immediate booking concern had been resolved.

Opportunity space

The opportunity was not to remove useful information. It was to reveal information in the right order and at the right moment.

My guiding question became:

Through my research and analysis, I identified opportunities to make the experience responsive to each booking state, support self-service recovery and introduce ecosystem offerings at the right moment. These opportunities shaped a modular confirmation system that prioritized booking clarity first, recovery second and relevant cross-sell only after the user’s immediate concern was resolved.

Opportunity 1: Make the page a self-service and recovery surface

Pending, failed, waitlisted users needed more than a status message. They needed to understand what had happened, whether their payment was safe and what they could do next.

I used this opportunity to introduce clear explanations, payment and refund information, notification options and state-specific recovery actions. This helped users resolve more booking questions without depending on customer support.

Opportunity 2: Introduce cross-sell services related to the travel funnel

The business wanted to keep customers within the Goibibo ecosystem so I introduced cross-sell through return journeys, My Trips and other post-booking services. However, showing these options too prominently could compete with booking confirmation and reduce trust.

I treated this as an opportunity to make cross-sell contextual:

• Prominent after a stable, successful booking
• Deprioritized while a booking was pending
• Removed during unresolved payment or failure states

This allowed the experience to support business growth without distracting users from critical booking information.

Design Decisions based on Use cases

All travellers confirmed

I made the successful outcome immediately visible and prioritized the PNR, booked route, travel date and traveller details. Download Ticket and My Trips became the primary actions. Return trips and other related services appeared after the confirmation task.

Waitlisted or mixed traveller status

A successful payment does not always mean every traveller has a confirmed seat. I displayed status at the traveller level so that one overall label would not misrepresent a mixed booking.

The screen explained the waitlist status and provided access to PNR updates, notifications and My Trips.

Payment and IRCTC failures

I separated payment failure from booking failure because they require different recovery actions.

A payment failure could allow a safe payment retry. An IRCTC failure needed to explain the booking reason and allow the user to modify their selection or return to the review page without starting over.

I also designed for generic failures, preference-related failures, recovered sessions, expired access, route variations, children under five, split seats, long names and mixed traveller statuses. The full use-case and edge-case matrix is included in the project presentation.

How I handled challenges and made decisions

Primary KPI: Booking-status support queries and Secondary Metric: Cross-sell engagement

25.8% reduction in booking-status support queries

I selected booking-status support queries as the primary KPI because the main user problem was unclear confirmation information. When users could not understand whether their booking was successful, pending or failed, they often contacted customer support for clarification.

The reduction was supported by several design changes:

• Making booking status the first and most prominent information
• Prioritizing the PNR for train bookings
• Separating success, pending and failure experiences
• Showing traveller-level status for waitlisted and mixed bookings

10–15% increase in cross-sell engagement

I tracked engagement only for eligible users whose bookings had reached a stable successful state. Pending and failed users were excluded because resolving their current booking was more important than promoting another service.

Following launch, engagement with relevant post-booking cross-sell modules increased by 10–15%.

This improvement was supported by:

• Moving cross-sell content below confirmation and journey details
• Showing it only after the primary booking task was resolved
• Making recommendations relevant to the user’s journey

What I learned

This project taught me that simplifying an experience does not always mean removing information. In this case, the larger opportunity was to decide what users needed first, what could wait and what should only appear in certain states.

Mapping the system before designing the screens helped me create a solution that supported both user clarity and business needs. It also changed how I think about confirmation pages: they are not simply the end of a transaction, but an important space for reassurance, recovery and continued engagement.

What I would do differently

If I repeated the project, I would define the analytics and support taxonomy at the beginning of the work so that every state had a clear baseline. I would also conduct short comprehension tests using realistic booking data, including mixed traveller statuses and payment uncertainty. This would allow me to validate not only whether users liked the page, but whether they could correctly explain what happened and choose the right next action.