One Trip, Many Tickets: How Jettova's Per-Member Booking Works

If you've ever organized a group trip, you know the part where it almost always falls apart isn't the planning. It's the booking. You pick a destination, you agree on dates, you find a flight everyone likes, and then someone has to put $2,400 on their credit card so the group can book together. They chase Venmos for weeks. Two people respond. The math gets fuzzy. Six months later, no one remembers exactly who paid what, and the friend who fronted the money quietly resolves to never volunteer for that role again.

This isn't a behavior problem; it's a structural problem. Group booking on traditional travel sites assumes one transaction with one card. The booking is built around 'one customer'. When that customer is actually four customers, the cardholder absorbs the financial risk and the social burden of collection. The whole architecture is wrong.

Jettova's booking flow is designed around a different assumption: a group trip should produce one shared itinerary and one ticket per member, each booked individually with each member's own card. The trip is the shared object; the bills aren't. We built this as a per-member handoff. Each member gets their own single-passenger search for their own city and dates, then books their own ticket directly with the provider, on their own card.

Here's how it works in practice. The group goes through the planning room (vibes, destination, day-by-day storyboard) and lands on a finalized trip. When members open the trip page, they see a prominent 'Your booking details' card at the top with three fields: their departure city (a city autocomplete), their depart date (defaulted to the group's date), and their return date. Members fill these in and click 'Book my flight'. The backend runs a fresh single-passenger search for that member's exact origin, dates, and route, surfaces the cheapest matching fare (preferring the airline the group's sample flight used), and hands the member off to the provider to book it.

The member is handed off to the provider to complete the booking — passenger details, payment, and confirmation happen on the provider's site, with the member's own card. The provider's prices and cancellation policies apply. We stamp the booking in the member's local browser storage so the next time they open the trip page, their booking shows up automatically (instead of prompting them to book again).

What this changes is the social dynamic of group travel. The friend who used to volunteer to 'put it all on my card' doesn't have to anymore. Members in different cities (one flying from Boston, one from Austin, one from London) get their own per-route quotes. Every member gets the cheapest single-passenger fare from their own home airport. There's no shared invoice for anyone to chase. Every member has their own confirmation reference and their own airline relationship for any later changes.

There are some practical second-order benefits. Members on different schedules can fly on different dates. The per-member booking flow lets each person extend before or after the group's shared dates if they want to. Members who prefer different cabins (one wants premium economy, another wants the cheapest fare) can each pick what they actually want. The shared itinerary is what makes it a group trip; the individual bookings are what make it bookable.

We considered other approaches when we were designing this. One was the 'single group offer' model, a single fare priced for N adults that one person books and others pay back. This is what most existing flight tools do, and it's exactly the model that produces the credit-card-volunteer problem. We rejected it as structurally wrong for group travel: putting all the financial risk on one person creates social drag and produces fewer trips. Another approach was external split-payment tools (Venmo, Splitwise) — but those happen after the booking, which means the cardholder still fronts the money and chases payment. Neither solved the actual problem.

The per-passenger handoff model is more work on our end than just sending people to Skyscanner, but it's the only model where the structural bottleneck of group travel — 'who pays first?' — disappears entirely. There's no first payer because there are N payers, each paying their own ticket. The booking step stops being where group trips die.

If you want to see this work in practice, the easiest path is to start a planning room (/room/create), get a friend or two to join with the invite link, vote through to a destination together, and watch each member book their own flight at the end. The first time most groups use Jettova, the moment everyone realizes 'oh, I just book my own ticket' tends to land. It's the small structural fix that makes the rest of the planning effort worth doing.