# What Happens After the Client Says Yes?
> A travel agency booking workflow should preserve the approved itinerary, supplier terms, payment status, changes, and next actions after the client says yes.
**Canonical URL:** https://www.ghloria.com/blog/what-happens-after-the-client-says-yes
**Published:** 2026-08-05
**Author:** Manuel Cardoso Amaral
---
The client has approved the itinerary.
Someone still has to make the trip real.
The advisor needs to confirm the services, check what changed during the sale, record the decisions, follow the payment deadlines, and keep the client informed as departure gets closer. In many agencies, this is where the proposal leaves the system. The rest happens in emails, spreadsheets, messages, and memory.
* Client approval is a handoff into booking and follow-up work, not the end of the workflow.
* The approved itinerary, supplier confirmations, changes, payments, and next task should stay attached to one trip.
* Good automation handles routine steps and makes exceptions visible when someone needs to decide.
## What happens after a client approves an itinerary? [#what-happens-after-a-client-approves-an-itinerary]
The client might approve an itinerary with one request: change the flight, move the transfer, add a night, or swap the room.
The advisor updates the document the client sees. Someone tells the supplier. Another person updates the price. A payment deadline changes. The client needs a new confirmation. The old version is still sitting in an email thread.
This is ordinary agency work. That is what makes it easy to underestimate.
The proposal records what was offered. It does not automatically record what was booked, what was paid, or what still needs attention.
After approval, the agency has to move the trip into booking and follow-up work without losing the approved version, supplier terms, changes, payment status, or next task.
## Keep the trip together [#keep-the-trip-together]
After approval, the agency needs one reliable place to answer basic questions:
* What did the client approve?
* Which supplier confirmed each service?
* What changed after approval?
* What price and conditions apply now?
* Has the payment been requested or received?
* Who owns the next task, and when is it due?
The answers may involve different people. They should still point back to the same trip.
When they do not, every handoff becomes a small investigation. Someone searches the inbox. Someone opens a spreadsheet. Someone asks the advisor what they remember. The team reconstructs the story before it can act.
That is a poor use of an experienced advisor's time.
## Automation needs a place to stop [#automation-needs-a-place-to-stop]
There is an obvious temptation here: send the confirmation, update the record, create the payment reminder, close the task.
Some of those steps can become routine. The decisions around them cannot all be treated the same way.
A supplier may confirm one part of a change but not another. A client may accept a higher price because the alternative would make the trip worse. A payment may arrive with a reference that does not match the expected amount.
The system should surface that difference. It should not quietly assume that the plan is still correct.
This is where good agency software earns its place. It removes repeated checking when the facts line up and makes exceptions visible when someone needs to decide.
## What Ghloria is building toward [#what-ghloria-is-building-toward]
Ghloria currently focuses on the first part of this work: turning supplier and client information into structured trip data and helping agencies produce proposals. The [proposal and trip workflow](/docs/booking-workflow/1-creating-proposals) is the part we can describe today.
The next question is what happens after the proposal is delivered. Booking coordination, supplier follow-up, payment workflows, and visibility across active trips are areas we are building toward. They are not finished features, and we are not presenting them as if they are.
The reason to think about them now is practical. An agency should not have to rebuild the trip record after the client says yes.
The information collected while preparing the proposal should still be useful when the agency confirms services, handles changes, and prepares the client for departure. Proposal versions are the first place to preserve that continuity, and [delivery tracking](/docs/booking-workflow/6-versions-and-delivery) shows how the handoff can remain attached to the work.
## Open an approved trip [#open-an-approved-trip]
You do not need a new process map to find this gap. Open a trip your agency approved recently and look for four things:
1. The approved itinerary.
2. The supplier confirmations.
3. The changes made after approval.
4. The next action and its owner.
If those answers live in four tools, the problem is already visible.
The fix is not one giant screen with every task on it. The fix is keeping the trip, its decisions, and its next actions close enough that the team can act without reconstructing the story each time.
That is the operational layer we are building at Ghloria.