Letting more than one trusted person manage the same home — modeled on Airbnb's Co-Host feature, adapted to Trustead's friends-of-friends trust network.
Airbnb lets a listing owner invite other people to help run a listing. The research below is drawn from Airbnb's own Help Center plus current (2025–26) operator guides.
A co-host is an additional person invited to help manage a listing — they can manage the listing, respond to inquiries, and message booked guests. The owner keeps control of the big decisions; the co-host handles execution.
Airbnb offers three tiers, set per co-host so the owner controls exactly what each person can touch:
| Airbnb tier | What it grants |
|---|---|
| Full access | Manage the listing (edit calendar, pricing, listing details); manage reservations (accept/decline requests, changes, cancellations); message guests; handle damage / Resolution Center requests; view the earnings dashboard; add / remove other co-hosts (limited-access only) and set the primary host. |
| Calendar & messaging | Message guests and view the calendar — but cannot edit the calendar, pricing, listing details, reservations, or see earnings. |
| Calendar only | View the calendar. Most restrictive — read-only. |
Universal to every tier: a co-host can receive payouts, contact Airbnb support, message other co-hosts on the same listing, and remove themselves. Only the listing owner can set up or edit a co-host's payouts, and only the owner can delete the listing.
Listings → pick the listing → Listing editor → Co-hosts → Get started → enter the person's country + phone or email → choose their permission tier → review and send. The invitee gets an invitation and accepts it to become active. Up to 10 co-hosts per listing. Notably, Airbnb lets you invite anyone by phone/email — they don't need any prior relationship to you.
By default Airbnb pays the full payout to the main host, who then pays the co-host privately (bank transfer, etc.). Airbnb also offers an optional co-host payout feature that splits the funds automatically before they hit the host's account — a fixed amount, a percentage, the cleaning fee, or a combination. There is no standard cut; the two parties agree terms themselves.
Separately, Airbnb launched a Co-Host Network in 2024 — a marketplace where owners search for and hire vetted local professional co-hosts they've never met. Co-hosts build service profiles; hosts browse and hire. Available in ~13 countries; professional co-hosts typically charge 17–20% of the host's payout. Airbnb takes no matching fee.
VRBO is simpler and cruder: you add someone as a "property manager" on your account and they get access — no marketplace, no built-in payout split, and no granular per-person permission tiers. Because native tools are thin, many professional hosts route team access through third-party software (Hostaway, Hospitable, Guesty) instead. Takeaway for Trustead: Airbnb's permission-tier model is the good part worth borrowing; the professional marketplace + payout-splitting is a separate, heavier layer we do not need early.
Trustead isn't Airbnb. It's private, invite-grown, and every booking rests on a trust path between two people. Bolting on co-hosts naively would poke holes in exactly the thing that makes Trustead different. Four questions decide the design.
Yes — a co-host must already be a connection in your trust network. Airbnb lets you add a stranger by phone number; Trustead should not. You may only hand co-host powers to someone you're already connected to (someone you've vouched for, or who is a direct connection). This keeps every person touching a listing inside the trust graph and matches the product's whole premise: you don't give a stranger the keys to your home.
This is the crux. In Trustead a guest decides to book based on their trust path and connection/vouch scores to the host. If two people run one home, whose identity is the guest trusting?
The listing always has exactly one trust anchor: the owner. The trust badge, connection score, vouch score, and degree-of-separation a guest sees are always computed to the owner — the person whose home it actually is. A co-host is an operational helper, not the trust counterparty. The co-host is disclosed for transparency ("managed with Sam") but never changes the trust math.
If co-hosting transferred trust, it becomes an exploit: a low-trust owner adds a high-trust friend as co-host purely to borrow their reputation and reach guests they'd never legitimately reach. Anchoring trust to the owner (the real party to the stay) closes that hole. Co-hosting must never be a backdoor to inflate or move trust.
Borrow Airbnb's permission model, drop its professional-marketplace baggage. Trustead's real cases aren't hired managers — they're a partner co-running the home, a family member helping, a friend who watches the place. That's a trusted helper, not a property-management business. Ship "invite someone you trust to help manage this home." Defer the paid marketplace and automated payout-splitting — that's a professional-manager economy that doesn't fit a friends-of-friends product yet.
There are really two concepts hiding in "multiple people manage one home":
Co-host (operational helper) — helps run it; owner stays the sole trust anchor. ship this
Co-owner (shared trust identity) — a genuine joint household where both people's networks should reach guests, so the trust path is the best of the two. This is powerful — a two-network household reaches far more friends-of-friends — but it complicates the trust math and reopens the laundering risk, so it needs deliberate design. deliberate later Keep it out of v1, but it's a real growth lever worth a dedicated decision.
Adopt a trimmed-down, trust-native co-host model.
The owner sits above three possible co-host tiers. The v1 tag marks what ships first; the rest are later refinement.
| Capability | Owner | Co-manager v1 | Messaging v2 | Calendar v2 |
|---|---|---|---|---|
| Is the listing's trust anchor | Yes | No | No | No |
| Edit listing details & photos | Yes | Yes | No | No |
| Set pricing | Yes | Yes | No | No |
| Edit the calendar / availability | Yes | Yes | View only | View only |
| Message guests | Yes | Yes | Yes | No |
| Accept / decline / cancel bookings | Yes | Yes | No | No |
| Write & respond to reviews | Yes | Yes | No | No |
| See booking-scoped guest info | Yes | Yes | Messages only | No |
| See owner's / guest's wider network | Yes* | No | No | No |
| Add / remove co-hosts | Yes | No | No | No |
| Set up / edit payouts | Yes | No | No | No |
| Delete listing / transfer ownership | Yes | No | No | No |
| Remove themselves as co-host | — | Yes | Yes | Yes |
*Owner sees their own network as they always have — this row means co-hosts never inherit that visibility. The three owner-exclusive rows (add/remove co-hosts, payouts, delete/transfer) are the hard line Airbnb draws too, and Trustead should keep it.
Reuse Trustead's existing invite / notification plumbing; the "must be a connection" rule leans directly on the vouch graph.
Keep vouching and co-hosting distinct. A vouch is a public trust claim; co-hosting is an operational grant. Requiring an existing connection means the two interlock without conflating them. Whether accepting a co-host invite should also prompt "want to vouch for them too?" is an open decision (§09) — recommended as an optional nudge, never automatic.
Trust stays keyed off the owner; a single join table carries co-hosts and their permissions.
listing.owner_id as the canonical trust anchor — never derive trust from listing_manager.role as an enum now; if granular per-capability control is ever needed, it can graduate to a permissions set without reshaping the table.user_id must be an existing connection of invited_by (enforced against the vouch/connection graph).manager_action_log (who did what, when) for accountability once multiple co-hosts exist.| Decision | Recommendation |
|---|---|
| 1. Can a co-host be anyone with an account, or must they be an existing vouched connection? | Existing connection only — protects the trust model. |
| 2. Should adding a co-host automatically create a vouch? | No — keep them separate; optionally prompt a vouch. |
| 3. How much guest data does a co-host see? | Booking-scoped only — never the guest's wider network. |
| 4. Should guests be told a home is co-managed, and by whom? | Yes — lightweight, always-on disclosure. |
| 5. v1 = one role, or ship granular tiers immediately? | One "Co-manager" role first; tiers in v2. |
| 6. Do we ever want true "co-owner" (shared trust identity)? | Park as a deliberate v3 growth call — not now. |