How It Works — Cancellations, Changes and Fees¶
Who this is for: anyone who needs to understand what happens when a booking is cancelled or changed, and how Wilderness decides what to charge. Product managers, business leads, finance, anyone joining a conversation about cancellation policy or a disputed fee.
What this is not: a statement of policy. This describes what the software currently does. Where that differs from what the business believes, the software is what clients experience.
Companion to How It Works — From Quote to Booking.
The one-paragraph version¶
Cancelling is three different things wearing one button. An empty draft is deleted outright. A booking with nothing owing is cancelled and disappears. A booking where money is owed is cancelled with costs — it stays visible, carrying the fee. Which one happens is decided by the system, not the user. The fee itself comes from the supplier's payment terms where those are configured, and from a hardcoded fallback ladder where they are not — and that fallback is expensive.
The three outcomes¶
| Outcome | Shows as | When it happens | What the client sees |
|---|---|---|---|
| Deleted | nothing — the record is gone | An empty draft: no itinerary built, never sent to Tourplan | Nothing. It never really existed |
| Cancelled | "Canc" | Nothing is owed | Booking gone, no charge |
| Cancelled with costs | "CCost" | At least one line attracts a fee | Booking gone, but an invoice follows |
Two things worth knowing about this:
- Deletion is real deletion. The booking row is removed. An archive log entry is written first, recording what was deleted and why, but the booking itself is not recoverable from the Window. This only happens to bookings with no itinerary and no Tourplan record.
- "Cancelled with costs" is sticky. Once a booking reaches CCost it can never be downgraded to a plain cancellation, even if cancelled again. That is deliberate: the money is owed.
How the fee is decided¶
Five questions, in order. The first "no" ends it with no fee.
1. Has someone overridden fees on this booking? yes -> NO FEE
2. Is the line chargeable? no -> NO FEE
3. Is the line confirmed? no -> NO FEE
4. Was the line ever written to Tourplan? no -> NO FEE
5. Does the fee percentage come out above zero? no -> NO FEE
yes -> charge it
Question 4 is the one that surprises people. A booking that was held provisionally but never confirmed into Tourplan cancels free, no matter how close to departure it is. All the commercial risk sits on the confirmation step, not on the hold.
Where the percentage comes from¶
First choice: the supplier's configured payment terms. If RARA has set up payment terms for that supplier, the cancellation percentage on those terms is used, full stop. This is the intended path and it is where policy should be expressed.
Fallback: a hardcoded ladder in the software. Used only when no payment terms exist. It is not configurable and changing it requires a code change.
| Product | More than 60 days out | 60 days or less |
|---|---|---|
| Camp accommodation, explorations, private activities | 25% | 100% |
| Flights | More than 7 days | 7–4 days | 3 days | 2 days | 1 day or less |
|---|---|---|---|---|---|
| 0% | 25% | 50% | 75% | 100% |
| Everything else (transfers, sundries, and so on) | any timing |
|---|---|
| 0% |
Associated-product suppliers are charged 100%, always — at any notice, even a year out — whenever payment terms are missing for them. These are identified by a fixed list of ownership codes written into the software.
The fallback used to be gentler¶
The system still carries a written record of the previous fallback scale, used for bookings confirmed before 31 December 2020:
| Notice given | Old fee | Current fee (accommodation) |
|---|---|---|
| 56 days or more | 20% | 100% |
| 28–55 days | 45% | 100% |
| 21–27 days | 50% | 100% |
| 14–20 days | 60% | 100% |
| Under 14 days | 100% | 100% |
| More than 60 days | — | 25% |
The old scale was graduated across five bands; the current one has two, with a cliff at 60 days. Between 56 and 60 days' notice the charge went from 20% to 100%.
A graduated scale looks like a commercial position somebody decided. A two-band scale with a cliff looks like a default nobody revisited. That distinction matters when deciding whether to treat the current fallback as policy or as a gap to close.
Why this matters commercially¶
The fallback ladder is a master-data failure mode, not a policy. Its cliff edges are steep:
- Camp accommodation goes from 25% to 100% overnight at the 60-day mark. There is no middle band.
- An associated-product supplier with a missing payment-terms record charges the client the full value of the line regardless of notice given.
- A booking line with a missing travel date also charges 100%.
If a client disputes a fee that looks disproportionate, the first thing to check is whether payment terms exist for that supplier. A 100% charge at 90 days' notice is almost certainly a missing configuration record, not a deliberate commercial decision.
The percentage is also per line, not per booking. A cancelled trip can charge 25% on the camps, 0% on the transfers and 100% on one associated-product line, and the client sees the total.
What the fee does to the numbers¶
When a fee is applied, the line's price is replaced by the fee amount. A £1,000 line at 25% becomes a £250 line, with the £750 written off recorded separately. The line stays visible on the booking — that is how the charge reaches the invoice.
This is why a cancelled-with-costs booking still shows lines and still has a value. Those are fees, not the original trip price.
The fee override¶
There is a button, "Override cancellation fees", that switches off all cancellation fees for a booking. There is also a cancel-with-no-fees route that sets it automatically and records the cancellation as a presumed postponement.
Two things the business should be aware of:
It requires no approval and no manager. Any consultant — including an external consultant — can waive every fee on a booking. The only record is an entry in the booking's event log. By comparison, extending a provisional hold by a few days is manager-only. That asymmetry looks unintentional and is worth a policy decision.
The cancellation reason does not drive the fee. The reason list includes "Cancelled but not charging fees as a favour to agent" and "Trip postponed no fees charged" — but selecting either of those does not switch fees off. The reason is recorded for reporting; the override is a separate flag. It is entirely possible to record "not charging fees as a favour" and still charge the client.
For reporting on waivers, count the override flag, not the reason. They will not agree.
What else happens when a booking is cancelled¶
Beyond the money:
- Camp and airline holds are released.
- Third-party and channel inventory is released.
- Itineraries are removed from Wetu.
- Guests are cancelled.
- The consultant and agent are e-mailed.
- The booking is flagged for Tourplan to be updated.
- Open error records against the booking are automatically closed and marked resolved.
That last one is worth flagging: cancelling a booking erases its error history. If a booking is being cancelled because something went wrong, the diagnostic trail goes with it. Investigate before cancelling, not after.
If the camp inventory system rejects the cancellation, the whole thing stops — the booking is not marked cancelled — and it becomes a manual task for a consultant. The client-facing message says so.
Two different messages, two different meanings¶
- "Your booking has been successfully cancelled and the reserved inventory has been released where applicable" — nothing owed, nothing further to do.
- "A consultant has been informed of the cancellation of this booking and will be in contact with you in the event of any financial settlement. Please be aware that we can not show this financial settlement in the Wilderness Window." — this booking reached Tourplan. Any settlement is handled outside the Window.
What cannot be cancelled¶
| Situation | What happens |
|---|---|
| Trip already travelling or travelled | Blocked. "Please get your manager to speak to WW support" |
| Booking is ex-Window | Blocked. It must be handled in Tourplan |
| Booking is confirmed in Tourplan | Blocked from the overview grids — must be cancelled from the booking file |
One inconsistency worth knowing: there are two routes to the cancel confirmation screen, and they do not enforce the same rules. One blocks travelled bookings outright; the other lets a manager through. One blocks Tourplan-confirmed bookings; the other does not check at all. Which route a user gets depends on which screen they started from. This is on the defect list.
Undoing a cancellation¶
There is a "Revive cancelled booking" button, but only support staff can use it. There is no self-service undo for consultants or agents.
More importantly, reviving is not a restore:
- The booking returns to Draft.
- Its link to the camp inventory system is deleted, not restored. All previous holds are gone.
- Room configurations, booked room counts and holding-space flags are all reset to zero.
- The booking must be re-priced and re-provisioned from scratch.
Reviving recovers the paperwork, not the space. If the camps have since sold the rooms, they are gone. Treat cancellation of a confirmed booking as effectively irreversible from a commercial standpoint, and make sure consultants understand that before they click.
Waitlists¶
When a booking asks for space that is not available, accommodation lines are waitlisted rather than lost. A scheduled job then releases waitlists — meaning it gives up and removes the line, notifying the consultant.
Waitlists are released in two situations:
- Space came free and the waitlist has been sitting for at least two days.
- The trip departs within 42 days — released regardless of whether space ever became available.
The second rule is the commercially significant one: any waitlist on a trip inside six weeks is dropped as a matter of course. If the business believes waitlists are held until departure, that is not what happens.
And the six weeks looks like a mistake. The note the developers left on this process says it clears waitlists "for trips with less than 8 weeks to go" — but the system is set to 42 days, which is six weeks. The 48-hour part of the same note matches the system exactly, which suggests the note is accurate and the number is wrong. If so, waitlists are being released a fortnight earlier than intended. This needs a decision, not a fix: eight weeks and six weeks are both defensible, but only one is what was agreed.
Two limitations worth knowing:
- The job does not run at weekends.
- It only processes bookings owned by a Wilderness consultant. Waitlists on agent-owned bookings are never released and no notification is sent. Either they are handled somewhere else, or they accumulate — worth confirming with the reservations team.
Housekeeping¶
The system quietly removes abandoned work:
| What | Condition | Action |
|---|---|---|
| Empty Step-1 drafts | No party name, no reference, no dates, never notified | Deleted |
| Old quotes and placeholders | Long past trip end — see the quote-to-booking doc | Deleted |
| Stale provisional bookings | Already cancelled at camp level | Cancelled |
Everything is archive-logged before removal.
The retention periods were agreed, and the archive log's wording is out of date. Quotes are kept for four years after travel — a change agreed on 5 May 2023 by Joe and Francis. The reason text written into the archive log still describes the older rule (six months, from an earlier decision recorded as Ianka's: guests shop around and sometimes want a booking requoted later). The system does the agreed four years; only the label is stale. Don't reconcile deletion volumes against that text.
Where this typically goes wrong¶
| Symptom | Usual cause |
|---|---|
| "Our cancellation numbers look too high" | A report counting the internal "cancel" flag rather than cancellation status. That flag is also set when a partner amends an itinerary and drops a line — see below |
| "The cancellation fee is far too high" | Missing payment terms for that supplier, so the punitive fallback ladder applied. Check master data first |
| "We cancelled 90 days out and were charged in full" | An associated-product supplier with no payment terms — that is a flat 100% at any notice |
| "It charged fees even though we recorded it as a postponement" | The reason field does not switch fees off. Only the override flag does |
| "The booking still shows a value after cancelling" | Those are cancellation fees, not the trip price. The line stays visible to carry the charge |
| "Cancel does nothing / says use the booking file" | The booking is confirmed in Tourplan and must be cancelled from the booking file |
| "We revived the booking but the space is gone" | Reviving clears the inventory link by design. It recovers the record, not the beds |
| "Our waitlist disappeared without warning" | Trip was within 42 days, so it was released automatically |
| "Nothing happened to our agent's waitlist" | Agent-owned bookings are skipped by the release job |
| "The booking was cancelled and now we can't see what went wrong" | Cancellation auto-closes the booking's error records |
A caution for anyone reporting on cancellations¶
Internally, a booking line carries a "cancel" marker meaning this line is going through the removal process. It is set both when a booking is genuinely cancelled and when a partner system amends an itinerary — dropping a night, switching a camp, removing accommodation. The line is removed either way, so the same machinery runs.
Counting that marker will overstate cancellations, because it includes ordinary itinerary
changes. Real cancellations are identified by the booking's status (Canc / CCost) and the
line's status, not by the marker.
Worth checking against any existing cancellation reporting: if the numbers have ever looked higher than the team expected, this is the first thing to rule out.
Who can do what¶
| Action | Agent | Consultant | Manager | Support |
|---|---|---|---|---|
| Cancel a booking | Yes | Yes | Yes | Yes |
| Cancel a travelled booking | No | No | Only via one of the two routes | — |
| Cancel a single line | No | Yes | Yes | Yes |
| Waive all cancellation fees | No | Yes, no approval needed | Only by also holding the consultant role — "manager" is not itself on the permitted list | Yes |
| Revive a cancelled booking | No | No | No | Yes |
| Bulk-cancel bookings | No | No | No | Yes |
Glossary¶
| Term | Meaning |
|---|---|
| Canc / CX | Cancelled, nothing owed |
| CCost / CC | Cancelled with costs — a fee is owed |
| Booking line | One item on a trip: a night at a camp, a flight sector, a transfer, an activity |
| Payment terms | Per-supplier configuration held by RARA, including the cancellation percentage. The intended source of every fee |
| Associated product | A supplier category identified by a fixed set of ownership codes. Charged 100% when payment terms are missing |
| Waitlist | A request held against space that was not available at the time of booking |
| Wetu | The itinerary publishing system |
| Ex-Window | A booking that has left the Window's control and is handled directly in Tourplan |
| Revive | Support-only function returning a cancelled booking to Draft. Does not restore inventory |
Where the detail lives¶
- Engineers:
docs/deep-dives/cancellation-and-fees.md - QA:
docs/qa/regression-cancellation-and-fees.md - The forward path: How It Works — From Quote to Booking
A note on confidence. This was read out of the application's logic, not from policy documents. It is accurate about what the software does; it cannot tell you what was intended. Three things stand out as worth a decision rather than a fix:
- The fee override has no approval step while smaller decisions are manager-gated.
- The 42-day waitlist release drops waitlists regardless of availability — and appears to contradict the eight weeks its own developer note describes.
- The fallback fee ladder is hardcoded, punitive, and invisible to the people whose master data triggers it — and it replaced a graduated scale that looks more like considered policy.
- Cancelling from step 2 may owe camps a notification that was noted as required and never built.
None of these are bugs in the sense of "the code does not do what it says". They are commercial rules that currently live in code rather than in configuration, where nobody outside engineering can see or change them.