It's a Trip, Not a Booking

Nobody thinks in bookings

Ask a guest what they’re doing in March and they’ll tell you about a trip. Two nights in the city, a flight down the coast, four nights at your place, a boat thing on the Thursday, then home.

Ask your software what they’re doing in March and it will tell you about a booking: four nights, two adults, paid. Which is true, and which is roughly two percent of what’s actually happening in that person’s head.

This gap is not a cosmetic problem. It’s the reason guests email you at 11pm asking about airport transfers, the reason they arrive having misread which day they fly, and the reason the next four bookings of their trip were made through four different websites that will each hold their details and none of which will ever mention you again.

Airflow Guest is the other side of the platform: not the host’s view of a booking, but the traveller’s view of a trip.

Forward a confirmation, get a plan

The entry point is deliberately unglamorous. A guest who already has an itinerary shouldn’t be made to type it into a form.

So the first step is a question rather than a form: do you already have an itinerary, or are you starting fresh? If they have one, there are three ways in — paste the text, give a link, or upload a PDF, CSV or text file. The itinerary gets read into a structured plan: title, destination, and for each day the places, activities, transfers and flights. Something that isn’t an itinerary is refused rather than turned into an empty trip.

Two details in there took some thinking about.

Three nights at one lodge is one stay, not three. An itinerary that lists the same place on days 2, 3 and 4 describes a single booking. Consecutive nights at one place merge into one stay spanning them — otherwise the guest would end up sending the same host three separate availability requests for the same visit.

Dates are never guessed. Real itineraries say “Day 1, Day 2, Day 3”, not dates. Inventing a start date would put a trip on the calendar the guest never agreed to and quietly corrupt every availability request that followed. So items carry a day offset and no date at all, and the plan says “pick the day your trip starts”. That single date then places everything in order and sets the trip window.

Flights, without pretending to be an airline

Ask the planner about flights and it maps the route — one card per one-way leg, using the stay dates and the airport nearest each stay. Each card asks for what’s missing: from, to, date, passengers, cabin. The first card you complete remembers your home airport, and the planner uses it from then on.

Then Find flights opens a flight search already filled in.

That last part is a deliberate limit rather than a missing feature. We could have integrated a flight-booking API and sold tickets inside the plan. That raises questions about who the seller of record is, how package-travel rules apply and who handles refunds — a genuinely different business. The lighter loop is better: the guest books with the airline, and Airflow keeps the plan. When the confirmation comes back, forwarded or pasted, the reader extracts the segments, joins connections into single journeys, and matches a journey to the card that was waiting for it. Anything unmatched is added as a booked flight rather than dropped.

There’s a nice wrinkle for the parts of the world we care most about. Large flight search engines don’t sell seats on small regional and charter operators — the ones that actually fly the routes into a lot of the places worth going. So the planner names the operators it knows for that leg and turns them into a plain web search that reaches the operators’ own booking pages. On those legs, that becomes the card’s main action.

While building this we found that no forwarded or pasted flight had ever reached a plan at all. A change the previous day had started saving flights and transfers under a category name the database rejected. The insert failed silently, and the table held zero rows. The kind of bug that only surfaces when you go looking for the feature you just built.

What this is for

It would be easy to read all this as a nice extra for guests. It isn’t — it’s the part of Airflow that compounds.

Every host who uses Airflow sends their guests into the same planner. That guest has three other stays on the same trip, booked elsewhere. When they plan the next one, the planner is where they start, and the places Airflow already knows about are the ones they can ask for availability immediately. A place we don’t yet hold is queued as a lead — deliberately queued, not acted on, because a guest naming a place is a claim about a business rather than a verified business, and a person qualifies it before we spend anything or contact anybody.

There’s a suppression check in that path too: a host who has previously said “not me” or “stop” is never silently recreated because someone else’s itinerary mentioned them.

Meanwhile the marketplace side has trip ideas already built — 31 routed trips covering 126 stops — so a guest arriving with no plan at all isn’t looking at an empty box.

The security you don’t see

Two things in here would be irresponsible to build casually.

A URL a guest pastes is, from the server’s point of view, attacker-controlled input to a server-side fetch. So link imports allow only http and https, refuse private and link-local addresses, re-check the destination after any redirect, and cap the download size.

And PDFs go straight to the model as documents rather than through a parser we’d have to maintain and patch. Less code, fewer places to get it wrong.

How well does it work?

We’d rather give you the test numbers than an adjective. The import path has unit tests covering night merging, day offsets, positioning and trip windows; a browser suite covering the modal, each import tab, and the whole plan moving onto real dates; and a live end-to-end run against production on a throwaway guest — six days read, stays merged across nights, flights and transfers carried across, a place we list matched so it can be asked for availability, a place we don’t hold queued as a lead with research left open, and something that wasn’t an itinerary correctly refused. The flight cards have the same three layers, including a pasted two-way confirmation with a connection joined correctly.

One thing isn’t finished: forwarding a flight confirmation to the trips inbox needs a mail route that isn’t live yet. Until it is, pasting works and forwarding doesn’t — which is why the cards say “forward or paste” rather than promising one.

And the write actions in the demo version of the planner are refused rather than simulated, so if you’re poking at the demo, the toast telling you nothing was saved is telling the truth.

Where this goes

The flight card is a pattern, not a one-off. Car hire, airport transfers and travel insurance all have the same shape — a thing the guest needs, on a date you already know, that you currently learn about when they email you about it at 11pm.

If you want the host’s side of this, Every Guest Message in One Thread and Sell the Airport Pickup at Checkout are the nearest neighbours. Or have a look at Airflow Guest.