How It Works — Dead Beds¶
Who this is for: reservations consultants, camp revenue and operations managers, and anyone asked why a booking will not go through when the camp "has space".
Written from the application's own logic. Anything the system does not state outright is marked (inferred) and worth confirming with the development team.
The one-paragraph version¶
When a booking would leave a bed that nobody else can sell, the system calls that bed dead. It checks this only for camps in months you have configured as sensitive, only when travel is more than eight weeks away, and only for Wish-managed accommodation. If dead beds would be created, the line is not booked — it is waitlisted, the consultant sees what it would cost, and a manager can override it. The override is recorded against the booking line with the manager's name, and an email goes out with the value of the beds being sacrificed.
What counts as a dead bed¶
Take the day before your stay starts. If more rooms are free on that day than on the two days around it, and those two neighbouring days together cannot absorb what is free, then taking your rooms strands the leftovers: nobody can book a single night with nothing either side of it.
The system counts those stranded beds by room type — double, family, honeymoon, twin — and does the same check at the end of the stay. Only whole beds are counted, never a value.
One important subtlety: if the camp already had dead beds before your booking, only the extra ones caused by your booking are counted. If your booking creates the situation from nothing, the whole count is yours.
When the check runs — and when it does not¶
| Condition | Effect |
|---|---|
| Accommodation is not Wish-managed | no check |
| Travel starts within 8 weeks | no check |
| No dead-bed month configured for that camp covering your dates | no check |
| Room selection screen never opened | no check — nothing runs in the background |
That last one matters for reporting: dead beds are only counted when someone looks. There is no nightly job.
The sensitive periods are maintained per camp under RARA → Dead Beds, as date ranges. Two ranges are consulted — one for the start of the stay, one for the end.
What a consultant sees¶
The message is deliberately not an error:
"As the booking … is creating deadbed(s) and occupancy at this time is very high, this can only be booked by a Wilderness Manager. It will however be waitlisted in the meantime."
Alongside it, the system works out what the sacrifice is worth: the rack price for the room type multiplied by the number of dead beds, and the dead beds as a percentage of the rooms in the booking. That figure appears in the warning and in the email to the managers. It is an indicative rack value, not the price of your booking.
(inferred) The intent is a negotiating figure: "these beds are worth this much — is the booking worth more?"
The override¶
A manager overrides on the accommodation line. When they do:
- the room configuration is marked as overridden, with the manager's name;
- an event is logged on the booking — "Deadbeds overridden by manager on this booking line";
- an email goes out with the camp, the nights, the number of dead beds and their rack value;
- the booking line records who approved it.
The override does not stick to a changed selection. If the room configuration is re-checked after a change, the line-level approval is cleared and must be granted again. That is intended (inferred) — the approval was for the beds as they stood.
One caveat worth knowing: the "only a Wilderness Manager" restriction is stated in the message but is not enforced by the logic itself. Whether the button is limited depends on page security, which the development team should confirm.
Where the numbers come from, and where they can mislead¶
Availability "after waitlist". The check reads availability after waitlisted demand, not raw availability. A camp can look free and still be counted as generating dead beds because waitlisted guests are already accounted for.
Duplicate availability records produce 99. If a camp has duplicated availability rows for a date, the system cannot do the arithmetic. It logs a critical fault, tells the user it could not check — and returns 99 as the count. Downstream, 99 is treated as a real number: the booking is blocked and the email quotes the rack value of 99 beds. If you ever see 99, or a value in the email that looks absurd, that is what happened. This is a defect, not a business rule.
The availability screens check the end of the stay against the wrong month. On the availability and trip-finder screens (not the booking wizard), the end-of-stay check is switched on by whether the start date falls in a dead-bed month. A stay that ends in a sensitive month but starts outside one is therefore not checked at the end there. The booking wizard does this correctly. Also a defect.
On those same screens, doubles are now checked as twins. A change made on 2026-08-19 merged the two: the number of double and twin rooms is added together and checked against twin availability. Double dead beds can therefore be missed on the availability screens while the booking wizard, which still checks four room types separately, reports them.
And the wording at the start of a stay always says "twin". "2 twin room(s)" may mean two family rooms or two honeymoon rooms; the room type in that sentence is hard-coded. The end-of-stay sentence names the type correctly. Read the type from the booking, not from the message.
Who is told, and how¶
| Audience | Channel |
|---|---|
| Consultant, at the point of booking | on-screen message plus a logged warning |
| Reservations and operations manager of the branch | email, when an override happens or clearance is requested |
| Partner channel (ITRVL) bookings | the same warning with additional wording about high occupancy |
Reporting on dead beds¶
The only durable record of a verdict is a log of the three days that produced it, kept for roughly 30 days — older entries are deleted by the next check. Counters live on the room configuration for the booking line, so a booking that was never completed leaves nothing behind.
The verdict itself is temporary. The "dead beds not allowed" marker is cleared by almost anything that recalculates availability: reopening room selection, rebuilding the room configuration, a partner system changing dates, or a held line expiring. It says what the last calculation found, not what happened on this booking.
Anyone building a dead-bed report should know that: this is not an audit trail, the absence of dead beds in the data may mean nobody opened the screen, and a booking that was refused earlier can show a clean marker later.
One asymmetry to be aware of when auditing overrides: the approval recorded on the booking line is cleared whenever the selection is re-checked, but the approval recorded on the room configuration is never withdrawn once given. A room configuration that a manager approved stays approved.
Glossary¶
| Term | Meaning |
|---|---|
| Dead bed | a bed left unsellable by the shape of a booking |
| Dead-bed month | a configured date range, per camp, in which the check applies |
| After waitlist | availability with waitlisted demand already deducted |
| Override | a manager's decision to accept the dead beds and book anyway |
| Potential dead beds taken up | the opposite case: a booking that absorbs beds that would otherwise die, which the pricing rules can discount (inferred) |
Where the detail lives¶
Dead beds — developer reference has the arithmetic, every node number and the seven known defects. Regression suite has the cases to test.