When we started designing the occupancy layer for Letswork, the obvious path was IoT. Desk sensors are a solved product category: there are half a dozen mature vendors offering occupancy detection hardware with various accuracy and integration specs. You buy the sensors, install them, wire them into your data pipeline, and you have real-time occupancy. It works.
The problem is operator adoption. We are targeting small and medium coworking operators in Dubai Internet City, many of whom run 10 to 40 desks from a single location. Asking those operators to purchase, install, and maintain desk-level IoT hardware before they can join the platform is an onboarding barrier that would have kept the early network far smaller than we needed it to be. The hardware-first path is a non-starter for the market we are in.
This post is about what we built instead, why the constraint of not having sensors made us think harder about what accuracy level is actually needed for the decisions we are supporting, and what the tradeoffs look like.
The question we started with: what accuracy do you need?
The first thing we had to be honest about is that different use cases require different accuracy thresholds. A hospital using occupancy data to manage isolation room usage needs near-perfect accuracy. A coworking platform using occupancy state to decide whether to open a desk for same-day booking does not.
Specifically, the decisions our occupancy model supports are:
- Is this desk likely occupied right now? (For no-show detection)
- Is this space currently near capacity? (For search ranking and availability display)
- What is the historical occupancy pattern for this time slot? (For pricing recommendations)
None of these require knowing with certainty whether a specific person is sitting at a specific desk at this exact second. They require a probabilistic assessment of occupancy state that is accurate enough to inform a decision with a consequence measured in tens of AED, not clinical outcomes. That is a much lower accuracy bar than sensor-based systems are designed for.
What we built: the inference model
Our occupancy model runs on three data sources that every operator already has or can easily generate: booking records, check-in timestamps, and check-out records.
Booking records are the prior. If a desk has a confirmed booking for 9am to 1pm and the current time is 10am, the prior probability that the desk is occupied is high. If there is no booking and no walk-in history for this time slot, the prior is low. This is not a model. It is just reading the calendar.
Check-in records update the prior. If a member booked from 9am to 1pm and checked in at 9:12am, the occupancy probability is very high. If the booking starts at 9am and by 9:25am no check-in is recorded, the probability drops toward the no-show rate we have observed for that operator and time slot. We maintain per-operator no-show priors that update over time as we observe actual behavior.
Check-out records (when available) close the occupancy window. Not all operators have automated check-out. When they do, the occupancy window closes cleanly. When they do not, we use session duration priors derived from historical booking data for that space type and time slot.
Combining these three inputs gives us an occupancy state estimate for each desk that is accurate enough for our use cases. We have validated this against a small number of spaces where operators ran side-by-side hardware sensor data for a calibration period. The booking-plus-checkin model achieves accuracy in the 85 to 92 percent range on whether a given desk is occupied or empty, depending on the operator's check-in discipline. That is well above the threshold needed for our decisions.
The technical implementation
The model runs as a lightweight service that ingests booking and check-in events in near real-time. Each event updates the occupancy probability for the relevant desk. The state for each desk is stored as a probability rather than a binary occupied/empty flag, which lets downstream components (the search ranking layer, the no-show alert system) apply their own thresholds.
The no-show alert system, for example, fires when a booked desk's occupancy probability drops below 0.3 and holds there for more than 20 minutes past the booking start time. That threshold combination is designed to minimize false alerts for members who arrive slightly late while still catching genuine no-shows with enough time to act.
Search ranking uses a different threshold. A desk with probability above 0.7 is shown as occupied in the search results and excluded from same-day availability. A desk with probability below 0.4 and no upcoming booking for the next 90 minutes is surfaced in the available slot pool. The 0.4 to 0.7 range is flagged as uncertain, which the UI reflects with a "check with operator" note rather than a confident available/unavailable status.
Where the model is weaker and what we do about it
The model's weakest point is walk-in occupancy. An operator who accepts walk-in members who pay in person but do not create a booking record has phantom occupied desks from the model's perspective. The model sees no booking, no check-in, and no occupancy probability, even though a person is physically sitting there.
We handle this in two ways. First, we ask operators to log walk-ins as unregistered desk occupancies in the dashboard. This takes 15 seconds per walk-in and keeps the model current. Second, for operators with a high walk-in rate, we apply a walk-in adjustment factor to the baseline occupancy prior during their historically busy walk-in windows, which increases the probability estimate to account for the unlogged presence.
The accuracy degrades in proportion to how poorly operators maintain their check-in records. An operator who runs a casual front desk with inconsistent check-in logging will have model accuracy closer to 75 to 80 percent rather than 85 to 92 percent. We surface a data quality score in the operator dashboard that shows how current their check-in data is, both to nudge better habits and to help operators calibrate their trust in the model's output for their specific space.
Why this approach is better for our market, not just cheaper
I want to push back on the framing that sensor-free occupancy tracking is a compromise. For our market, it is actually a better fit for reasons beyond cost.
Sensors measure physical presence, not booking state. A sensor can tell you a desk is occupied. It cannot tell you whether the occupying person has a booking, whether they have paid, or whether they are a member at all. For the decisions we care about, booking state and check-in confirmation are more useful than raw presence detection. Our model already has the booking context. Adding sensors would give us high-confidence presence data but would require integrating it with booking context anyway to produce the decisions we need.
Sensors also create maintenance overhead. A dead sensor quietly degrades model accuracy without any visible alert. Our model's failure modes are visible: if check-ins are not being logged, the data quality score drops and the operator can see it. The failure modes of software data quality are more tractable than the failure modes of hardware reliability in a market where operators do not have technical maintenance capacity.
That said, we are not opposed to sensors in principle. For operators who scale beyond 50 to 60 desks, the ROI case for hardware starts to shift. At that density, the accuracy improvement from sensor fusion and the reduction in check-in friction for members may outweigh the hardware and maintenance costs. We have designed the data pipeline so that sensor inputs can be added alongside booking and check-in data without replacing the model, which means we can support hardware-equipped operators when they exist without requiring it for everyone.
