Every coworking operator I have talked to keeps some form of booking schedule. It might be a spreadsheet, a Google Calendar, a purpose-built coworking management platform, or simply a front-desk system where members check in. The schedule tells the operator what is supposed to be occupied on any given day. But it does not tell them what is actually occupied right now, and the gap between those two things is where revenue leaks quietly and persistently.
This post is about that gap, why it exists, and why we think both systems, static scheduling and real-time occupancy, need to coexist rather than one replacing the other.
What static schedules do well
A static booking schedule is a commitment surface. It captures confirmed future demand: member A has booked desk 7 from 9am to 5pm on Thursday. That record is reliable in the sense that someone has made a decision and committed to it. The schedule is also easy to reason about and plan around. Operators use it to staff the front desk, order supplies, anticipate parking demand, and plan cleaning schedules. A week's schedule tells you what the operational week should look like.
Static schedules are also the primary billing surface. The booking record is what triggers the charge. Even in a real-time occupancy world, you need the booking record to know who owes what and when. This is not going away.
Where the static schedule breaks down is in its assumption that committed bookings reflect physical reality. They often do not. No-shows are common across the coworking industry. In our early-access network, a meaningful fraction of confirmed bookings on any given day result in a member who does not arrive, or arrives late and leaves early. The desk shows as booked on the schedule. In physical reality, it is empty for hours. An operator who relies only on the schedule sees "booked" and does not act on the empty inventory.
What real-time occupancy adds
A real-time occupancy feed tells you what is physically happening in the space right now. Not what was scheduled, but what is actually occurring. Implemented well, it reveals no-shows within the first 30 minutes of a booked slot: a desk marked as booked at 9am that shows no physical presence by 9:20am is probably a no-show. That information is actionable: you can open the slot for same-day booking, potentially recovering revenue from that desk within the hour.
Real-time data also reveals the unofficial use patterns that the schedule does not capture. Members who book a morning slot but use the space all day. Members who share desks without registering the second person. Overflow from a meeting room into the open floor. These patterns matter for operational planning and for understanding your actual capacity constraints versus your scheduled capacity.
The way we built real-time occupancy into the Letswork platform is not through IoT sensors. Our approach is lighter weight: operator-confirmed check-in records, combined with booking data, give us a signal about physical occupancy that is accurate enough to be actionable for revenue management without requiring hardware investment. I wrote about this approach in the post on building workspace AI without sensors, but the short version is that booking plus check-in data gets you to about 85 to 90 percent accuracy on occupancy state, which is sufficient for most revenue management decisions.
The gap where revenue leaks
The most concrete example of the gap: imagine an operator with 10 hot desks, all showing as booked on the schedule for Tuesday morning. By 9:30am, 3 of those members have not shown up. No check-in recorded, no arrival scan at the door. The schedule says 100 percent utilization. Physical reality is 70 percent. The operator has no signal from the schedule that anything is wrong.
By 10am, those 3 empty desks could have been offered as last-minute same-day bookings. By 10:30am, the windows for most morning-bookers have closed. By noon, the revenue from those 3 desks that morning is permanently lost.
The operator did not have a visibility failure on the schedule. The schedule was accurate in reflecting the bookings. The failure was the absence of a real-time layer that could have flagged the no-shows early enough to act. That 20 to 30 minute early-detection window is where the operational value of real-time data concentrates.
Why real-time data does not replace the schedule
A reasonable question at this point: if real-time occupancy is so useful, why keep the static schedule at all? There are several reasons the schedule remains essential even in a real-time environment.
First, real-time data has a latency and confidence floor. A sensor that says a desk is empty might be wrong. Equipment placed on a desk while the person steps away briefly. A check-in system that was not triggered because the member came through a secondary entrance. An operator who acts on every real-time empty signal without context will frustrate members who have legitimately booked a desk and stepped away for five minutes. The schedule provides the confirmation layer: this desk shows empty on the real-time feed, but the schedule says it is booked until 10am. Hold for another 15 minutes before marking it as a no-show.
Second, the schedule is the billing and administrative record. Real-time data tells you what happened. The schedule tells you what was committed to and paid for. You need both to run the financial side of the operation.
Third, future planning requires the schedule. Real-time occupancy is, by definition, a present-tense signal. It does not tell you what next Thursday looks like. The schedule's forward-looking dimension drives staffing, maintenance windows, and demand forecasting. A real-time feed without a forward-looking schedule would leave operators operationally blind to anything beyond the current moment.
What the integration looks like in practice
The way we handle this in the Letswork platform is to treat the static booking calendar as the primary operational record and the real-time occupancy feed as a monitoring and alerting layer on top. The booking calendar sets expectations. The real-time feed flags deviations from those expectations. When a deviation is detected, such as a likely no-show, an unbooked physical presence, or an early departure from a full-day booking, the system surfaces an alert that the operator can act on: open the slot for same-day booking, contact the member, or simply note it for future no-show policy decisions.
Operators who have enabled this combination in our beta have found that the most valuable alerts are the no-show detections in the first 30 minutes of a booked slot. Those are the ones where there is still time to recover revenue on the same day. Later alerts such as late departures and unofficial extra occupants are useful for policy and planning but do not have the same immediate revenue recovery value.
Building this as two layers rather than trying to replace one with the other was a deliberate architectural choice. The static schedule has a long operational history and integrates with billing, staffing, and planning workflows that operators already have. Asking operators to abandon it in favor of a purely real-time approach would require rebuilding those workflows from scratch. The better path is to layer real-time monitoring over the existing schedule, add signal where there was none, and let operators act on that signal within their existing process.
One caution for operators adding real-time monitoring
We are not saying that adding a real-time feed automatically improves utilization. The feed creates information. What you do with that information determines whether revenue is recovered. Operators who add the real-time layer but have no response protocol for no-show alerts are not better off than before: they have more data and the same outcome. The value is only realized when the information triggers an action, specifically opening the slot for same-day booking fast enough for demand to find it.
For operators who want to start simply: define a no-show window (we use 25 minutes after the scheduled start time as the default) and a standing rule that any desk flagged as likely no-show during that window is immediately opened on the platform for same-day booking at a slight discount. That single rule, applied consistently, captures most of the recoverable revenue without requiring the operator to monitor the dashboard in real time themselves.
