Agency workflow answer
How should travel agencies manage itinerary revisions?
Treat each sent proposal as a versioned record. When feedback requires itinerary changes, update the private trip, create a revised proposal version, summarize what changed, and tie approval to the exact version the client accepted.
Why it matters
The agency process has to stay clear before the client sees the plan.
Revisions are normal in custom travel. The risk is not revision itself; the risk is silently changing the record the client thought they approved.
Common agency workflow
- Review client feedback and decide what needs itinerary work.
- Update the private trip while preserving the old proposal version.
- Create a new proposal version from the updated trip.
- Show a concise client-safe change summary and collect approval on the new version.
Where this step can go wrong
- The agency edits a proposal link in place.
- The client cannot see what changed between versions.
- Approval is detached from the final proposal version.
- The private trip changes after approval without warning.
Platix example
How Platix supports this step.
- Platix keeps published proposal versions immutable.
- A revised proposal can show a client-facing What changed section.
- Final itinerary delivery should come from the approved published version, not an unreviewed private trip.
Boundary
What Platix does not replace.
- A side-by-side legal redline is not required for ordinary itinerary feedback.
- The agency remains responsible for confirming that revised prices, availability, and supplier terms are still valid.
Product guides
Use the exact Platix controls.
Questions
What do v1 and v2 mean?
They are proposal versions: the first published client proposal, then a later revised proposal.
Should clients see what changed?
Yes, a concise human summary helps them review the revised version faster.
Can the final itinerary come from v1 if v2 exists?
Only if v1 is the version the agency intends to finalize and it is still correct.