Shared Holiday Home Booking Change Log Template

A shared holiday home booking change log should record the original confirmed booking, the requested change, the current rule or source, the valid decision route, the final calendar state, who was notified, which dates returned to the pool, and every unresolved follow-up. The live calendar should still show the current truth; the log explains how that truth changed.

Use this template when a private family, friend, sibling, trustee, or small co-owner group changes or cancels an already confirmed stay. It can cover a cancellation, release, swap, extension, reduction, correction, or maintenance conflict without turning a chat message into an entitlement. A record coordinates the change. It does not create permission, determine a refund, override governing documents, or prove that an approval was valid.

Copy This Booking Change Log Template

Give each change a stable ID such as BCL-014. Link it to the original booking rather than overwriting the history before the final position is clear.

Copy this compact version into a shared document, form, spreadsheet, or task system:

Change ID, opened time, coordinator, status:
Original booking ID, holder, scope, dates, confirmation reference:
Requested change type, proposed dates or scope, request time:
Current policy or source, version, and link:
Decision route, required participants, deadline, and conditions:
Decision reference and approved outcome:
Final calendar holder, dates, status, released availability, and update time:
Affected people, notice channel, notice time, and acknowledgement:
Cost or refund question reference, source, owner, and status:
Guest, maintenance, cleaning, access, or property handover:
Open tasks, assignees, due dates, and escalation route:
Calendar verifier, close-out evidence, closed time, and review trigger:

Recommended statuses are requested, checking source, waiting for decision, approved pending calendar, declined, calendar updated pending notices, blocked, completed and verified, and superseded. Avoid “cancelled” as the only status: it may be unclear whether the request was cancelled, the booking was cancelled, or the dates were actually released.

Keep the Policy, Calendar, Change Log, and Decision Log Separate

These records answer different questions:

1. Booking policy: what the group has already agreed about ordinary dates, peak access, cancellations, swaps, guests, maintenance blocks, approvals, and exceptions. Build that foundation with the 12-decision vacation home booking-rules guide.
2. Live booking calendar: who may use the home now, on which dates, in which room or property scope, and when the property is blocked.
3. Booking change log: what changed after confirmation, which source applied, which route decided it, how the calendar was updated, and which follow-up remains.
4. Decision log: the final wording, authority, effective date, superseded position, and review trigger for a durable policy or exception decision. Use the shared holiday home decision log when the group changes the rule itself.
5. Changeover or maintenance record: the property state and work between stays. A booking change may link to the changeover handover record, but it should not copy the property report.

For example, BOOK-208 may be the confirmed stay, BCL-014 the request to release it, DEC-033 a separately approved one-off exception, and BOOK-219 the replacement booking. Stable references make the sequence readable without creating another calendar.

Use Change Categories Without Pretending They Are Universal

The following labels are operational prompts. Their meaning must come from the group's current policy and governing sources.

Correction

Use a correction when the live record does not match the already approved booking: a mistyped departure date, wrong room, duplicate entry, or missing holder. Preserve the incorrect state, identify the supporting confirmation, correct the calendar, and verify that no other booking was displaced.

A correction should not be used to hide a new request. If the household wants an extra night that was never approved, record an extension request instead.

Cancellation or release

A cancellation may end a confirmed booking under the applicable process. A release may return all or part of the dates to the group's available pool. Those outcomes can be connected, but they are not always identical.

Record whether the original booking changed status, which dates became available, when other households could request them, and whether a waitlist or priority route applied. The log should not assume that a message automatically released the dates or that the cancelling household kept or lost an allowance.

Swap, transfer, extension, or reduction

A swap connects two proposed booking changes. Each affected booking needs a clear before-and-after state, applicable policy, valid confirmation, and final holder. Do not mark either side complete while only one calendar entry has changed.

An extension or reduction changes a boundary. Recheck overlap, bookable unit, stay limits, changeover time, room use, maintenance blocks, guests, and any source-based preparation. A one-night edit can affect the next household even when the original holder stays the same.

Maintenance conflict

A maintenance issue may require a provisional or confirmed block, a shortened stay, a move, or no booking change at all. Link the applicable property record, approved scope, decision route, expected review time, and the person who will remove an unused block. Do not use the booking log to diagnose risk, certify work, expose access details, or reinterpret a provider report.

Move One Change From Request to Verified Calendar

Use the same sequence even when the change feels obvious.

1. Freeze the original reference

Capture the booking ID, holder, dates, rooms or property scope, status, and confirmation reference before editing. A screenshot can help with a disputed technical error, but a structured text record is easier to search and compare. Keep only the evidence needed for the operational purpose.

2. Make the request specific

State the requested change and the desired final state. “We cannot come” is context, not a complete calendar instruction. A usable request might say: “Household B requests release of BOOK-208, 12–16 October, back to the ordinary pool under policy version 4.”

The requester does not need to share a private medical, work, relationship, or financial reason unless a current source genuinely requires particular information through an appropriate route. Record the minimum needed to coordinate the dates.

3. Check the current source

Open the actual policy, governing document, payment arrangement, provider term, maintenance source, or qualified advice that applies. Record its version and where authorised readers can find it.

If the group cannot locate the source, mark the change checking source or blocked. Do not reconstruct a binding deadline, penalty, approval threshold, refund, or use right from memory. The shared holiday home document register can help identify the current controlled copy without duplicating it in the change log.

4. Follow the valid decision route

Identify who can confirm an ordinary in-policy change and who must decide an exception. Record required participants, conflicts, deadline, conditions, and the final decision reference. The person entering the log may coordinate the route without having authority to approve it.

