--- title: What a Travel OTA Learned by Distributing the Booking Form Across the Whole Group description: How splitting a group booking form across all travellers reduces organiser burnout, cuts drop-off and turns checkout into a sharing loop. image: https://weareaffective.com/hubfs/learning-centre-images/what-a-travel-ota-learned-by-distributing-the-booking-form-across-the-whole-group.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-a-travel-ota-learned-by-distributing-the-booking-form-across-the-whole-grou#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What a Travel OTA Learned by Distributing the Booking Form Across the Whole Group Table of Contents Group travel bookings carry a specific kind of social tension that individual bookings do not. One person volunteers to organise everything, spends an hour entering passport numbers and dietary preferences for eight people, and arrives at the holiday already quietly exhausted by the administration. The rest of the group arrives fresh. That asymmetry is a genuine design problem, and one that a travel OTA we worked on chose to solve by rethinking who actually owns the checkout. > The lead booker completes the minimum to reserve, then each traveller fills in their own details in parallel. The product was aimed at younger adults, roughly early twenties to mid-thirties, booking group trips with friends or colleagues. The checkout covered accommodation, flights, transfers, and extras, with integration across multiple third-party providers. The volume of information required per traveller was substantial, and asking one person to gather and enter it all created a friction point large enough to push people away before the booking completed. So we redesigned the flow to distribute that data-entry burden across the group itself. What followed was not just a checkout improvement. It became a viral acquisition loop, a retention mechanism, and a lesson in what happens when a product treats a group as a group rather than as one person with a long to-do list. ## The Problem With Making One Person Do Everyone's Admin Checkout design is normally thought of as an individual task. One person, one basket, one set of details. But group travel does not work that way. The person making the booking needs passport numbers, frequent flyer details, meal preferences, and contact information for every traveller on the trip. They have to gather this by text, chase the people who do not reply, and then manually enter everything themselves. The whole process can take thirty minutes or more before any payment is made. On the OTA product we worked on, this was producing measurable drop-off mid-flow. Users were entering information and then leaving before completing the booking. The assumption had been that a longer, more complex checkout was simply the cost of a complex product. What we found was that the complexity was real, but the distribution of that complexity was wrong. One person was carrying what eight or ten people could have shared between them. According to [Baymard Institute's checkout benchmark database](https://baymard.com/ux-benchmark), the average US checkout flow contains 23.48 form elements by default, against an ideal of 12 to 14. A group travel checkout multiplies that problem by the number of travellers. Asking the lead booker to fill in every field for every person is a spreadsheet task dressed up as a purchase flow. ## How the Distributed Checkout Actually Worked We rebuilt the checkout so that the lead booker only needed to complete the minimum required to reserve the booking. For personal information, traveller details, passport numbers, room-sharing preferences, ticket distribution, we added the ability for the lead booker to invite each individual traveller to fill in their own section directly. The booking updated in real time as each person completed their part. The flow worked in a specific sequence. The lead booker selects the trip, reserves it, and then sends an invitation to each traveller through the app. Each traveller receives a prompt to download the app, log in, and complete only their own details. The booking dashboard shows which sections are complete and which are still outstanding, so the lead booker has visibility without having to chase anyone individually. #### What Each Party Sees The lead booker sees an overview of the whole booking and which travellers have completed their details. Individual travellers see only their own section, pre-labelled with their name, and a simple form covering the fields relevant to them. Neither party has to interpret a complex checkout interface designed for someone else's task. #### The Opt-In Principle Critically, this was never a forced model. A lead booker who needed to could still enter everything manually. The distribution option was an invitation, which meant it suited friendship groups and colleague trips well without breaking the product for the person who genuinely wants full control. As Simon's thinking on this goes, collaborative data entry works as an opt-in enhancement, not a replacement for manual entry. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Behavioural Mechanics: Reciprocity, Fairness and Shared Ownership The reason this model worked is not simply convenience. It touches three [psychological mechanisms that, together, make group bookings](https://weareaffective.com/user-psychology-app-design) feel fundamentally different. The first is fairness. When one person carries all the administrative work for a group trip, there is a background sense of imbalance that the other travellers are often aware of, even if they do not say so. Distributing the task removes that imbalance. Each person does their own part. The social contract of the trip feels more equitable before anyone has even packed. > Distributing the task removes the background imbalance that makes group bookings feel like one person's burden. The second is reciprocity. When a traveller is invited to complete their own details, they are being asked to contribute to something the group is doing together. That invitation carries a light social obligation, not pressuring, but engaging. People who complete their own section feel invested in the trip in a way that a traveller who simply turns up does not. The third is shared ownership. Each traveller who fills in their own information has taken an active step toward the trip. Psychologically, that investment raises their commitment to actually going. The booking is no longer something one person organised, it is something the group built together, which changes the emotional relationship every traveller has with it. ## Why This Became a Viral Acquisition Loop Before we redesigned the checkout, the product team on the OTA had tried several post-launch acquisition tactics, referral discounts, push notifications, social sharing prompts, and email campaigns through tools like Mailchimp. None of them moved the numbers in any sustained way. What actually worked was already inside the booking flow. When the lead booker organised a group trip for ten people and sent the invitation to each traveller, nine new users downloaded the app. Each of those nine new users then had the app, had completed their details, and were now warm accounts with [a genuine reason to engage](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one). Some of them went on to organise their own trips. When they did, they triggered their own cohort of new users. One person booking a trip for ten people generated nine new users, who each arrived already understanding the product's core mechanic and already trusting it, because a friend had recommended it through action rather than words. This is [a different quality of acquisition than any paid](https://weareaffective.com/learning-centre/what-makes-users-share-apps-with-their-friends) or push channel can produce. Build your acquisition loop into the core product action, not into a separate referral programme. A prompt that asks someone to "invite a friend for a discount" is easy to ignore. A prompt that says "invite your travel companions to fill in their own details" is embedded in a task the user needs to complete anyway. ## Reducing Drop-Off: The Interactive Progress Indicator The distributed checkout solved part of the drop-off problem, but the booking flow itself remained complex. Accommodation, flights, transfers, and extras across multiple third-party integrations meant a long journey from first reservation to completed payment. Even with the data-entry burden shared, [users were still dropping off mid-flow](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl). We noticed this was happening most during information-entry steps. Users would start a section, realise they did not know how long it would take to complete, and leave rather than commit to something open-ended. The progress indicator at that point was a static bar, it showed position within the flow but gave no information about the effort remaining. #### What We Changed We redesigned the progress indicator to be interactive. Users could jump between sections in any order, see an estimated time required to complete each individual section, and see an overall time estimate for the whole flow. This gave them the information they needed to decide whether to continue now or return later, which is a far better outcome than an unexplained drop-off. The booking journey covered traveller details, passport numbers, room sharing, ticket distribution, and payment, across a flow that could realistically take fifteen to twenty minutes to complete in full. Making that transparent reduced the sense of being inside a task with no visible end. According to [Baymard Institute's checkout usability research](https://baymard.com/research/checkout-usability), better checkout design alone can produce a 35.26% increase in conversion rate, and visibility of progress is one of the most consistently cited improvements in their testing. Add time estimates to each section of a multi-step checkout, not just a step counter. "Step 3 of 7" tells the user where they are. "About 2 minutes" tells them whether they have time to do it now, which is the question they are actually asking when they consider dropping off. ## Where the Model Works and Where It Does Not The distributed checkout model is not a universal solution. It works because of a specific set of social conditions, and those conditions are not present in every group booking context. | Context | Distributed checkout | Why | | --- | --- | --- | | Friendship group trip | Works well | Each person is an independent adult responsible for their own details | | Colleague / work trip | Works well | Clear individual accountability, shared peer relationship | | Family booking with children | Less suitable | A parent must enter children's details, distribution does not reduce the burden | | Couple booking | Low benefit | The overhead of inviting one other person often exceeds any time saved | For family bookings, the lead booker still needs to enter children's details regardless. The opt-in nature of the system means this is never a problem, the parent simply fills everything in manually, as they always would have done. But product teams should not over-engineer the invitation flow for contexts where it will rarely be used. The model is strongest when each traveller is an independent adult with genuine ownership of their own information and a social relationship with the other travellers that makes completion feel like a reasonable contribution to a shared activity. ## Retention Implications for Group-Focused Products A user who downloads an app to complete their passport details for someone else's booking has arrived through a low-friction, [high-trust channel. They were recommended by a friend](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) through the act of being invited. They have already completed one meaningful task inside the product. They are far more likely to return than someone who arrived through a paid acquisition channel and abandoned mid-onboarding. On the OTA product, those secondary users, the nine people who joined because one person booked a trip, arrived already engaged and already trusting the product. Users who experience friction in their first session are 2.7 times less likely to return by Day 7, according to [AppsFlyer mobile onboarding studies](https://sparklin.com/blog/why-users-abandon-apps-during-onboarding). Secondary users on this product had the opposite experience: their first session was completing a specific, purposeful task at a friend's request, with no unexplained friction and a clear endpoint. The retention mechanic extends beyond the first booking. Once a user has the app and has booked one trip, the next group trip in their social circle is likely to route through the same product. The network effect builds not through algorithmic recommendation but through social habit, the group that booked Lisbon together will use the same tool to book Seville. Design your secondary user onboarding for the specific context in which they arrive. Someone invited to fill in their passport details does not need a full product tour. They need a clear, fast path to completing that one task, with the rest of the product revealed gradually once the immediate job is done. ## What Travel, Hospitality and Events Teams Can Apply Now The core principle behind the OTA checkout redesign applies across any product where one person is expected to gather and submit information on behalf of a group. Travel is the clearest example, but event ticketing, hotel block bookings, and group dining reservations all carry the same structural problem. #### Start With the Minimum Required to Reserve Identify the smallest amount of information needed to hold a booking, and let the lead booker submit only that. Everything else can follow. This is consistent with a broader principle we apply across products we work on, deferring commitment until the user has experienced value, rather than demanding it upfront. On a gifting platform and a sports second-hand marketplace we worked on, [deferring the login to later in the process](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) consistently produced higher completion rates for the same reason. #### Make the Invitation Feel Social, Not Administrative The wording of the invitation matters. "Please submit your passport details via this link" is administrative. "Your travel companions need your details to confirm the booking" is social and purposeful. The information required is identical. The psychological framing is not. On a travel app we worked on separately, reframing a review prompt from "rate this experience" to "what would you tell other travellers about this?" produced meaningfully better engagement, because the reframe [shifted the perceived beneficiary from the company](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) to the user's peers. The same logic applies to how you phrase an invitation to complete checkout details. 1. Let the lead booker reserve with minimum information first. 2. Generate per-traveller invitations that link directly to individual detail forms. 3. Show the lead booker real-time completion status for each traveller. 4. Add time estimates to each section so travellers know what they are committing to. 5. Keep manual entry available throughout for anyone who needs full control. ## Conclusion The travel OTA project illustrated something that applies well beyond checkout design. When a product treats a group as a single user with multiple dependants, it creates an imbalance that the lead person feels acutely and the rest of the group barely notices. Redistributing the work so that each person contributes their own part does not just reduce friction, it changes the emotional relationship every traveller has with the booking and with the product. The viral acquisition loop that emerged was a direct consequence of this thinking. When individual travellers are invited into the booking, they download the app for a real reason, complete a purposeful task, and arrive as warm users rather than cold acquisitions. One booking for ten people becomes nine new accounts, each with a high probability of completing their own bookings in future. The interactive progress indicator solved a separate but related problem: people drop off not because a task is too long, but because they cannot see how long it is. Transparency about effort is a form of respect for the user's time, and it consistently reduces abandonment across complex flows. These are not abstract principles. They came from a specific product, a specific checkout flow, and a specific set of decisions about who owns which part of the booking process. If your product involves group actions, shared decisions, or multi-party data entry, the same thinking applies to you. [Let's talk about your booking experience](https://weareaffective.com/get-started). ## Frequently Asked Questions What is a distributed checkout in the context of group travel? A distributed checkout splits the data entry across the whole group rather than placing the entire burden on one person. The lead booker completes only the minimum required to reserve the trip, then each traveller fills in their own details separately through the app. Why do group travel bookings cause so much drop-off before completion? The lead booker is typically required to gather and manually enter personal details for every traveller, including passport numbers, meal preferences, and contact information, which can take thirty minutes or more. This volume of admin before any payment is made creates enough friction to push users away mid-flow. How does the lead booker keep track of who has completed their details? The booking dashboard gives the lead booker a real-time overview showing which travellers have completed their sections and which are still outstanding. This removes the need to chase group members individually, as the information is visible in one place. What do individual travellers actually need to do in this system? Each traveller receives an invitation through the app prompting them to log in and complete only their own personal details. They are not shown the full booking overview, just the section relevant to them, which keeps the task simple and quick. Does this approach only improve the checkout experience, or does it have broader benefits? The redesign produced benefits well beyond checkout completion rates. It created a viral acquisition loop by drawing new users into the app through the invitation process, and it also acted as a retention mechanism by engaging the whole group with the product before the trip. Why is standard checkout design poorly suited to group travel products? Standard checkout design assumes one person, one basket, and one set of details, which works for individual bookings but breaks down when multiple travellers are involved. According to the Baymard Institute, the average checkout already contains nearly double the recommended number of form fields, and a group travel checkout multiplies that problem by the number of travellers. Who was this OTA product aimed at, and what did it cover? The product was designed for younger adults, broadly those in their early twenties to mid-thirties, booking group trips with friends or colleagues. The checkout covered accommodation, flights, transfers, and extras, drawing on multiple third-party provider integrations. What was the key insight that led to the redesign of the checkout flow? The team found that the complexity of the checkout was not the core problem, but rather that one person was being asked to carry what the whole group could have shared between them. Redistributing the data entry to the people best placed to provide it, the travellers themselves, resolved the asymmetry without simplifying the product. ## Related Articles [![Whats the Best Database Setup for Apps That Work Offline](https://weareaffective.com/hubfs/learning-centre-images/whats-the-best-database-setup-for-apps-that-work-offline.webp)](https://weareaffective.com/learning-centre/whats-the-best-database-setup-for-apps-that-work-offline-1) ### [Whats the Best Database Setup for Apps That Work Offline?](https://weareaffective.com/learning-centre/whats-the-best-database-setup-for-apps-that-work-offline-1) A user opens your travel app somewhere in rural Patagonia. No signal. The app they have been... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Why Development Estimates Get Worse the More Detailed the Brief Becomes](https://weareaffective.com/hubfs/learning-centre-images/why-development-estimates-get-worse-the-more-detailed-the-brief-becomes.webp)](https://weareaffective.com/learning-centre/why-development-estimates-get-worse-the-more-detailed-the-brief-becomes) ### [Why Development Estimates Get Worse the More Detailed the Brief Becomes](https://weareaffective.com/learning-centre/why-development-estimates-get-worse-the-more-detailed-the-brief-becomes) There is a version of a development brief that looks, on the surface, like a thoroughly good piece... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![what-are-the-most-common-mistakes-startups-make-when-building-their-first-app](https://weareaffective.com/hubfs/learning-centre-images/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app.webp)](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app) ### [What Are the Mistakes Startups Make When Building Their First App?](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app) Nine out of ten startups fail. That's a sobering statistic that becomes even more concerning when... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.