Managing a Co-Host Remotely: Permissions, Payouts and Scope

A co-host with the wrong access is either useless or dangerous. Both outcomes are set at setup, not at the first problem.

Last updated: September 29, 2026

Hiring a co-host is the easy part. The setup is where remote hosting is won or lost. Give someone too little access and they'll ring you about every small decision, which is the arrangement you were trying to escape. Give them too much and you've handed a stranger the keys to everything at once. Both failures start on the same day, and both are avoidable with three decisions made in advance: what they can see, how they're paid, and how far the job runs.

Key Takeaways

• Two failures, one cause. Too little access and too much access both come from granting by feel instead of by design.
• Grant by area, not by rank. Access should follow the work someone actually does, not how much you trust them.
• Write the payout basis down. Who pays what, to whom, and on what cycle, agreed before the first busy month.
• Scope drifts, so review it. The job a co-host holds in low season isn't the job they hold at peak.
• Your credentials stay yours. Access is something you hand out; your own login is not.

Two failures that look nothing alike

The first failure is a co-host who can't act. They can see the guest thread but not the calendar, so they can't open dates for a last-minute booking. They can see a maintenance problem but can't approve the fix, so it waits for you, in another time zone, asleep. Every small task routes back to you, which is exactly the thing you hired them to stop. A co-host with too little access is expensive in a quiet way: they're on the payroll, and you're still doing the work.

The second failure is the mirror image, and it's worse because it's silent until it isn't. Someone who can see every area at once can change prices you set, close dates you needed, or read guest details they have no reason to hold. The damage isn't malice, usually. It's a helpful person doing something reasonable in an area that should never have been open to them, and finding out only when a booking goes wrong.

The two failures pull in opposite directions, which is why "give them a bit more access just in case" feels safe and isn't. The fix for both is the same: stop granting access as a single lump, and start granting it one area at a time.

Splitting access by domain instead of by seniority

Most hosts grant access by seniority. The person they trust most gets the most, often everything, and everyone else gets less. It's intuitive, and it's the source of both failures above.

The alternative is to grant by domain: the areas of the business a person actually touches. Bookings. Money. Availability. Rates. Each is separate, and each can be opened or closed on its own. A cleaner who only turns the unit needs the calendar and the guest's arrival time, and nothing beyond that. Someone handling the guest conversation needs the bookings area, and still nothing from the money side. A co-host running the whole operation may need most of them — but "most" is arrived at area by area, not handed over as one block.

The reason this works is that access and trust rarely move together. You might trust your oldest friend completely and still not want them changing rates, because rates aren't a trust question — they're a skills question. Granting by area lets you answer the two separately, so a person can be deeply trusted and still narrowly scoped.

There's a privacy layer under all this. Guest names, phone numbers and ID details are masked by default, so a person working in one area sees what that area needs and not the guest's full record. Your own credentials stay with you, on your device, rather than becoming a shared login everyone in the chain can use. Access is something you grant per person and per area; your account is not. That's the shape of the manage roles view, where what each person can reach is set area by area rather than handed over as one key.

Payout arrangements that do not need a spreadsheet

Money is where a friendly arrangement quietly turns into friction, and it usually isn't the amount. It's the ambiguity around it.

Settle four things before the first month, one sentence each. What your co-host is paid for — a share of revenue, a flat fee, or a fee per booking. When it's paid — after each stay, monthly, or on some other cycle you both name. Who pays — you, or the owner above you, if there's a chain. And what happens in a month with no bookings, because that's the month the arrangement gets tested. None of this needs a percentage, and none of it belongs in a spreadsheet that only one of you can open.

The trap is trying to run the arrangement from the platform's side. The system shows the bookings and the figures they generate; that's the job it's built for, and moving your money or judging a fair split is not part of it. So the arrangement lives in a note you both can read, and the numbers it's calculated from live where the bookings live. When the person doing the work can see the figures their fee is based on, and the person paying sees the same view, most disagreements never get a chance to start. That's why access is worth setting area by area at localsbnb.com — whoever works on the money side sees the figures they need, while the guest's personal details stay masked for anyone who has no reason to hold them.

Rewriting the scope when the season changes

Scopes don't stay put. The arrangement that works in a quiet month is too thin for a peak one, and the one that works at peak is expensive when nothing's booked.

So treat the scope as something you rewrite, not something you set once. Pick a date — the turn of a season, the start of a school holiday, the week your own travel picks up — and go through three lines. What does the co-host need to do in the next stretch? What access does that actually require, area by area? And what should be taken away, because the busy work that justified it has ended?

Removing access is the half people skip. It feels ungenerous, so hosts leave open an area nobody's using, and it sits there as a quiet risk. Taking access back when the work ends isn't a demotion; it's the same tidiness that put it there in the first place. If the arrangement genuinely needs someone watching something year-round, that's a real reason to leave an area open. "They might need it" isn't.

Write the review date next to the scope, so it happens on schedule rather than when something goes wrong. A scope is only worth as much as the review behind it.

FAQ

Should my co-host use my login or their own?

Their own, with access granted by the area they work in. Sharing your login puts you straight into the second failure mode above: the co-host can reach everything, you can't tell who did what, and revoking access means changing your own password.

How should I pay a co-host remotely?

Agree the basis before the mechanism — what they're paid for and on what cycle — and keep the note where you'll both find it. The platform shows the bookings and the figures the arrangement draws on; moving the money stays a job for the two of you.

What changes in peak season?

Usually the scope widens and the access has to follow, which should be a deliberate decision rather than a side effect. Then it narrows again afterwards, and the areas opened for peak get closed again.

The whole thing comes down to three decisions made once and reviewed often: what a person can see, how they're paid, and how far the job runs. Get those right at setup and the co-host is useful from day one instead of dangerous from day one. Set them by feel and you'll find out which failure you picked at the worst possible moment, usually a peak weekend with the phone ringing. If you'd rather grant access area by area, with guest details masked and your own credentials kept on your device, localsbnb.com is built so each person's reach is something you choose rather than something you hand over.

---

This article is general guidance for hosts, and it isn't legal, tax or employment advice. Payment arrangements, worker classification and data-handling duties are set locally and change over time; check the current requirements of your local authority and the current terms of any platform you use.