If the request changes a durable rule, create a separate decision-log entry with an effective date and transition plan. Do not quietly rewrite the policy inside one booking record.

5. Update the live calendar once

Apply the approved outcome to the agreed source of truth. Record:

• the final holder and status;
• arrival and departure boundaries;
• rooms or whole-property scope;
• dates returned to general, waitlist, rotation, or other approved availability;
• any replacement booking or linked maintenance block;
• the person and time of the update; and
• the person who independently checked the final state when the change is complex.

The shared holiday home calendar guide helps groups choose the live system. The change log should link to that system, not compete with it.

6. Notify only the people who need the outcome

Tell affected households which dates and responsibilities changed. Notify the appropriate guest, cleaning, access, maintenance, or provider coordinator when their work depends on the booking. Use the approved contact route and record delivery or acknowledgement only when the group's process needs it.

Avoid copying a full guest list, travel itinerary, phone directory, access code, private reason, provider credential, or dispute history into a widely visible log.

7. Hand off costs and property work

A change can create a question about cleaning, preparation, deposits, tickets, provider charges, allowance, refund, contribution, or another cost. Record the question, applicable source, evidence owner, authorised reviewer, and separate record. Do not declare an amount payable or refundable merely because the booking changed.

Likewise, move property observations and work into the relevant task, maintenance log, provider record, or handover. Keep the booking log focused on dates, source, decision, notice, and coordination.

8. Verify the outcome before closing

Close the record only when:

• the original request has a clear outcome;
• the live calendar shows the approved dates, holder, scope, and status;
• released availability is visible through the correct route;
• affected people received the final operational information;
• cost, guest, access, cleaning, or maintenance questions are closed or assigned; and
• every remaining task has an owner, due date, and escalation route.

If one condition is missing, use an honest status such as calendar updated pending notices or blocked.

Handle Peak Dates and Waitlists Transparently

Peak changes can affect more than the cancelling household. Record which named period, rotation position, points, allowance, waitlist, response window, or release route applies under the group's existing rule. Show the final calendar result and the next eligible action without publishing a universal method.

The free usage rotation planner can help a group model fictional household and date allocations before it changes a rotation. It does not approve a real swap, interpret an agreement, or update the live booking calendar.

When nobody accepts released dates, record that the availability remained open or expired under the approved process. Do not edit the history to make the allocation look fully used.

Worked Example: One Released Stay, One Replacement Booking

This example is fictional. Its dates, statuses, decision route, timing, and cost treatment are not recommendations for another property.

Four households privately share a coastal cottage. Household B has confirmed booking BOOK-208 for 12–16 October. It requests release of the whole stay. The current policy says ordinary released dates return to a named group pool after the calendar coordinator verifies the change.

The change log does not decide whether Household B owes or receives money. It proves only that the group preserved the original booking, followed its current process, restored the dates, recorded the replacement, reassigned operational work, and gave the separate cost question an owner.

Review Patterns Without Rewriting History

Review open changes at an interval suited to the next affected stay, then examine patterns during the group's normal booking-policy review. Ask:

• Are changes waiting on a source or decision after the calendar deadline?
• Do released dates actually return through the approved route?
• Are swaps leaving one side incomplete?
• Are maintenance blocks remaining after the work or visit was cancelled?
• Do guest, cleaning, access, or provider handovers follow the final booking?
• Are cost questions being hidden inside calendar notes?
• Are repeated exceptions showing that the policy itself needs review?
• Is the log collecting more personal information than the group needs?

Preserve completed records according to the group's current operational, contractual, privacy, insurance, accounting, or professional requirements. Do not publish a universal retention period. Mark a corrected or superseded entry honestly rather than deleting the sequence that explains the calendar.

FAQ

What is the minimum booking change record?

Record the original booking ID and dates, requested change, current rule or source, valid decision route, approved outcome, final calendar state, affected notices, and any open action. For a simple correction, this can be one compact row.

Does a cancellation message cancel the booking?

Not necessarily. The effect depends on the group's current policy, governing documents, system, provider terms, payment arrangements, and applicable requirements. Keep the booking unchanged or honestly pending until the valid route produces a final outcome, then update the live calendar.

Should the reason for cancelling be recorded?

Usually the operational record needs the requested outcome, not a detailed personal explanation. Collect only what the applicable source and valid decision route genuinely require. Keep medical, work, relationship, travel, and financial information out of a broad group log by default.

How should a swap be logged?

Reference both original bookings, both proposed final holders and date ranges, the applicable rule, each required confirmation, and the final calendar updates. Do not close the swap while only one side has changed.

What if a booking change creates a refund or cost question?

Link the applicable rule or provider term, evidence owner, authorised reviewer, status, and separate financial record. The booking log should not store sensitive payment details or declare a result before the appropriate route confirms it.

When does a policy exception need a decision-log entry?

Use a separate decision record when the group needs to preserve approved wording, authority, conditions, effective period, expiry, transition, or a durable change to the rule. Link the booking change to that decision instead of copying it.

Can Shared Holiday Homes replace the group's agreement or adviser?

No. Shared Holiday Homes is coordination software for groups already sharing a private holiday home. It does not sell property shares, manage the property, create ownership rights, interpret contracts, or provide legal, tax, financial, insurance, or safety advice.

Keep Every Changed Stay Traceable

Shared Holiday Homes can keep the current booking calendar, assigned follow-up tasks, house documents, and property information together for an existing private co-owner group. Use the change log to preserve the route from original booking to verified outcome, while the live calendar remains the source of truth.

When your group is ready to replace scattered change messages with one visible operating system, start a free trial.