Partner Onboarding Workbook

Handing over any part of your listing management to a partner is not a single conversation. It is a sequence of decisions, credential transfers, and agreed boundaries that either get documented before work starts or become the source of every friction that follows. Most onboarding problems do not come from disagreement about strategy. They come from ambiguity about who can do what, which systems the partner can reach, and what a good outcome looks like at the end of the first month.

This workbook treats the first thirty days as a project with a defined scope, not a warm-up period. Each section gives you something to complete, not just something to read. Work through it in order, assign every item to a named person, and by Day 30 you will have a documented operating baseline that both you and your partner can refer to when questions arise.

Before Day 1: Name the People and Systems

Nothing in onboarding moves faster than the slowest credential. Before any access is granted or any rate strategy is discussed, you need a complete map of who owns what and who can approve what. This is not administrative housekeeping. It is the dependency chain for every task in the thirty days that follow.

People to name before the first handoff

Write down a single named individual for each of the following roles. A role with no name attached is a role that will cause a delay.

On your side:

• Primary owner contact (the person who can approve access requests and sign off on strategy changes)
• Billing contact (may be the same person, but confirm it explicitly)
• Property manager on the ground, if one exists (the person who handles turnovers, maintenance calls, and guest issues at the property level)
• Anyone else who currently has login access to your Airbnb account or channel manager

On the partner side:

• Onboarding lead (the person responsible for completing this workbook with you)
• Rate strategist assigned to your account
• Support contact for day-to-day questions after onboarding closes

Systems to inventory before Day 1

List every platform that touches your listing's pricing, availability, or guest communication. For each one, record the platform name, the login email associated with it, and who currently holds the credentials. Do not share passwords in this document. The point is to know what exists before you start granting access.

Common systems to check:

• Airbnb host account
• Channel manager, if you use one (record which one and whether it pushes to Airbnb via API or iCal)
• Direct booking website, if one exists
• Smart lock or keypad management platform
• Cleaning or turnover scheduling tool
• Any spreadsheet or manual calendar you currently use to track availability

If a system is not on this list and it affects availability or pricing, add it now. Discovering a forgotten iCal sync on Day 14 that is overwriting rate changes is a recoverable problem. Discovering it on Day 45 is not.

Access Inventory: What to Grant, to Whom, and When

Access should be granted in the minimum scope needed for the work, confirmed in writing, and logged with a date. This section gives you a checklist for each platform category.

Airbnb account access

Airbnb offers co-host permissions that allow a partner to manage pricing, availability, and messaging without holding your primary login. Review the current permission tiers available in your Airbnb account settings before granting anything. The specific permissions Airbnb makes available change over time, so check the current state in your account rather than relying on any description written before your onboarding date.

Checklist for Airbnb access:

• Confirm which co-host permission level your partner needs for rate management
• Send the co-host invitation from your account to the partner's designated Airbnb profile
• Confirm the partner has accepted the invitation and can see your listing in their account
• Record the date access was granted and the permission level applied
• Remove any former co-hosts or managers who no longer need access

Channel manager access

If you use a channel manager, access procedures vary by platform. The general principle is the same: grant the minimum role that allows the partner to push rate and availability changes, and confirm that the connection to Airbnb is live and syncing correctly after access is set up.

Checklist for channel manager access:

• Identify the user role in your channel manager that covers rate and availability management
• Create a user account for the partner under that role (do not share your own login)
• Confirm the partner can see your property and push a test change
• Verify the test change appears correctly on Airbnb within the expected sync window
• Record the date, the role granted, and the name of the partner user account

Other system access

For any other system that affects availability, record the access decision explicitly. If the partner does not need access to a system, write that down too. An explicit "no access needed" is better than a blank, because it shows the question was asked.

Decision-Rights Matrix: Who Decides What

The most common source of friction between a host and a revenue management partner is not a bad rate decision. It is a rate decision made without the host knowing it was going to happen, or a host override made without the partner knowing it happened. A decision-rights matrix removes that ambiguity by assigning every category of decision to one of three states before work begins.

The three states are:

• Partner decides and acts (no prior approval needed, partner notifies you after)
• Partner recommends, owner approves (partner proposes, owner confirms before action is taken)
• Owner decides (partner provides information, owner makes the call)

Work through the table below with your partner before Day 1. Fill in the "Assigned to" column for your specific situation. If you leave a row blank, you are choosing ambiguity.

Once this table is filled in, both parties sign or confirm it in writing. It is a living document. If a situation arises that is not on the list, add it and assign it before acting, not after.

The 30-Day Sequence: A Week-by-Week Plan

The thirty days are not a single sprint. They are four distinct phases, each with a clear output. If a phase does not produce its output, the next phase starts on a weak foundation.

Week 1: Foundation (Days 1 to 7)

The goal of Week 1 is a complete, confirmed access setup and a shared understanding of your current listing state.

