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, and somewhere in that loop a hotel gets dropped or a flight time goes stale. It is not that the changes are hard to make. There is just 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 is almost entirely a workflow problem rather than a tooling problem. Fix the workflow, and the back-and-forth gets a lot shorter. This guide also covers what to do when the change comes from the airline instead of the client, and how to send documents without creating new problems.

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 is not more communication. It is a clearer separation between the draft phase, where the itinerary is expected to change, and the final phase, where it is 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 are starting from a raw GDS booking, it also helps to convert the PNR into readable text first so the draft is not cluttered with cryptic flight codes while the client is still deciding.

• Label drafts clearly (for example "Draft — Bali Trip, Rev 2") so there is 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 deserves different treatment from the drafts before it. A branded PDF, with your logo, colors and contact details, signals that a professional handled the trip, and it is 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 the number of round trips.
3. Update and re-share. Edit the same working document rather than creating a new file each time.
4. Get a written yes. Ask for explicit confirmation of names, dates and routing before you ticket or finalize.
5. Lock and export. Once confirmed, generate the final branded PDF and send that as the version of record.

This is 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 is actually final. No juggling multiple file versions, and no re-typing flight data from scratch on every revision.

Sending Etiquette That Saves Time

How you send matters nearly as much as what you send. A few habits make a visible difference.

• Use a descriptive subject line. "Itinerary v2 — Lisbon 14–21 May — please confirm names" beats "Itinerary".
• Make one clear request. Say what you need and by when: confirm the names, approve the hotel choice, or reply with changes by Thursday.
• Summarize changes in the email body. Do not make the client compare two PDFs to find what moved.
• Send to the right person. When several travelers are involved, send to the lead booker unless told otherwise, and check you have not auto-completed a similar-looking address.
• Avoid sensitive data. Do not include passport numbers or card details in the document or the email.
• Use blind copy for groups. Individual families should not see each other's addresses.
• Reply within a predictable time. Clients tolerate a one-day turnaround if you tell them to expect it.

Handling Changes: Client-Initiated vs Airline-Initiated

These two kinds of change need different handling, and mixing them up causes most of the confusion.

For airline changes, speed matters. Clients may already have booked a hotel transfer or told family the old arrival time. Contact them as soon as you know, explain the new times in plain words, and give them your recommendation. If the change is significant, they may have rights to a refund or rebooking under the airline's conditions or local passenger rules. Those rules vary by region and by fare, so check the airline's conditions or the relevant regulator rather than guessing. For more on reading schedule-change codes, see our status code guide.

Tracking What Changed

When a booking is revised, compare the old and new PNR line by line: dates, times, flight numbers and status codes. Do it every time, even for small changes, because a retimed connection can quietly break a transfer you arranged. If you keep bookings in the optional My Bookings feature on PNRGenius, re-converting a saved PNR gives a smart diff that highlights what moved, and schedule-change alerts for saved bookings can tell you something has changed. You can also look up the live status of a flight on the flight status page as the departure date nears.

A Short Illustration

Imagine an agent, Tomas, who has sent a final itinerary for a family trip to Lisbon. Two weeks before departure the airline retimes the outbound flight by ninety minutes. Tomas notices it in the PNR, sees that the airport transfer pickup is now too early, and contacts the transfer company first, then the client. His message says what changed, what he has already fixed, and what he needs from the client. He issues a new version marked v2, with the changed segment noted at the top. The client replies "thanks, got it" within the hour. Nothing dramatic happened, because the system, not heroics, handled it.

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 is already in the PNR, it should not need to be retyped. That is where small errors creep in.
• Losing track of which version is current. One working document beats five files named "final," "final2," and "final_ACTUAL."
• Overwriting rather than versioning. If you replace the file but keep the name, the client cannot tell the difference.
• Burying the change. If the airline moved a flight, say so in the first line of the message.

Frequently Asked Questions

Should I send drafts as PDFs or as plain text?

Plain text or a simple working document is usually better for drafts, because it is easy for the client to comment on and cheap for you to change. Save the polished branded PDF for the version of record, once the client has confirmed. Mark every draft clearly so it cannot be mistaken for the final.

How do I stop clients using an old version of the itinerary?

Put a version number and issue date on every file, say in the email exactly which version replaces which, and ask them to delete or archive older ones. You cannot fully control what clients keep, so the safest habit is to restate the key facts that changed in the body of the message.

What should I do when an airline changes the schedule after I have sent the final itinerary?

Check the PNR to see the new times and status, decide whether the change is acceptable to the client, and contact them promptly. Then issue a new version of the document with the changes highlighted. If the change is significant, the client may have options such as rebooking or a refund under the airline's conditions or local rules, so check those before advising.

How can I tell what changed between two versions of a booking?

Compare the old and new PNR line by line, focusing on dates, times, flight numbers and status codes. If you save bookings in PNRGenius's optional My Bookings, re-converting the PNR shows a smart diff of what moved, and saved bookings can send schedule-change alerts. Either way, never rely on memory to know what changed.

Is it safe to share itineraries over WhatsApp or other chat apps?

Many clients prefer it, and it is convenient, but it is less controlled than email. Chats can be forwarded and screenshots are easy to take. Avoid sending passport details or payment information, send only to the named client, and confirm the number before sending. Follow your agency's and host's data-handling rules.

How much feedback should I collect before updating the itinerary?

Ask for all changes in one pass and say what you need by when. One consolidated update is clearer than six small ones, and it reduces the chance that two changes conflict, for example a later flight that no longer connects to a transfer you already arranged.

When should I ask the client to approve the final version?

Before ticketing, if the ticket is non-refundable or expensive to change. Ask the client to confirm names, dates and routing in writing, and keep that reply. This protects both of you, because names and dates are the most expensive things to correct after issue.