Shared Holiday Home Guest Request Template

A shared holiday home guest request should record who is responsible, the requested dates, the guest-use category, the live booking, the current policy source, the approval result, the access window, the approved stay guide, and the final close-out. It should apply a rule the co-owners have already agreed; it should not invent permission in a group chat.

Keep the record small. A party label and number of invited people may be enough for ordinary coordination. Do not collect identity documents, health histories, relationship details, travel plans, payment information, screening notes, or permanent access details unless a current, applicable source genuinely requires them and the group has a suitable restricted place to keep them.

This template is for private families, friends, siblings, trustees, and small groups coordinating invited use of a home they already share. It is not a holiday-rental booking form, tenancy, licence, waiver, or source of authority. Paying guests, events, exchanges, or other accommodation activity may raise different legal, insurance, tax, building, safety, and privacy requirements.

Copyable Shared Holiday Home Guest Request

Copy this into the group's approved request form, shared document, or task. Replace the prompts with facts from the current guest policy and live calendar.

• Request ID: [short stable reference]
• Requesting co-owner or household: [name used by the group]
• Responsible owner for the stay: [one person or household]
• Guest-use category: [accompanied / unaccompanied / day visitor / other approved category]
• Requested arrival and departure: [date and agreed time boundary]
• Live booking reference: [calendar entry or pending-request link]
• Party size and space needed: [number plus rooms or shared areas to check]
• Current policy source: [guest-rule title, version, and location]
• Checks required by that source: [capacity, building, insurer, safety, accessibility, or other property-specific check]
• Decision route: [who may decide and by when]
• Decision: [pending / approved / approved with recorded conditions / declined / withdrawn]
• Decision record: [decision-maker, date, source applied, and reason category]
• Approved guest guide: [welcome-book version or link]
• Access reference and window: [controlled record reference, start, end, and close-out owner—never the credential itself]
• Arrival, departure, and changeover actions: [owner, task, and due point]
• Exception or change reference: [only when needed]
• Close-out: [calendar final, access closed, departure confirmed, issue assigned, record closed]

Use not applicable when a field genuinely does not apply. Do not leave an important field blank and let the next person guess whether it was forgotten.

What Each Field Is For

The request should connect the policy decision to the operational handoff without becoming a dossier about the invited people.

Define the Guest-Use Category Before Deciding

The word “guest” can hide several different situations. Give each approved category a plain definition in the group's policy, then select one in the request.

Accompanied guests

The responsible co-owner stays at the property with the invited people. The request still needs dates, party size, booking impact, applicable house rules, and any property-specific checks. Presence does not automatically override capacity, building, insurer, safety, or event restrictions.

Unaccompanied guests

Invited people stay without a co-owner present. If the current sources allow this, name one responsible owner for approval, pre-arrival information, access, contact during the stay, departure, and issue reporting. “They know the house” is not a replacement for a named responsibility path.

Day visitors

People visit but are not expected to stay overnight. A group may decide that ordinary small visits do not need a request, while larger gatherings, use of shared facilities, parking pressure, or another defined trigger does. Use the group's sourced rule; do not quietly turn a day visit into an overnight stay or event.

Providers are not ordinary guests

Cleaners, tradespeople, inspectors, caretakers, and delivery providers have a different purpose, access scope, evidence trail, and follow-up. Use the provider visit record for an approved appointment rather than forcing provider work into a social-guest form.

A paid stay, home exchange, public event, or stranger-arranged visit also needs its own properly sourced route. This template does not convert any of those uses into private invited use.

Run the Request From Policy Check to Close-Out

1. Start with current authority, not precedent

Find the current guest rule and record its title, version, and controlled location. Check any governing document, trust or entity rule, insurance condition, lender term, building or community rule, local occupancy or accommodation requirement, and safety source that applies to this property and proposed use.

A previous stay is evidence that someone stayed before; it is not proof that the same use remains authorised now. If the sources conflict or the decision-maker is unclear, pause the request and obtain appropriate local or professional advice.

2. Connect the request to the live calendar

Record the exact arrival and departure boundaries, not “next weekend.” Link the pending or confirmed booking and check:

• whether the dates are open;
• whether the guest category uses the requesting household's allowance;
• whether a co-owner must be present;
• whether a cleaning, maintenance, or empty-night buffer applies;
• whether another household shares any room or facility during the stay; and
• what happens if the request changes.

The vacation home booking rules guide helps the group define those rules. This request applies the current rule to one proposed stay; it does not replace the live calendar.

3. Ask only the capacity and space questions the property requires

Record the total party size and the rooms or shared areas that need checking. Then use current property-specific sources for sleeping spaces, water or septic constraints, parking, shared facilities, fire or building requirements, insurer conditions, and any other relevant limit.

Do not publish a universal “safe” number or assume that the number of beds establishes lawful or appropriate occupancy. If children, accessibility requirements, animals, vehicles, boats, pools, fires, or equipment change the preparation, record the practical action needed and the source—not a speculative diagnosis or personal profile.

4. Name one responsible owner

One owner or household should hold the operational thread, even if another person approves the request. The responsible owner should know who will:

• keep the calendar accurate;
• send the approved guide;
• arrange only the access already authorised;
• remain reachable through the agreed contact route;
• confirm the departure and access close-out; and
• create a task for damage, missing items, cleaning, or another unresolved issue.

This is responsibility for coordination, not a promise of legal liability or a transfer of another person's formal duty.

5. Record a real decision

Use a short set of states: pending, approved, approved with recorded conditions, declined, or withdrawn. An approval should name the decision-maker, decision date, applicable source, and any conditions already permitted by that source.

