Background & Problem

Mrbilit is an online travel agency offering multiple travel services, with domestic flights as one of the core business lines. In this vertical, the search results page (SRP) is the critical step of the booking funnel: it's where users see real ticket options, compare prices and times, and decide whether to move forward with a booking.

Search Results Page, domestic flight

To understand SRP → reservation performance, we used three views:

• conversion on the same device,
• conversion that finished on a different device,
• and a broader view of how often this SRP showed up in paths that ended in a booking.

In this case, I'm referring to same-device CR, which typically looked like:

• Desktop: ~25-33%
• Mobile web: ~16-21%
• Mobile app: ~14-19%

(Figures are approximate for confidentiality.)

Behaviour data showed that most search and discovery started on mobile, while many users later completed their booking on desktop, especially for domestic flights.

When we examined drop-off rates under specific conditions, performance dropped noticeably below the usual desktop SRP baseline in scenarios that combined:

• high-demand routes,
• time-critical travel (religious trips, leisure peaks, last-minute plans),
• high-intent users who already knew where and when they wanted to go,
• direct entry from Google to SRP (skipping the homepage),
• and limited, volatile seat capacity.

Within these conditions, three routes showed the worst performance:

• Tehran → Kish
• Tehran → Mashhad
• Mashhad → Tehran

Analytics also showed that in these cases:

• users usually saw more than 10 available tickets on SRP,
• prices were not dramatically worse than normal; last-minute charter options were often attractive,
• and around two-thirds of users clicked at least one ticket, yet many of these journeys still did not end in a successful reservation on any device.

So the issue wasn’t “no results” or “no affordable options.”

We already knew where and for whom the funnel was leaking. What we didn't know yet was why these high-intent users were still failing to complete their booking.

Clarifying the problem

We already knew the leak was in high-intent, time-pressured users on key domestic routes who reached SRP, saw real options, clicked a ticket, but still didn’t finish their booking.

Our working hypothesis was:

In these high-demand, time-critical scenarios, many failures happen after ticket selection, in the last steps before ticket issuance, due to a mix of provider volatility, time pressure, and how our flow handles those situations.

So we designed the research to answer one simple question:

“What exactly breaks for these users between clicking a ticket and getting (or not getting) a confirmed reservation?”

Research approach & execution

To answer that question, I designed a two-phase study (qual + quant) anchored in our funnel data.

1. Defining the population & bucketsWith the data team, we targeted users who:

• reached SRP on one of the key routes (Tehran–Kish, Tehran–Mashhad, Mashhad–Tehran),
• clicked at least one ticket,
• and did not complete a reservation on any device within a short time window.

We then split them into buckets by route × device (desktop vs mobile), focusing on the high-demand, time-critical scenarios where we had seen the worst drops.

2. Qualitative phase – understanding the storyFor each bucket, I recruited recent failed-booking users (2–5 days after their attempt) and ran short phone interviews.

I asked a single open question:

“In your own words, why do you think your booking didn’t succeed?”

I then coded and clustered their answers into recurring reason themes (post-payment failure, capacity gone, unsuitable time, price, trust, payment issues, flow complexity).

3. Quantitative phase - sizing the reasonsNext, we sent a short survey to a larger sample from the same buckets:

• users could select 1-3 reasons from the list derived from the qualitative phase,
• options were randomised to reduce order bias,
• then they chose one main reason.

We collected 160 valid responses, which gave us a clear, quantified view of which failure reasons dominated in these high-pressure scenarios, per route and device.

Research findings

From 160 valid responses in the target routes and scenarios, users reported these main reasons for unsuccessful bookings:

Top reported reasons for failed bookings in high-pressure scenarios

In total, 53% of failures came from post-payment issuance errors and time/capacity pressure, not from lack of options or obviously bad prices.

From findings to auto-reservation

The findings shifted our focus from “Why is SRP underperforming here?” to a sharper question:

“In high-pressure scenarios, how can we reduce the risk the user personally carries when trying to secure a seat on volatile supply?”

This led to a clear product hypothesis:

If, for high-intent users on high-demand domestic routes with volatile capacity and short time-to-departure,
we offer an automatic reservation option,
then we can shift part of the risk and effort from the user to the system and recover a meaningful share of failed bookings,
without creating unsustainable operational overhead.

What we launched (v1)

Instead of trying to “perfect” the five-minute hold, we designed a system-driven mechanism that:

• lets users define their conditions (time window, airline flexibility, max price, how long we should keep trying),
• uses their wallet balance to enable automatic booking,
• and allows Mrbilit to monitor inventory, auto-issue the ticket when a match appears, or refund the full amount if it doesn’t.

We scoped v1 to:

• Routes: Tehran–Kish, Tehran–Mashhad, Mashhad–Tehran
• Situations: day-of-flight / near-departure, low or volatile inventory, and users whose previous booking had just failed

And we surfaced it only in recovery moments:

• on the “reservation unsuccessful” page, with a short explanation and CTA to start auto-reservation,
• and via support, where agents could offer auto-reservation after failures and send an SMS link into the flow.

Pilot impact

In the initial pilot on these routes and scenarios, we saw roughly:

• Adoption: ~20–25% of eligible users chose auto-reservation
• Completion: ~60–70% of auto-reservation flows ended in a successfully issued ticket
• Recovered bookings: we recovered roughly 3–5% of journeys that would previously have ended in failure, which translated into a small but meaningful uplift in total successful reservations on those routes during high-pressure periods

We also saw a noticeable drop in users citing “reservation failed after payment” and “ran out of time/capacity was gone” as their main reason for failure in follow-up surveys.