The monthly report a hostel owner should actually read

For a long time, my monthly “report” was an export I opened, scrolled through and closed. Forty columns, a total at the bottom, and a vague feeling that things were fine or not fine. I knew when revenue went up. I never knew why.

Now I read one page per property every month, in one sitting with a coffee. It's short on purpose. Every number on it has to answer one question: what do I change next month? If a number can't change a decision, it doesn't go on the page.

Here's what's on it, and what each line makes me do.

Why most hostel reports don't get read

Most software reports are built for hotels. They count rooms, so a twelve-bed dorm with three guests shows up as “occupied”. They list every metric the system can calculate, because a long list looks thorough in a demo. And they mix day-to-day detail with business results, so you can't see what matters.

More reporting depth doesn't fix this. What fixes it is the right depth in a few places: beds instead of rooms, channels with their real cost, and the cash that never shows up in booking data.

Occupancy, counted in beds

The first line is bed occupancy: bed nights sold divided by bed nights available. Not room nights. If your dorms are set up as beds in your system, as they should be (I wrote about why hotel software gets this wrong), this number is honest.

Then I split it three ways:

• Dorms vs privates. They behave like two different businesses. Privates tend to fill earlier, while dorms fill late and fast.
• Weekdays vs weekends. A strong weekend can hide four empty weeknights. If midweek is weak, that's where a weekly or long-stay rate earns its keep.
• Dorm type and size. If the eight-bed female dorm is full and the twelve-bed mixed is half empty, that's a question about layout or price. More marketing won't solve it.

What it makes me do: move rates on the weak segment only, not across the whole property.

What a bed actually earned

Average rate on its own is a flattering number. Raise prices, sell fewer beds, and your average rate goes up while the bank account goes down. So next to it I put revenue per available bed: total bed revenue divided by every bed night you could have sold, empty ones included.

Read together, the two tell the story. Average rate up and revenue per bed up: the pricing worked. Average rate up and revenue per bed down: you priced people out. Both down: look at demand, your reviews, or a channel that went quiet.

Big events show up here too. During Día de Muertos our Oaxaca beds sell for roughly ten times the low-season rate, so one week can look like the whole month's result. I report event weeks on their own line so they can't hide a weak rest of the month. More on that in how we price for big events.

Where bookings came from, and what they cost

Channel mix is the line most owners skip, and it moves profit more than any other. For each source I want three numbers: bookings, revenue and commission paid. Revenue after commission is the one that counts. A channel that brings lots of bookings at a high commission can be worth less than a smaller one where you keep almost everything.

The number I watch most closely is direct share: the part of revenue that came through our own booking engine, walk-ins and repeat guests. When it drops, something changed. Maybe the website widget broke, an OTA undercut our own price, or we stopped asking happy guests to book direct next time. I've written up the math of direct bookings separately.

Two more lines belong in this section:

• Booking window. How many days ahead people booked, per channel. If guests are booking closer to arrival than before, I hold rates longer instead of discounting early.
• Cancellations and no-shows. Per channel, as a share of bookings. A channel with a high cancellation rate fills your calendar with beds that come back at the last minute. That's worse than never selling them.

What it makes me do: change which channels get our best availability, and fix whatever is hurting direct bookings.

Cash, extras and the money that leaks

Booking data only covers beds. A hostel also sells breakfast, laundry, lockers, tours and beers at the bar, and a lot of that is still paid in cash. None of it shows up in an OTA report.

So the last block covers:

• Extras revenue per guest night. If it drops, the desk stopped offering things, or the offer got stale.
• Cash shift differences. The total over or short across all shifts. One shift a little off is normal. The same shift, or the same person, off every week needs a conversation.
• Refunds and discounts. Who gave them and why. Usually it's fine. Sometimes it's the reason margins look thin.
• Unpaid balances. Guests who checked out still owing money. This should be zero, or close to it.

This is why I want reports, cash shifts and the till in one system. When the drawer, the folio and the booking live in three places, matching them up takes a whole weekend, so nobody does it. In Travel404 the reports use the same data the desk works from, so the cash line is already filled in when I sit down to read.

The checklist

• One page per property, read at the same point every month.
• Bed occupancy in bed nights, not rooms, split by dorms and privates, and by weekdays and weekends.
• Average rate next to revenue per available bed. Never read one without the other.
• Event weeks on a separate line.
• Per channel: bookings, revenue, commission and revenue after commission.
• Direct share of revenue, plus the reason if it moved.
• Booking window and cancellation rate per channel.
• Extras revenue per guest night.
• Total cash over or short across shifts, and any pattern that repeats.
• Refunds, discounts and unpaid balances.
• One written decision per section. If a number never changes a decision, take it off the page.