How to Share and Update Client Itineraries Without the Back-and-Forth

Every agent knows the drill: you send a first draft of an itinerary, the client asks for a change, you re-send it, they ask for another change, and somewhere in that loop a hotel gets dropped or a flight time goes stale. It's not that the changes are hard to make — it's that there's no clean system for sharing drafts, tracking feedback, and knowing which version is actually final.

This is one of the most common friction points travel agents run into, and it's almost entirely a workflow problem rather than a tooling problem. Fix the workflow, and the back-and-forth gets a lot shorter.

Why Itinerary Revisions Get Messy

Most of the mess comes from treating every revision as a brand-new document. An agent emails a PDF, the client replies with three change requests, the agent edits the original file, renames it "v2," and sends it again. After a few rounds, nobody — including the agent — is entirely sure which version the client last looked at.

The fix isn't more communication. It's a clearer separation between the draft phase, where the itinerary is expected to change, and the final phase, where it's locked and sent as a polished document. Starting from a consistent itinerary template makes this separation much easier to maintain, since every draft and final version follows the same structure.

Keep It Editable Until It's Actually Confirmed

During the draft phase, resist the urge to make everything look "final." A simpler, clearly-labeled working version — even a plain list of flights, hotels, and transport — is easier for a client to comment on than a fully designed PDF, and it saves you from re-formatting a polished document every time something changes. If you're starting from a raw GDS booking, it also helps to convert the PNR into readable text first so the draft isn't cluttered with cryptic flight codes while the client is still deciding on changes.

• Label drafts clearly (e.g. "Draft — Bali Trip, Rev 2") so there's no ambiguity about which version is current
• Keep a single source of truth for the itinerary rather than juggling multiple files
• Only move to a branded, final export once the client has actually confirmed the details

Send the Final Version as a Branded Document

Once everything is confirmed, the final itinerary is worth treating differently than the drafts that came before it. A branded PDF — agency logo, colors, and contact details included — signals that a professional handled the trip, and it's the version the client is most likely to keep, print, or forward to travel companions. See our guide on how to convert a PNR into a branded PDF itinerary for the exact steps.

A Simple Workflow That Avoids Most of the Confusion

1. Build the draft. Pull flight details from the GDS PNR, add hotels, transport, and any pricing, and share a simple working version.
2. Collect feedback in one pass. Ask the client to list all their changes at once rather than replying to each item separately — it cuts down the number of round trips.
3. Update and re-share. Edit the same working document rather than creating a new file each time.
4. Lock and export. Once confirmed, generate the final branded PDF and send that as the version of record.

This is exactly the gap tools like the PNRGenius Itinerary Builder are built to close — you paste a raw GDS PNR, add hotels, transport, and pricing, keep editing the same itinerary as the client's feedback comes in, and only export the branded PDF once it's actually final. No juggling multiple file versions, no re-typing flight data from scratch on every revision.

What to Avoid

• Sending a "final" PDF too early. If changes are still likely, a locked document just means more re-formatting later.
• Re-typing flight data by hand on every revision. If it's already in the PNR, it shouldn't need to be retyped — that's where small errors creep in.
• Losing track of which version is current. One working document beats five files named "final," "final2," and "final_ACTUAL."