What a spreadsheet can and can't tell you about your holiday let's performance

The common mistake with a holiday let spreadsheet is judging performance on bookings and revenue alone. Those totals can rise while something important slips, such as fewer enquiries turning into bookings, or a lower nightly rate hidden by a couple of long stays. The sections below cover what a typical bookings log misses, how to separate occupancy from rate, the three extra numbers worth tracking, and when doing it by hand stops being worth your time.

What most spreadsheets record

Almost every self-managing host ends up with some version of the same spreadsheet. A row per booking. Columns for check-in date, check-out date, nightly rate, total revenue, guest name, maybe the channel it came through.

It's a ledger. It tells you what happened. Booking by booking, month by month, it's a perfectly accurate record of outcomes.

The problem is that a ledger of outcomes and a tool for understanding performance are two different things, and most hosts only ever build the first one. You can total the revenue column and compare it to last year all day long, and you still won't know why the number moved.

Revenue can go up because more people wanted to stay with you. It can also go up because you raised your rates and fewer people wanted to stay, but the ones who did paid more. Both show up as "revenue increased". They mean opposite things about the health of your listing.

A spreadsheet built only from confirmed bookings has already thrown away the information you'd need to tell those two stories apart.

Why more bookings this year doesn't mean you're winning

Say your bookings this year are up 15% on last year. Good news, on the surface.

Now ask: did the total number of nights available change? Did you add a bank holiday weekend that fell differently this year? Did a nearby event, a wedding venue calendar, a festival, or a change in a competitor's pricing shift demand your way without you doing anything?

None of that shows up as a separate line in a standard bookings log. It's all folded into "more bookings", which reads as a win regardless of the cause.

This matters because the actions you'd take are completely different depending on the cause. If demand grew because of something structural in your area, you might have room to raise your rates and keep the bookings. If the growth was just a calendar quirk, doing the same thing next year assuming it will repeat is how you end up disappointed twelve months from now.

A spreadsheet that only records what was booked can't distinguish "the market changed" from "I did something right" from "this year had one more weekend in it." You have to build that distinction in yourself, deliberately, because the data won't hand it to you.

Enquiries that never became bookings

Here's the bigger blind spot, and it's the one that quietly costs the most money.

Your bookings spreadsheet, by definition, only contains bookings. It has no row for the guest who messaged you, asked a question, and never replied again. It has no row for the person who looked at your calendar, saw your price, and booked somewhere else. It has no row for the enquiry that arrived at 11pm and got a reply the next afternoon, by which point the guest had already booked elsewhere. The pattern can differ by booking platform, which is another reason to record where each enquiry came from.

Those are the numbers that would tell you where you're losing business, but few hosts track them, because they don't naturally end up anywhere. A completed booking creates its own paper trail. A lost enquiry evaporates.

This is the single biggest reason a spreadsheet full of "wins" can coexist with a nagging feeling that things aren't quite right. You're only ever looking at the successes. You have no visibility into the failures, so you can't diagnose them, and you can't fix what you can't see.

If you want to understand your performance properly, you need a record of enquiries as well as bookings, even a rough one. It doesn't need to be sophisticated. It needs to exist.

Occupancy and rate are separate problems

Once you accept that revenue alone hides more than it reveals, the next distinction matters just as much: occupancy and rate are not the same lever, even though they multiply together to produce the same number.

Low revenue with high occupancy and a low rate is a pricing problem. You're full, which means demand exists, but you're not capturing enough of it per booking. The fix is usually to test higher rates carefully and watch what happens to occupancy. To see what a new rate leaves you on each stay length once fees and changeover costs are paid, run it through the holiday let short stay calculator.

Low revenue with low occupancy and a reasonable rate is a demand problem, or a visibility problem, or a conversion problem. Raising the rate here would make things worse, not better, because the issue isn't that people are willing to pay more, it's that not enough people are finding or choosing your listing in the first place.

The trouble is that a basic spreadsheet reports the combined result, total revenue, and lets you infer the split only if you go and calculate it yourself. Most hosts don't, because there's no column prompting them to. They see revenue is down, and the instinctive reaction is often to drop the rate to "get more bookings", which is exactly the wrong move if the real issue was never the rate at all.

You cannot fix a problem correctly if your data collapses two different problems into one number. Separating occupancy and average rate into their own tracked figures, month by month, is the first real upgrade you can make to any bookings log.

The three numbers a bookings log is missing

Pull these three things out from wherever they're currently buried, or start capturing them if you aren't already:

Enquiry count. Every message that asks about availability or pricing, whether it turns into a booking or not. This doesn't need a new system. A tally on a notepad, updated daily, is enough to start. Airbnb and Booking.com also expose listing-view or conversion information in their host dashboards, so compare those platform figures with your own sheet.

