Co-Host and VA Runbook for STR Turnovers (RACI + Handoffs)

In this article: how to split turnover work between host, co-host, and virtual assistant without losing the thread — RACI-style clarity and audit-friendly habits.

The useful question is not only whether co-host and va runbook for str turnovers sounds right in theory. It is whether your version still works when the calendar shifts, the cleaner is deciding, or a guest is already expecting an answer.

That is where clearer operating rules help most: they turn a one-time save into something your team can repeat without waiting for the same person to translate the situation again.

In this article

• A lightweight RACI you can paste into Notion or Google Docs
• Turnover-specific responsibilities (bookings, assignments, guest comms, payouts)
• Handoff rules that prevent silent failures
• Where tooling fits without replacing judgment

Definitions

• Responsible: does the work
• Accountable: ultimately owns the outcome (ideally one person per decision)
• Consulted: should be looped in before big changes
• Informed: should be notified after changes

Roles diagram (visual)

Turnover spine — what must stay coherent

Across most portfolios, these objects must stay aligned:

1. Booking truth (dates, checkout time)
2. Job / turnover record (what needs to happen, when)
3. Assignee (who is confirmed)
4. Guest-facing instructions (access, checkout expectations)
5. Money movement rules (if payouts or guest-paid services are involved)

If any of these diverge across people, you get the classic failure: the guest thinks checkout is 11, the cleaner planned for 10, and the co-host is on a flight.

RACI template (copy/paste starter)

Adjust names to your team. The goal is single accountability per critical decision.

Booking changes and calendar hygiene

Staffing and assignments

Guest experience (non-turnover)

Your matrix will differ — the point is to remove guessing.

Handoff rules that prevent disasters

Rule 1 — “Changed time” is an event, not a footnote

When checkout moves, your runbook should require:

• internal record updated
• assigned cleaner notified
• reconfirmation if someone was already locked in

Read: Handling booking changes.

Rule 2 — Guest messaging is a brand surface

If a VA messages guests:

• use approved templates
• define escalation triggers (access failure, damage, safety)
• log what was sent (even a simple log table helps)

Rule 3 — Money needs explicit authority

Payout approvals, refunds, and guest-paid add-ons should have a named approver. “Everyone kind of can” becomes disputes.

What a VA should not do without training

• improvising checkout policy in guest threads
• changing access codes without a documented process
• promising compensation without authority

Tooling: shared truth beats chat volume

Group chats are fine for alerts. They are weak as a database.

If your team is growing, prioritize:

• a canonical place for job status
• visibility into who is assigned
• auditability when booking truth changes

Where the Advice Usually Gets Tested

A guide becomes useful only when it survives a real turnover, a real guest question, or a real schedule change.

Start with the first principle: Ambiguous ownership creates duplicate work or dangerous gaps — especially around booking changes. This matters because guides fail when the advice sounds right on paper but nobody can find the rule when the day gets busy, and around co-host and va runbook for str turnovers the difference between a calm day and a scramble is usually whether that rule was clear before the pressure showed up.

The next idea matters just as much: Write down who may message guests vs who only updates internal systems. This matters because guides fail when the advice sounds right on paper but nobody can find the rule when the day gets busy, and around co-host and va runbook for str turnovers the difference between a calm day and a scramble is usually whether that rule was clear before the pressure showed up.

The third point is really about consistency: A shared system of record beats “everyone is in the group chat.”. This matters because guides fail when the advice sounds right on paper but nobody can find the rule when the day gets busy, and around co-host and va runbook for str turnovers the difference between a calm day and a scramble is usually whether that rule was clear before the pressure showed up.

A Simple Starting Framework

If you want this topic to become repeatable, start by naming three things in writing: the trigger, the owner, and the deadline. That turns a nice idea into an operating rule the next person can actually follow.

Most hosts do not need a giant SOP first. They need one place where the current version of the rule lives, one person who updates it, and one backup path when the plan slips. Around co-host and va runbook for str turnovers, that usually means deciding what information is required, who owns the next step, and what happens if the first plan fails.

• Write the current rule for co-host and va runbook for str turnovers in one shared place.
• Name who owns the next move when something changes.
• Set a deadline or cutoff so the backup path is obvious.

Read Next

• Co-hosts (product)
• Booking changes
• From 1 to 5 properties

Put This Into Practice

Pick one live workflow from this article and turn it into something your team can reuse without you: a checklist line, a saved message, a property note, or a written cutoff.

You do not need a full documentation sprint. You need one sharper rule that lowers the number of clarifying messages the next time the same situation appears.

• Write the rule where your team already looks for turnover truth.
• Test it on the next real booking, turnover, or guest request.
• Tighten the wording based on where people still hesitated.