Why "Is There a Guest in the Unit?" Should Change How You Triage Every Repair

Two identical maintenance tickets come in on the same afternoon: "AC is blowing warm air." Same unit type, same trade, same likely cost. One of them is an emergency and one is a Tuesday job.

The difference isn't in the ticket. It's that one unit has a guest in it right now who paid for a summer weekend, and the other is empty until the 14th.

Why most systems can't tell the difference

This sounds obvious, and it is. The reason it doesn't happen in practice is structural: the software that reads the maintenance request and the software that knows the booking calendar are usually two different products from two different vendors.

• Maintenance tools (built for long-term rentals) have a rich concept of trades, vendors, and work orders, and no concept of a booking calendar at all.
• Short-term rental platforms know exactly who is checking in and when, and treat maintenance as a note field.

So the operator becomes the integration. You read the ticket, you mentally cross-reference the calendar, and you decide the urgency yourself. That works until you're doing it forty times a week, or until it's 10pm and the person doing the cross-referencing is tired.

What occupancy-aware triage actually changes

When the system knows both halves, three things change automatically:

• Urgency gets set correctly at intake, not after a guest complains. A fault reported with someone in the unit escalates on its own.
• The dispatch window tightens. "Sometime this week" is fine for an empty unit and unacceptable with a guest mid-stay, and the vendor should be told which situation they're walking into.
• Quiet hours stop being absolute. A rule that says "no vendor contact after 8pm" is sensible right up until there's no hot water and a guest checking out in the morning.

The turnover version of the same problem

The same blind spot shows up at checkout. A guest leaves at 10am and the next one arrives at 4pm: that's a six-hour turn, and whether it's achievable depends on facts living in two different systems. The booking calendar knows the arrival time. The maintenance system knows there's an open repair on that unit. Only something holding both can tell you the turn is going to fail before it does.

That's the pre-arrival check worth building: a guest arriving within two days, an open repair or an unfinished cleaning turn, and an alert while there's still time to do something about it. Not a report you read afterward explaining why the review was bad. We go deeper on this in the same-day turnaround playbook.

What this means if you run both kinds of rental

If your portfolio is all long-term, none of this applies and you can ignore it: leases don't have check-in times. If it's all short-term, a dedicated STR platform covers the calendar side well and you'll be patching the maintenance half.

The operators who feel this most are the ones running both, which is an increasingly ordinary portfolio: two houses on annual leases and three cabins on Airbnb. That group is genuinely underserved, because the market split its products along a line that real portfolios stopped respecting years ago. It's the same gap that shows up when you try to run a micro-resort with shared amenities on software built for single units.

Once urgency is set correctly, the next question is who to send. Ranking vendors by what they've actually done rather than who comes to mind first is its own problem, covered in picking a vendor by data instead of by memory.

The practical test for any tool you're evaluating: ask whether it can tell you a guest is currently in the unit at the moment a repair is reported. If it can't, you're still the integration.