Booking Flow: From 13% to 35% Confirmation-Page Completion

What is Cityflo?

Cityflo is an app-based commute service that gives office workers a premium alternative to driving or public transit, reserved seats on air-conditioned buses running fixed routes between residential areas and business districts, with live tracking along the way. When I worked on this project, the service operated in Mumbai; it has since expanded into several other major Indian cities and is now India's largest app-based bus operator.

The problem

Even after onboarding asked users for their commute details — home, office, preferred timing — the booking flow ignored all of it. Every time a user wanted to book, they had to manually work through 12–15 route and timing cards with no differentiation or guidance, then repeat the same decision they'd already told Cityflo about at sign-up.

Three things compounded this:

• Information was scattered across multiple screens instead of one clear view.
• The app offered no help deciding — no recommendation, no ranking, just a list.
• Secondary information that mattered — stop distance, route, what to do if you missed the bus — was hidden behind interactions users had to discover on their own.

Take a new user who'd just onboarded and given Cityflo her regular commute — home in Thane, office in Goregaon, an 8:30am departure to beat traffic. She'd still have to read through every route option, decide which one worked, then separately choose a time, despite the app already knowing both.

This wasn't only a usability problem. Solving it mattered for the business too: Cityflo's growth team needed better demand signals to decide which timings justified launching new buses on existing routes.

What we knew about users

57% of users traveled within their favourite hour window.

Regular customers were even more consistent: 3 out of 4 traveled within one hour of their preferred time, 80% of the time — affected by factors like bus frequency and time of day.

Preference for a specific arrival time was strongest during peak hours.

This told us the flow didn't need to make users decide from scratch every time. Most already had a strong, predictable preference — the app just wasn't using it

Old booking flow

One scenario, drawn from conversations with users, captured the problem clearly.

Bhavana is a bank manager living in Thane, commuting to Nesco IT Park in Goregaon. She leaves around 8:30am to beat traffic and reaches the office by 9:40am. She'd heard about Cityflo from a colleague and signed up.

After onboarding — where she gave Cityflo her home, office, and preferred timing — the app still didn't help her. She had to read through every possible route option, decide which one worked best, then repeat the same process to choose a time, despite having already given Cityflo that information.

As a new user, she was left with open questions the app never answered:

1. How far is the stop from my home?
2. What route is the bus going to take?
3. How do I identify my stop?
4. What if I miss this bus?

How did we go about it?

To begin with, it was imperative to understand what information did our users needed before making a decision of choosing a bus. What were the preconception our users had and how will the app help them with the same.

1. Recommending buses that will help users reach their home/office on time.
2. Grouping information so that it helps user take a decision easily
3. Showing relate secondary information which is easily accessible
4. Ability to tell users suggest timings that they would prefer a bus to help with demand identification

To understand it a little further, I wanted to see how Mumbai local's indicator worked. They seemed to have similarities with what we wanted to achieve - make a choice! At first I did feel the information was overwhelming but it was important to make an informed decision, one which is going to impact the routine for the day.

The final card, a summary of information about a particular unit.

Design decisions

Cards, not lists. Bite-sized, contextual cards let us surface the right information in the right context without overwhelming the user, closer to how Mumbai locals' train indicators present dense information as scannable, discrete choices. Every card had to answer two questions: what information matters most to this decision, and how much is too much before it stops being usable?

Put decision-critical information on the card, not behind it. In an earlier version, pickup and dropoff details, information users genuinely needed to choose between options, lived behind a swipe interaction on the card, a colored panel revealed only if you knew to swipe. Almost no one discovered it. We moved that information onto the visible face of the card instead of gating it behind an interaction with low discoverability.

Recommend, don't just list. Instead of showing every possible stop-and-time combination, the flow surfaced a maximum of 3 relevant stop combinations per search, with a relevant time pre-selected. Most users don't have more than 3 pickup stops worth genuinely considering, showing all 12–15 was noise dressed up as choice.

Specify the ranking logic for engineering, not just the cap. Capping results at 3 wasn't enough on its own — which combination showed up first versus third had to be an explicit, documented rule, not left to guesswork or implementation default. The ranking followed a fallback sequence:

1. Has the user ridden this route before? Show their most recent stop and time first, tagged "Your last ride."
2. Otherwise, find the closest stop with a time matching their usual office hours — and if that exact best match is unavailable (bus full), fall back to the next-closest option that still fits their timing. Both cases tagged "Recommended."
3. If nothing matches their usual timing at all, fall back to simply the closest stop — tagged "Nearest," so the label itself tells the user this one's a geographic compromise, not a personalized pick.

This operationalized the research directly: since most users had a strong, consistent time preference, the flow used it to rank automatically instead of asking again.

Use the flow itself for demand signals. Rather than run a separate research exercise, we built light-touch timing suggestions into the booking flow for select users and routes — not everyone, since a full list of timings was overwhelming for users who already had a clear preference. This fed directly into the growth team's question: which timings justified a new bus.