Twenty Units Later: When a Spreadsheet Stops Being Enough

A spreadsheet fails gradually, then all at once. Four signals tell you which side of that line you're on, and only one of them is about the number of units.

Last updated: October 21, 2026

Hosts usually ask when a portfolio outgrows a spreadsheet, expecting a number. The number isn't the useful part: a well-built sheet handles twenty units and struggles at eight, depending on channels, turns and people. What changes is the kind of work. Below the line you enter data; above it you coordinate people. Four signals mark the crossing.

Key Takeaways

• Four signals, and only one is about count. The others are about who holds the calendar, how long a change takes, and whether reporting still answers questions.
• The calendar breaks before the accounts. A bookkeeping error surfaces at month end; a calendar error surfaces at the door.
• It fails silently. Nothing errors. The sheet says a unit is free, and two people act on it.
• Move channels first, roles second, reporting third. Pricing experiments and new channels wait until after peak.
• Migrate in parallel, not in one weekend. A week of both systems running costs less than one double booking in high season.

Four signals, not one number

Signal one: the calendar lives in one person's head. The sheet may be shared; the knowledge isn't. Only one person can say whether unit four is free on Friday, whether the cleaner has the key, and whether last night's booking matches the message. When that person is on a plane, the portfolio stops taking decisions.

Signal two: every change is a message plus an edit. A rate change means telling someone, who edits a cell, who updates a channel, who confirms. The change takes a minute; the round trip takes an afternoon. Once changes queue up you start batching them, and batching is how a rate ends up a week stale.

Signal three: reporting costs more than the decision it supports. The monthly close takes two days at eight units and two days at twenty, because the work is reconciliation, not arithmetic. When answering a question costs more than the answer is worth, you stop asking. That's the quiet failure: not wrong numbers, but a portfolio nobody interrogates.

Signal four: handoffs grow faster than units. Each unit adds channels, each channel adds a calendar, each turn adds a cleaner, a check and a message. Ten units on four channels isn't ten times the coordination of one unit; it's closer to ten times the edges. This is the only signal about count, and it arrives last.

Read them together. A host with six units who fails signal one has a bigger problem than a host with twenty who passes all four. The trigger is coordination, not arithmetic.

The first thing that breaks

The calendar. Specifically, the changeover edge: a day with a departure and an arrival, where the sheet says both are fine and the channel says one of them isn't.

Three failures live on that edge. A double booking, where two channels sell the same night because one update didn't land. A rate left behind on one channel, so the unit is quoted at two prices on the same day. A cleaner at the wrong unit, because the turn was logged against the booking.

What makes it dangerous is the silence. A bookkeeping mistake produces an odd number at month end, and someone catches it. A calendar mistake produces a guest outside a door, and no system reports an error. You find out from the person most inconvenienced.

It also has a season. The edge is busiest when you have the least attention to spare, which is why portfolios fail in August rather than February. Off-season a stale cell is a nuisance; in peak it's a refund and a lost repeat guest in the same hour.

This is why the accounts are the wrong place to start. Finance feels like the grown-up system and is usually the last thing that needs moving. The calendar is first, because it's the only place where an error reaches a guest before it reaches you.

What to move before the peak

Order matters more than timing. Move the thing that fails in public first.

First, the channel calendar. One view showing what each channel has sold, at what rate and in what state. That's the fix for the changeover edge, and the only migration that pays back in the first week. LOCALSBNB connects Airbnb, Booking.com, Agoda and Trip.com in one calendar and shows each channel's source rate and status beside the dates, so a night sold on one channel and open on another is visible rather than inferred. That single view is the whole point of the first move, and it's what localsbnb.com is built around.

Second, roles and access. Once more than one person touches the calendar, the question stops being what the software can do and becomes who may do it. Access granted by domain, per person, means a cleaner sees turns, a co-host sees messages, and neither sees the settings — so adding a person doesn't mean handing over the account.

Third, reporting. Occupancy, ADR and RevPAR per unit become useful once the calendar is trustworthy, because they're derived from it. Move it first and you'll spend a month reconciling two versions of one number.

What not to move before peak: pricing experiments, a new channel, a new cleaning partner, a new property. Each adds a variable to a system you're already changing.

Timing: start in the shoulder, aim to be settled six to eight weeks before peak, and freeze changes in the last two. A migration that ends the day before high season is one you'll debug during it.

A migration that doesn't stop letting

The rule is that no night goes unsold because of the move. That rules out a weekend cutover.

Run both systems for a week. The old sheet stays authoritative for reading, the new calendar for selling. Each morning, compare the next fourteen days: arrivals, departures, rates, blocks. The differences are your worklist, and a week is enough to find the pattern.

Move one channel at a time, and one building at a time within each channel. A cutover per block of units is a small failure if it goes wrong; a cutover across the portfolio is a season.

Make the old sheet read-only on cutover day, not deleted: people go back to what they trust, and a read-only copy answers questions without letting anyone edit.

Check the first three turns by hand: walk the unit on the first changeover, confirm the cleaner's view matches the calendar, and confirm the arrival message came from the new system.

Name one owner for the first two weeks, with authority to stop the migration, and write the rollback rule before you start.

Then count the near-misses on the changeover edge in the first month, not the features you gained. If they fall and nobody asks who holds the calendar, the move worked.

FAQ

Is there a unit count where a spreadsheet stops working?

No single number. Six units on four channels with three people can be past the line; twenty on one channel with one person can still be fine. The signals matter more than the count.

What breaks first?

The calendar, on a day that has both a departure and an arrival. That's where a missed update becomes a double booking, and it's the failure a guest experiences directly.

Can the migration wait until after peak?

It can, and often should. What shouldn't wait is the channel calendar, the part that fails in public. Roles and reporting can follow in the shoulder.

A spreadsheet isn't a stage you graduate from; it's a tool with a shape, and the shape is one person's attention. When the portfolio needs more attention than that, the sheet is being asked to do something it was never built for. localsbnb.com is where the channels, the calendar and the access sit in one place, so the question stops being who knows and becomes what's booked.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Channel connections, access models and reporting needs differ by market and by portfolio. Confirm the current terms of each platform you use and check what your own operation actually requires before you migrate.