Avoid copying sensitive arguments into the shared record. A neutral reason category such as date conflict, current policy does not allow unaccompanied use, required source unavailable, or request withdrawn is often enough. If the decision creates or changes a durable rule, record that separately in the shared holiday home decision log.

6. Handoff the approved guide and controlled access

Approval should trigger one current set of stay instructions. Link the exact guest welcome book version that covers arrival, parking, house rules, equipment, emergency information, issue reporting, and departure.

Keep the owner-side access lifecycle in the key and access register. The guest request needs only a reference to the approved method, its usable window, and the person who will verify return, expiry, revocation, or replacement. Do not paste a door code, alarm code, password, empty-home schedule, or key location into a broadly visible request.

7. Update changes before the stay

If dates, party size, guest category, responsible owner, spaces, or access needs change, return to the relevant policy check. Do not edit the original request so heavily that nobody can see what was approved.

Use a short change note with the previous value, proposed value, person raising it, required recheck, decision, and final calendar action. A date change that affects a confirmed stay also belongs in the booking change log.

8. Close the request after departure

A request is closed when the group can see that:

1. the calendar shows the final stay;
2. the approved access action is complete;
3. the responsible owner confirmed departure or recorded why confirmation is unavailable;
4. the agreed changeover action was completed or assigned;
5. any issue has its own task, maintenance record, expense route, or decision reference; and
6. the guest request contains no unnecessary live credential or personal detail.

Do not keep a guest request open as a substitute for resolving the issue it uncovered. Move durable work to its proper record and close the stay-specific thread.

Keep Personal Information Proportionate

Start by defining why the group needs each guest-related field. For example, party size may support a current capacity check; a responsible owner supports contact and close-out; a practical accessibility request may support preparation. Those purposes do not automatically justify copies of passports, dates of birth, medical histories, family relationships, employer details, travel itineraries, payment cards, background checks, or free-text opinions.

As an explicitly UK-labelled example, the Information Commissioner's Office data-minimisation guidance says personal data should be adequate, relevant, and limited to what is necessary for the stated purpose, with periodic review and deletion of data no longer needed. Use the privacy law and official guidance that apply to the property, group, and processing; the UK example is not universal legal advice.

Use these practical boundaries:

• record what preparation is needed rather than a person's diagnosis;
• keep a guest's private contact route only where it is necessary and appropriately restricted;
• link to a controlled source instead of duplicating sensitive material;
• state who can see the request;
• set a review or deletion point based on the applicable purpose and rules; and
• never reuse guest information for an unrelated purpose just because it is available.

If an insurer, building, authority, or other current source requires specific identity or stay data, record the requirement and controlled location. Do not spread the data through chat, calendar descriptions, and several copies of the form.

Fictional Example: An Unaccompanied Weekend

The following example is fictional. It shows the record flow, not a recommended approval threshold, capacity, access method, or legal result.

Four households privately share a lake house. Their current guest policy allows an unaccompanied stay only when the requesting household remains responsible, the dates are within that household's allocation, the current property and insurer checks pass, and the named administrator records the decision.

The useful result is not the fictional approval. It is the visible chain from current policy to dates, responsibility, decision, stay instructions, controlled access, and closure.

A 15-Minute Guest-Request Review

For an ordinary request that fits a settled policy, the reviewer can use this sequence:

1. Two minutes: identify the guest category and responsible owner.
2. Three minutes: verify the dates, booking reference, party size, and spaces affected.
3. Four minutes: open the current policy and each required property-specific source.
4. Two minutes: record the authorised decision route and result.
5. Two minutes: assign the welcome-guide and access handoff.
6. Two minutes: set the departure, close-out, and exception route.

Stop the clock when authority, capacity, insurer, building, safety, accessibility, or privacy requirements are unclear. A fast form should make a settled request easier to process; it should never pressure someone to invent an answer.

Frequently Asked Questions

Does every invited person need a separate request?

Not necessarily. The group can define one request per invited party or stay if that provides the facts its current sources require. Avoid separate identity records when a party count and responsible owner are sufficient.

Should accompanied guests go on the shared calendar?

Follow the group's booking policy. The calendar should show the confirmed stay and responsible household clearly enough to avoid conflicts, while guest details should remain limited to what the calendar audience genuinely needs.

Can a co-owner approve their own guest request?

Only if the current governing and operating sources give them that authority. Record the applicable route instead of assuming that ownership, payment, past practice, or calendar access equals approval authority.

What if the number of guests changes?

Record the change and repeat every affected capacity, room, parking, insurer, building, safety, and approval check. Update the live booking only after the revised request reaches its required decision state.

Should the form include an access code?

No. Reference the controlled access record, approved method, usable window, and close-out owner. Keep the live credential only in the restricted channel intended for it.

Is a guest request the same as a rental agreement?

No. This template coordinates private invited use under an existing co-owner policy. It does not create a tenancy, licence, rental, waiver, insurance cover, or legal permission.

What should happen if a guest reports damage?

The responsible owner should follow the current reporting and urgent-protection process, then move the issue to the appropriate maintenance, expense, insurer, safety, or decision record. Keep the original guest request as the stay reference, not the entire investigation.

Keep Guest Coordination in One Visible Flow

Use the free holiday home guest welcome book generator for the approved stay-facing instructions, and use the house rules generator as a discussion draft before the group adopts any rule. Keep the live booking, responsible owner, assigned handoff, approved property information, and supporting house document aligned.

Shared Holiday Homes gives private co-owner groups one place for bookings, shared tasks, property guides, and house documents. It does not grant guest authority, set occupancy, verify insurance, issue credentials, or replace local professional advice. Start a free trial when the policy is settled and the group wants a clearer operational handoff.