At a glance
- The situation
- A small tour operator assembles multi-stop trips from hotels, transfers and local guides that each confirm in a different way.
- What goes wrong
- The pending list is rebuilt by hand every morning, a late change slips through, and a cancellation that was sent but never acknowledged turns into a no-show charge.
- What changes
- The platform keeps every unconfirmed service in one queue with automatic reminders, and treats a cancellation as open until the supplier acknowledges it.
An illustrative scenario: a tour operator books many suppliers per trip and tracks confirmations in a spreadsheet; a cancelled room is still charged because the property never received the cancellation. With a supplier confirmation queue and two-way cancellation acknowledgement, nothing is assumed confirmed or cancelled until the supplier says so.
The scenario
Imagine a small tour operator building multi-stop trips: several hotels, airport transfers and a couple of local guides per itinerary. Some suppliers confirm instantly through an API, some reply by email the next working day, a few only answer on a messaging app when the owner has time.
The team keeps a shared spreadsheet of what is still pending and works through it every morning. Details change late — a room type, a pickup time, an extra passenger — and each change restarts the chase, because the old confirmation no longer matches the new details. On busy days a trip departs with one transfer still unconfirmed because the follow-up slipped to the next column.
Then a client cancels one hotel night. The operator emails the cancellation to the property, marks the row as cancelled and moves on. The property later charges a no-show night and says it never received the cancellation. The operator has an outgoing email with a timestamp, but nothing from the property confirming the cancellation was accepted.
The dispute runs for weeks. The operator cannot prove receipt, the property cannot prove non-receipt, and the client wants to know why a cancelled night is on the invoice. Meanwhile the morning spreadsheet is still being rebuilt by hand.
Why it is hard to fix
Every supplier confirms differently
Instant API confirmations sit beside emails and messages, so there is no single place that shows what is still open.
Changes reset the clock
A late amendment needs a fresh confirmation, and it is easy to treat the old one as still valid.
Sent is not received
A cancellation that was sent but never acknowledged leaves the operator exposed if the supplier says it never arrived.
Nobody owns the chase
When the pending list is a shared sheet, following up is everyone's job and therefore nobody's.
What changes with the platform
On the Innovate Solution platform, every service that is not confirmed instantly sits in a supplier confirmation queue against its trip. The queue sends automatic reminders to the supplier and shows staff which items are still waiting, on which trip, since when and how many reminders have gone out.
Any change to a confirmed service sends it back into the queue for a fresh confirmation, so an old confirmation is never mistaken for the new details. Supplier conversations can run through Inno Message, which keeps the reply attached to the booking rather than in a personal chat.
Cancellations work the same way in reverse: a cancellation is not treated as complete until the supplier acknowledges it. An unacknowledged cancellation stays visible in the queue and is chased automatically, so it is caught before the stay date rather than after a no-show charge. Live KPI dashboards show how many services are still open across all departures.
How it works, step by step
-
A service is booked
Anything not confirmed instantly enters the confirmation queue against its trip and departure date.
-
Reminders go to the supplier
The platform sends automatic reminders through the supplier's channel until the supplier confirms; staff see the reminder count.
-
The supplier confirms
The confirmation is recorded on the service and the item leaves the queue.
-
A change is made
The amended service re-enters the queue and needs a fresh confirmation against the new details.
-
A cancellation is sent
The cancellation stays open — and keeps being chased — until the supplier acknowledges it.
-
The dashboard shows what is still open
Live KPI dashboards show unconfirmed services and unacknowledged cancellations by departure date, so nothing is discovered on arrival.
Before and after
| Before | With the platform |
|---|---|
| A shared list of pending confirmations, updated by hand each morning | A live queue of every unconfirmed service, with reminders sent automatically |
| A changed service keeps its old confirmation by mistake | Any change sends the service back to the queue for a fresh confirmation |
| A cancellation is "done" once the email is sent | A cancellation is done once the supplier acknowledges it |
| Supplier replies live in personal chats and inboxes | Replies are attached to the booking through the platform's messaging |
| A disputed no-show charge is argued with an outgoing email | The acknowledgement, or its absence, is on the record and was chased in time |
What it does not do
- It cannot make a supplier reply; it makes the missing reply visible and keeps reminding.
- Acknowledgement depends on the supplier's connection: API suppliers acknowledge automatically, others through the channels they use.
- It does not settle billing disputes with a property; it gives the operator the record to do so.
Questions about this scenario
What went wrong with the cancelled hotel night in this scenario?
The cancellation was sent but never acknowledged by the property, so the operator had no proof it had been received when the no-show charge arrived.
Would the operator still need its morning check?
The queue replaces the hand-made list: the morning check becomes working the items still waiting in the queue rather than rebuilding the list.
What happens to a confirmation when a pickup time changes?
The service goes back into the queue and needs a fresh confirmation, so an old confirmation is never mistaken for the new details.
How does this help a supplier that only answers on a messaging app?
The reminders and the supplier's reply can run through the platform's messaging channels, so the conversation is attached to the booking instead of living on one person's phone.
Related
About this page. This is an illustrative scenario: the business is hypothetical and the story is drawn from problems that travellers and travel agents describe in public forum discussions. It contains no customer names and no performance figures. The problem itself is explained on Booking confirmation tracking; for measured results from named customers, see the case studies.
Recognise this situation? We will walk through it on the platform with your own bookings. The full explanation of the problem — causes, approach and limits — is on Booking confirmation tracking.