Tasks:

• Complete the people and systems inventory from the Before Day 1 section
• Grant all required access and confirm each grant with the checklist above
• Share your current pricing history with the partner (export from your channel manager or Airbnb, covering at least the previous three months)
• Share your occupancy calendar for the same period
• Walk through the decision-rights matrix together and assign every row
• Confirm the rate floor and ceiling you are comfortable with for the first thirty days
• Identify any dates in the next ninety days that are already blocked or have special circumstances (local events, owner stays, planned maintenance)
• Confirm the communication channel for day-to-day questions (email, a shared workspace, or another agreed method)

Output: A completed access log, a signed decision-rights matrix, and a confirmed rate range for the first operating period.

Week 2: First Rate Changes and Observation (Days 8 to 14)

The goal of Week 2 is to see the partner's rate strategy in action and confirm that all systems are behaving as expected.

Tasks:

• Review the first set of rate adjustments the partner has made or proposed
• Confirm that changes are appearing correctly on Airbnb (check the calendar view in your host account)
• If you use a channel manager, confirm that rates are syncing correctly to all connected platforms
• Note any bookings that come in during this period and record the nightly rate at which they booked
• Flag any rate decision that surprised you and discuss it with the partner before changing it unilaterally
• Confirm that the partner's notification process is working as agreed (are you receiving the updates you expected, at the frequency you expected?)

Output: A confirmed sync check, a log of any anomalies found, and a first conversation about whether the rate strategy matches your expectations.

Week 3: Calibration (Days 15 to 21)

The goal of Week 3 is to adjust anything that did not work as expected in Week 2 and to set up the reporting structure.

Tasks:

• Review the anomaly log from Week 2 and resolve each item
• If any decision-rights assignments caused confusion, revise the matrix now
• Set up the reporting template you will use for monthly reviews (see the Reporting Acceptance Checklist section)
• Confirm the escalation tree is documented and both parties have a copy (see the Escalation Tree section)
• Review the next sixty days of your calendar together and flag any dates that need special handling
• Confirm that the partner has everything they need to operate without needing to ask you for basic information

Output: A revised decision-rights matrix if needed, a confirmed reporting template, and a documented escalation tree.

Week 4: Closeout Preparation (Days 22 to 30)

The goal of Week 4 is to produce the Day 30 closeout deliverables and confirm that the operating baseline is solid enough to hand off to a steady-state rhythm.

Tasks:

• Compile the first monthly report using the agreed template
• Complete the reporting acceptance checklist
• Confirm that all access grants are still correct and that no unintended access exists
• Document any open questions or unresolved items and assign each one to a named person with a target date
• Schedule the first post-onboarding check-in (typically thirty days after Day 30)

Output: A completed Day 30 closeout package (see the Day 30 Closeout section).

Escalation Tree: What Happens When Something Goes Wrong

An escalation tree is not a sign that you expect problems. It is the document that prevents a small problem from becoming a large one because nobody knew who to call. Build it before you need it.

Tier 1: Routine questions and minor adjustments

These are handled directly between you and your assigned partner contact. No escalation needed. Examples include a question about why a specific night was priced a certain way, a request to block a date, or a notification about an upcoming local event.

Response expectation: Agree on this during Week 1. A common approach is a response within one business day for non-urgent items.

Tier 2: Unexpected changes or system issues

These are situations where something has happened that was not expected and needs attention within hours rather than days. Examples include a rate change that fell outside the agreed floor or ceiling, a sync failure between your channel manager and Airbnb, or a booking that came in at a rate you did not expect.

Escalation path: Contact your assigned partner contact directly using the fastest agreed channel (not just email if the issue is time-sensitive). If no response within a defined window, contact the onboarding lead.

Document the agreed response window here: _______________

Tier 3: Disputes or access emergencies

These are situations where you need to act immediately regardless of partner availability. Examples include a security concern with account access, a dispute about a decision that was made without your approval, or a situation where you need to revoke access quickly.

Action: Know how to remove co-host access from your Airbnb account without waiting for anyone. Practice this before Day 1 so you are not learning it under pressure. The steps are in your Airbnb account settings under the co-host management section.

Document the partner's escalation contact for disputes here: _______________

Escalation log

Keep a running log of any Tier 2 or Tier 3 events. Record the date, what happened, who was contacted, and how it was resolved. This log is not a complaint record. It is a calibration tool. If the same type of issue appears more than once, the decision-rights matrix or the access setup needs to be revised.

Reporting Acceptance Checklist: How to Know a Report Is Complete

A monthly report that does not answer your actual questions is not a report. It is a document. Before you receive your first report, agree on what a complete report contains. This checklist is the acceptance criteria.

A report passes acceptance when it contains all of the following:

Occupancy and availability:

• Total nights available in the period
• Total nights booked in the period
• Total nights blocked (owner use, maintenance, or other)
• Occupancy rate calculated from the above (so you can verify the arithmetic yourself)

