The value is not the twenty minutes of assembly. It is having every reference number and phone number in one place at 2am in an airport with no signal.
Travel is one of the oldest executive assistant tasks and one of the least changed. Confirmations arrive from six places in six formats, get forwarded around, and somebody assembles them into something usable, usually twice because the first version is out of date.
Parse deterministically, and expect it to break
Booking confirmations are structured documents. Airlines, hotels and car hire companies all send predictable formats, which makes them a good target for deterministic parsing rather than for a language model.
The honest caveat: they change those formats without warning, and a parser that silently stops working is worse than none, because the itinerary quietly goes stale. Build validation that shouts rather than guesses, and accept that this automation needs occasional maintenance in a way that most in this series do not.
The value is not the twenty minutes of assembly. It is having every reference number in one place at 2am in an airport with no signal.
How to build it
1. Get confirmations into one place automatically
A dedicated address that bookings are forwarded to, or a rule that files anything from known travel domains. Everything downstream depends on the confirmations arriving somewhere predictable.
2. Parse the structured fields
Dates, times, reference numbers, addresses, terminal information. Deterministic parsing per provider, with a validation step that flags anything it could not read rather than dropping it silently.
3. Normalise every time to local time at the location, and label it
Time zones are the single most common failure in any itinerary, and they are entirely avoidable. Show local time with the zone named next to it, every time, including on flights that cross zones.
4. Run the four checks
Impossible connections, time zone inconsistencies, missing segments such as an arrival with no onward transfer, and document expiry against destination requirements. These are the failures people discover at an airport.
5. Produce one page, on a phone and on paper
A single view with every reference number, address and phone number. Printed matters more than it sounds: the moment it is genuinely needed is often the moment there is no signal and a dead battery.
6. Include who to call, first
Not at the bottom. The travel agent, the airline number, the hotel direct line, and the person at home who can act. The itinerary is a reference document for when things go wrong, and that is the section that gets used.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Consumer itinerary apps (TripIt and similar) | Free tier; paid versions typically tens per year. | Excellent parsing across most providers with almost no setup, and they maintain it when formats change. Less flexible for company-specific requirements. |
| Apps Script parsing a dedicated mailbox | Free with Google Workspace. | Full control of format, checks and output. You own the parser maintenance, which is the real ongoing cost here. |
| Corporate travel platforms | Per booking or per traveller. | Policy enforcement, duty of care and support when things fail. Priced and designed for larger travel volumes. |
| A manually assembled document | Free. | What most assistants do now. Reliable, and it consumes real time and gets rebuilt on every change. |
What it is actually worth
The time is easy: trips per year, times the minutes per itinerary including rebuilds when something changes. It is a real number and it is not the main argument.
The checks are the main argument, and their value is asymmetric. A missed connection, a hotel booked for the wrong night, or a passport short of the required validity costs a day of an expensive person plus rebooking. One prevented instance usually justifies the build.
And the stress reduction is real even if unmeasurable. A traveller who knows everything is in one place, including who to call, behaves differently from one who is searching an inbox in a taxi.
I am not quoting travel management vendor figures on savings. They exist, they are marketing, and they assume corporate travel volumes that do not resemble a small business.
How it breaks
A provider changes their email format and parsing fails silently. The characteristic failure of this automation. Validate that every expected field was found and alert when one is missing.
Changes do not propagate. A rebooked flight leaves the original in the itinerary. Re-parse and regenerate on every new confirmation rather than appending, and mark superseded segments clearly.
Time zones are wrong. The error that ruins trust in the whole document. Test explicitly across a date line and across a daylight saving change.
It only exists on a phone. Print it, or at minimum save it offline.
How to tell whether it worked
Travel problems that were preventable, counted per year: missed connections, wrong-night bookings, document issues. That number should go to zero. Then minutes spent assembling and re-assembling itineraries, and the share of trips where the traveller had to ask for a detail already sent.