The Data Dashboard Every STR Operator Needs

If you operate short-term rentals and you can’t answer “did each unit make money last month” in under ten seconds, you don’t have a reporting problem — you have a data-model problem. A short-term rental dashboard is supposed to collapse a messy pile of bookings, payouts, cleaning invoices, and maintenance tickets into one screen that tells you the truth. Most operators I meet have the opposite: six browser tabs, three spreadsheets, and a gut feeling. This article is how I’d fix that — not with a prettier chart, but with the data layer underneath it.

I’ve built dashboards for brands, for an institutional commercial real-estate firm, and for a family office, and I ran rental-operations automation closely enough that I once ended up on the show Staycation. The pattern is always the same: the dashboard is the easy 20%. The data plumbing is the 80% that makes the numbers trustworthy. Get that order wrong and you build something nobody believes.

The three questions a dashboard has to answer

Before you pick a tool, decide what the screen is for. A good operator dashboard answers exactly three questions, in this order:

1. Am I making money? Portfolio and per-unit profitability, this month versus last.
2. Is each unit healthy? RevPAR, occupancy, and pacing for the next 30–90 days.
3. What needs me today? Today’s arrivals, turnover status, open maintenance, and slow guest responses.

Everything else is a footnote. If a metric doesn’t change a decision you’d make, it doesn’t belong on the front screen. I’d rather have eight numbers people act on than fifty that decorate a wall.

The metric set that actually matters

Here’s the core set I’d put on screen, split between the money layer and the operational layer. These are the levers; everything else is diagnostic.

Metric	What it tells you	Refresh	Why it’s on the screen
RevPAR	Revenue per available night	Nightly	The single most honest unit-health number
ADR	Average price of sold nights	Nightly	Separates pricing from occupancy
Occupancy %	Share of nights booked	Nightly	The other half of RevPAR
NOI per unit	Revenue minus real costs	Monthly	Whether the unit is a business or a hobby
Pacing (next 30/60/90)	Booked vs. prior year	Daily	Early warning before revenue drops
Turnover SLA	Cleans done on time	Real time	Protects reviews and next check-in
Avg response time	Speed to guest messages	Real time	Directly tied to ranking and conversion
Open maintenance	Unresolved tickets	Real time	The silent review-killer

Notice the split. RevPAR, ADR, occupancy, and NOI are your money metrics — they tell you whether the model works. The bottom four are operational signals — they tell you whether today is on fire. A dashboard that only shows revenue is a rear-view mirror. One that only shows operations is a to-do list. You need both panes.

I deliberately keep tax, depreciation, and ROI projections off the live dashboard. Those are decisions for a licensed CPA, not a real-time chart, and dressing them up as live metrics gives operators false confidence. Confirm anything money-, tax-, or regulation-related with the appropriate licensed professional.

The data model is the real product

Here’s the part nobody wants to hear: the chart is trivial, the data model is the product. Every reliable dashboard I’ve built sits on one idea — a clean, granular fact table that you can slice any way you want without re-deriving it.

For STR, the grain I reach for is one row per unit, per night. Each row carries:

• The date and unit ID
• Whether it was available, booked, or blocked
• The channel it booked on
• Gross booking revenue allocated to that night
• Channel fees and payment processing allocated to that night
• A foreign key out to expenses and operational events

Why per-night? Because almost every metric you care about is just an aggregation of that table. RevPAR is revenue summed over nights available. Occupancy is booked nights over available nights. Channel mix is a group-by. When the grain is right, you stop arguing about numbers — there’s one source of truth and everything rolls up from it.

Around that fact table you hang a few dimension tables: a units table, an expenses table (cleaning, maintenance, supplies, with the same unit and date keys), and an operational-events table (check-ins, turnovers, tickets). The dashboard is then just queries against this little star schema. This is the same architecture I describe in Architecting Your Real-Estate Data Layer — the domain changes, the discipline doesn’t.