Conversion rate. Bookings divided by enquiries, for a given period. Count instant bookings as enquiries too, so the rate compares like with like. This tells you whether a slow month is a "not enough people are asking" problem or a "people are asking and then walking away" problem, which need completely different responses.

Lead time. The gap between the booking date and the date the guest arrives. A sudden shortening of lead time across a season usually signals a shift in how people are deciding to travel near you, and it tells you how far in advance you can realistically expect certainty about a given month.

None of these require new software. They require you to decide to record them, and to do it consistently enough that the numbers mean something after a few months.

Building a sheet that explains your results

A useful way to read the results is this: a results sheet tells you the score. A diagnostic sheet tells you why the score is what it is. You need both, but most hosts only ever build the first one, then wonder why staring at it harder doesn't produce answers.

The shift is simple to describe and slightly tedious to build. Instead of one tab with a row per booking, you build a second tab, or a second section, that captures the funnel above the booking: how many people looked, how many enquired, how many booked, and how far ahead they did it.

You don't need this level of detail forever, and you don't need it retroactively for years of history you don't have. Start from today. The moment you have three or four months of paired data, real patterns start to show themselves in a way that a bookings-only log never surfaces.

Upgrading your existing sheet in a week

This is the part you can do, starting this week.

Day one, open whatever booking log you already have. Add three new columns to the far right: "enquiry date", "lead time (days)", and "source" (which channel or platform the enquiry came from, if you know it).

Day two, backfill lead time for the last three months of confirmed bookings if you can find the original enquiry dates in your messages. Don't spend more than an hour on this. Approximate is fine.

Day three, start a second sheet, or a second tab in the same file, titled "enquiries". One row per enquiry from this point forward, whether or not it converts. Columns: date, source, dates requested, outcome (booked, declined, went quiet), and if it didn't convert, your best guess at why (price, availability, dates, no reply received, chose elsewhere).

Day four, go back through your messages for the last month and log anything you can reconstruct. You won't get everything, and that's fine. Even a partial month gives you a baseline conversion rate to compare against going forward.

Day five, calculate three numbers from what you have: your conversion rate for the period, your average lead time, and your revenue split by occupancy times average rate, or revenue per available night, rather than as one lump figure.

Day six and seven, just watch. Don't change your pricing or your listing yet. The value of this week is that from now on, every month adds real diagnostic data instead of just another outcome row. Give it three months before you draw conclusions.

The limits of a spreadsheet

None of this makes a spreadsheet infinite. It has real limits, and it's better to admit them than to pretend more columns fix everything.

A spreadsheet can't tell you why an enquiry went quiet unless you write the reason down yourself, in the moment, which takes discipline most people don't maintain past the first few weeks.

A spreadsheet can't automatically adjust for external events, seasonality shifts, or competitor pricing changes. You can track that something happened, but connecting cause and effect is still a judgement call you're making, not something the sheet calculates for you.

A spreadsheet can't reconcile itself with your bank account, your cleaning costs, or your compliance paperwork unless you build and maintain those links by hand, and they tend to drift out of sync the moment life gets busy. A simple bookkeeping system for holiday lets helps with the money side. A channel manager can remove some calendar duplication, but it can't explain the reasons behind the numbers; what a channel manager keeps in sync covers where it helps.

And a spreadsheet has no memory of your intentions. If you changed your rate on a specific date to test something, and you don't log that change with a date and a reason, you'll be looking at the revenue effect a month later with no way to attribute it to the decision that caused it.

When it's time to let something else do the counting

There's a point where doing this by hand stops being the right use of your time, and it's worth naming that point rather than guessing at it. That is when choosing software at the right stage becomes worth considering.

If you're spending more time maintaining the tracking than you gain in insight from it, that's a signal. If you're managing enough enquiry volume that manual logging is falling behind, if entries are getting missed because life got busy, that's a signal too. If you find yourself wanting to slice the data by more dimensions than a couple of tabs can comfortably hold, syncing with a calendar system, splitting by property, cross-referencing changeover schedules, that's usually the point where dedicated software earns its cost, because the manual version has started producing worse data than no tracking at all.

The right test isn't a feature list. It's whether the manual version is still accurate enough to trust. Once you're skipping entries or estimating instead of recording, you've already lost the thing a spreadsheet was supposed to give you: a record you can rely on. That's the moment to look at something purpose-built, not before.

Reading your numbers

Take a month where bookings and revenue are both up on last year, yet the calendar has gaps you didn't expect. With occupancy and rate split apart, enquiries counted alongside bookings and lead time on the record, that kind of gap usually becomes explainable. Maybe fewer enquiries turned into bookings because a slower reply time let guests book elsewhere; automating routine replies can help you respond faster, and the log will show whether it makes a difference. Maybe the revenue increase came from two long bookings in a quiet period, masking fewer short stays.

A bookings log records outcomes: what was booked and what was paid. It can't show the enquiries that never became bookings, or why. Add the three numbers above this week, and next month's figures will start explaining themselves.