Rate performance:

• Average nightly rate for booked nights in the period
• Lowest rate accepted in the period and the date it was applied
• Highest rate accepted in the period and the date it was applied
• Any nights where the rate floor or ceiling was reached

Booking lead time:

• Distribution of how far in advance bookings were made (for example, how many booked more than thirty days out versus fewer than seven days out, expressed as counts not percentages if you prefer to do your own calculations)

Decision log:

• A record of any decision made under "partner decides and acts" authority during the period
• A record of any decision escalated to "owner approves" and the outcome

Open items:

• Any unresolved issues carried forward from the previous period
• Any upcoming dates in the next sixty days that require owner input

Format:

• Delivered in the agreed format (spreadsheet, PDF, or shared document)
• Delivered by the agreed date each month
• Includes a brief written summary in plain language, not just raw data

If a report arrives and any item on this checklist is missing, return it with a specific note about what is absent. Do not accept an incomplete report and then work around the gaps. The gaps compound over time.

Day 30 Closeout: What Done Looks Like

Day 30 is not the end of onboarding in the sense that everything is finished. It is the point at which the operating baseline is confirmed and the relationship moves from a setup phase to a steady-state phase. The closeout is a formal check that the baseline is actually in place.

Closeout checklist

Complete every item before declaring onboarding closed.

Access:

• All required access has been granted and confirmed
• No unintended access exists (former managers, test accounts, or shared logins that should have been removed)
• The access log is complete and dated

Decision rights:

• The decision-rights matrix is signed or confirmed in writing by both parties
• Any revisions made during the thirty days are reflected in the current version
• Both parties have a copy of the current version

Reporting:

• The first monthly report has been delivered and accepted against the checklist
• The reporting schedule for subsequent months is confirmed (delivery date, format, and recipient)

Escalation:

• The escalation tree is documented and both parties have a copy
• Response windows for each tier are agreed and written down
• Both parties know how to reach each other outside normal business hours if a Tier 3 issue arises

Open items:

• Every open item from the thirty-day period is documented with a named owner and a target resolution date
• No open item is left unassigned

Post-onboarding schedule:

• The first post-onboarding check-in is scheduled (date and format confirmed)
• The cadence for ongoing check-ins after that is agreed

What to do if the closeout checklist is not complete on Day 30

If items remain incomplete on Day 30, do not declare onboarding closed. Extend the onboarding period by a defined number of days, assign each incomplete item to a named person, and set a new closeout date. A premature closeout that leaves gaps in access, decision rights, or reporting creates problems that are harder to fix once the relationship is in steady state.

References: Documents to Keep and Where to Keep Them

Every document produced during onboarding should be stored in a single location that both you and your partner can access. The format matters less than the consistency. A shared folder, a project workspace, or a simple email thread with a clear naming convention all work. What does not work is having the decision-rights matrix in one place, the access log in another, and the escalation tree only in someone's memory.

Documents to retain

• People and systems inventory (completed before Day 1, updated if anything changes)
• Access log (one row per access grant, with date, platform, role, and the name of the person who granted it)
• Decision-rights matrix (the signed or confirmed version, with any revision dates noted)
• Escalation tree (including agreed response windows and contact details for each tier)
• Monthly reports (all of them, not just the most recent one)
• Reporting acceptance checklist (the agreed version, so there is no dispute later about what was required)
• Day 30 closeout checklist (completed and dated)
• Open items log (a running record of anything unresolved, with resolution notes added when each item closes)

How long to keep them

Keep all onboarding documents for as long as the partner relationship is active, plus a reasonable period after it ends. If a dispute arises about a decision that was made in Month 2, the decision-rights matrix from onboarding is the document that resolves it. Documents you cannot find are documents that do not exist.

Version control

When a document is revised, do not delete the previous version. Add a date to the filename or the document header and keep the old version in the same folder. The history of how your operating agreement evolved is sometimes as useful as the current version.

Where this becomes someone else's job

If the work described in this guide is more than you want to manage yourself, Revande offers two products that take on different amounts of it.

Performance gives you a full software stack for dynamic pricing with daily adjustments made by experienced rate strategists, Airbnb listing performance monitoring, email alerts when visibility or booking conversion drops below expected levels, and monthly reports. You retain responsibility for the access setup, the decision-rights conversations, and acting on the alerts you receive.

Maestro includes everything in Performance and adds done-for-you listing optimization, proactive Airbnb listing performance monitoring with visibility and booking conversion issues handled for you rather than flagged to you, compatibility with Airbnb directly or with your channel manager, and ongoing listing refinements over time. The distinction is not just the scope of the work. It is who carries the operational load after the onboarding phase ends.

If you are unsure which fits your situation, work through this workbook first. The places where you find yourself wanting to hand off a task rather than complete it are usually a reliable indicator of which product level matches how you actually want to operate.