The expense join is where most operators fall down. Bookings are easy because the platforms hand them to you. Expenses live in invoices, texts, and someone’s memory. If you want NOI per unit to be real, you have to capture cleaning and maintenance costs against the same unit-and-date keys — which is exactly why I treat maintenance and vendor coordination as a data problem, not just an ops problem.

Build vs. buy: don’t over-engineer your first ten units

You almost certainly do not need a custom application to start. Here’s how I’d decide.

Stage	Best fit	What it gets you	When to move on
1–5 units	PMS reports + a Google Sheet or Airtable	Revenue, occupancy, basic pacing	When expenses won’t fit cleanly
5–15 units	Self-serve BI (Metabase, Looker Studio) on a small database	Real per-unit NOI, multi-source joins	When you need custom logic or VA-facing screens
15+ units	A purpose-built data layer + internal tool (Retool/custom)	Operator-grade product, role-based access	When the dashboard becomes a competitive edge

The honest truth: a connected spreadsheet plus your PMS export will carry you further than you think. I’ve seen operators run a dozen units on Airtable with automations doing the joins. The case for building only appears when off-the-shelf reporting can’t combine your sources or can’t compute the profitability number you actually run the business on. Don’t build a warehouse to track three cabins. There’s a deeper treatment of this tradeoff in Build vs. Buy: Custom SaaS for Real Estate.

Wiring the live operational layer

The money metrics can refresh nightly from an export — cheap and simple. The operational signals need to be near real time, and that’s where a little engineering pays off.

The pattern I use is webhooks first, polling as a fallback. Your PMS or channel manager fires a webhook on events you care about — new booking, cancellation, check-in, message received. A small serverless function catches that event, writes it to your operational-events table, and the dashboard reads from there. For sources that don’t offer webhooks, a scheduled poll every few minutes fills the gap. This glue layer — webhooks, a queue, a couple of functions — is the unglamorous backbone of every real-time operator screen, and I go deep on it in Integrating Your Tools: APIs, Webhooks & the Glue Layer.

The discipline that keeps this from becoming a maintenance nightmare: every event lands in your own database first, then the dashboard reads your database — never the third-party API directly. That one rule gives you a stable schema, a history you control, and a dashboard that doesn’t break every time a vendor changes their API.

What to look at, and when

A dashboard nobody opens is decoration. I tie each metric to a cadence and an owner:

• Daily, before coffee: today’s arrivals, turnover SLA, open maintenance, slow responses. Your operations person owns this.
• Weekly: pacing for the next 30–90 days, channel mix, any unit whose RevPAR is sliding. This feeds your pricing and revenue management decisions.
• Monthly: NOI per unit, expense creep, the bottom-quartile units. This is the owner’s review, and it’s where you decide what to fix, refurbish, or release.

The cadence is the point. The same number means different things daily versus monthly, and forcing everything to the same refresh rate is how you end up with an expensive dashboard that still doesn’t change behavior.

One compliance note worth repeating: short-term-rental rules vary by city and county, and some jurisdictions cap nights or require permits that directly affect occupancy targets. Track your permitted-night usage as an operational metric, but verify the actual rules with your local authority — the dashboard reports reality, it doesn’t grant permission.

How I’d build this with you

If I were building your dashboard, we’d start where it actually matters: the data model, not the charts. We’d define the per-unit-per-night fact table, wire your PMS and expense sources into it, and only then put a screen on top — Metabase or a light internal tool, sized to where your portfolio is today, not where you wish it were. The first version would be live in a couple of weeks and trustworthy, which beats a beautiful dashboard nobody believes. If that’s the kind of system you want, that’s exactly what a systems consult is for.

To be clear about lanes: OceanFL Systems builds the technology, automation, and dashboards. We are not a brokerage and we don’t give licensed real-estate, tax, or legal advice — for those, work with the appropriate licensed professional. We just make sure the numbers you’re deciding on are clean.