Designing Property Readiness as a System
Building a day-by-day operational scheduler for high-stakes turnover environments in the short term rental industry.
Designing Property Readiness as a System
Building a day-by-day operational scheduler for high-stakes turnover environments in the short term rental industry.
01 — The Moment That Matters
In short-term rental operations, everything converges on a single moment: guest arrival.
Before that moment, there are dozens of moving parts — cleaning, maintenance, inspection, coordination across teams. But to the guest, none of that complexity exists. There is only one outcome: ready or not.
When I began redesigning our task management system, I thought I was improving workflows. What I eventually realized was that managers weren't struggling to create tasks. They were trying to answer a more urgent question:
“Will this property be ready today?”
That question reshaped the product.
02 — The Core Problem
Before this system, operational information was fragmented:
- Reservation data lived in one place
- Cleaning, maintenance, and inspection tasks lived in another
- Managers manually cross-referenced views to infer readiness
Nothing was technically missing. But readiness itself was never explicitly defined. It was just guessed.
Under same-day turnover pressure, inference creates anxiety. Managers double-checked Slack threads. They called cleaners. They scanned multiple screens before feeling confident enough to move on. Chaos! Chaos! Chaos!
The system held the data, but it did not communicate certainty. We needed a clear, traffic-light system that would make it obvious when a property was ready or not.
03 — Reframing the Product
Instead of refining task lists, I reframed the product around a new organizing principle:
The goal was not to show more information.
It was to make operational state visible.
I began designing a day-by-day scheduler that would answer:
- Which properties are at risk today?
- What is blocking readiness?
- Which department owns the issue?
- What needs to be prioritized immediately?
The scheduler wouldn't just display tasks.
It would model operational reality across all departments, reservations, and reality.
04 — Designing the Status Architecture
To make readiness explicit, I designed a structured state system across four operational layers.
Primary Property Status
Component Statuses
Cleaning
Maintenance
Inspection
Each status updated dynamically through task completion and reservation triggers. Status wasn't decorative — it was computed.
05 — Property Readiness Logic
A property could only achieve Ready if all components passed. Click each condition to see what happens when it fails.
Cleaning
Maintenance
Inspection
Reservation
Property Status
ReadyToggle statuses to see how readiness is computed
This made readiness binary and enforceable.
06 — Integrating Reservations Into Operations
The most important structural shift was connecting reservation events to operational state. Click a trigger to see the changes in status.
Property
ReadyCleaning
CleanInspection
InspectedClick a trigger to see the state cascade
Managers no longer had to remember to update statuses manually. The system anticipated turnover instead of reacting to it.
Millions of changes happen in the background. We are accounting for the details that may go unnoticed.
07 — Designing the Scheduler
The scheduler became the manager's command center.
Instead of scanning task lists, managers scanned property readiness by date.
The interface surfaced:
- Same-day turnovers
- Blocking maintenance issues
- Failed inspections
- Dirty units awaiting cleaning
- Occupied properties
Instead of reading lists, managers assessed risk.
08 — Prioritization as a Visual System
Not all "Not Ready" states carry the same urgency.
Prioritization logic was based on:
- Reservation arrival times
- Same-day turnover flags
- Blocking maintenance tasks
- Failed inspections
Visual hierarchy signaled urgency without overwhelming the screen: high-risk properties surfaced first, blocking issues were visually distinct, and task/department ownership was clearly labeled.
QuoteWhat must be resolved first to protect today's arrivals?
Managers moved from reactive scrambling to proactive coordination.
09 — Maintenance Blocking Logic
Maintenance introduced nuance.
Some issues — a broken AC — prevent occupancy. Others — a chipped cabinet — do not.
To preserve nuance without sacrificing clarity:
- Task-level blocking flags
- Department-level blocking thresholds
- Dynamic recalculation of Maintenance Status
If any blocking task existed: Maintenance = Blocked, Property cannot be Ready.
If only non-blocking tasks existed: Maintenance = Attention Needed.
Operational realism was preserved without diluting the readiness signal.
10 — Accuracy as a Design Principle
Managers make real-time decisions based on this system. Accuracy could not rely on manual discipline.
We implemented:
Status updates on task completion
Reservation events drive status changes
Controlled corrections when needed
Contradictory states prevented structurally
Reliability was enforced structurally. Users could understand status from day one.
11 — Impact
Properties tracked in real time
Reservations handled
Active users from beta
- Improved same-day turnover reliability
- Reduced guest-impacting failures
- Thousands of properties tracked through real-time operational states
- Task management grew from beta → ~1,000 active users
The most meaningful change showed in up how teams worked day to day.
Managers stopped cross-referencing channels and spreadsheets to confirm what was happening at the property. The scheduler became the place they looked first. Cleaners and staff could update each other of the status through SuiteOp.
12 — Reflection
This project reshaped how I think about product design. Early on, I thought reliability was mostly a technical problem. But the real issues was structural. Tasks existed in a vacuum away form the thing they were meant to represent: the actual state of the property.
By modeling property readiness as a system — not a checklist — we translated fragmented workflows into something legible and dependable.
Designing reliability meant:
- Structuring operational reality
- Linking events across domains
- Making risk visible
- Enforcing consistency without rigidity
This idea mattered to me personally. Before working in tech, I worked in hospitality as both a cleaner and a waitress. In that industry especially, experience is everything — small operational breakdowns are immediately felt by guests and staff alike. I remember how quickly teams stop trusting a system when the information is wrong or outdated. When that happens, people fall back to texts, whiteboards, and verbal handoffs.
Seeing teams rely on the scheduler-and update each other through the system instead of around it- felt like closing that loop.
Property readiness began as a feature. It became the organizing principle of the product.
Next Case Study
Designing for Work That Happens Elsewhere
View Project →