The phrase "matching algorithm" gets used loosely in proptech. Sometimes it just means filtering by postcode and price. What we built at Letswork is meaningfully different, and this post is my attempt to explain what is actually happening when the platform surfaces a ranked list of available desks for a member who opens the app at 8:45 on a Tuesday morning in Dubai Internet City.
What the algorithm actually receives
Before any scoring can happen, the system needs a candidate set. Candidate selection runs on hard constraints: date, time window, space type, and whether the operator has confirmed real-time availability on that slot. Any desk that fails one of those constraints does not enter the scoring phase at all. This matters because scoring is computationally more expensive than filtering, and it also means the ranking is not diluted by irrelevant options.
Once the candidate set is assembled, the algorithm receives three classes of signal. First, the explicit request: the member said they want a private pod, they need wifi rated at 100Mbps or above, and their window is 9am to 2pm. Second, the member's booking history: which types of spaces they have actually chosen over the past 90 days, how often they book at short notice versus in advance, and which spaces they have visited and not re-visited. Third, the live availability feed from each operator: how many desks are confirmed open at that time, how recently the operator updated their availability calendar, and whether the space has any in-session changes (a booking just made by another member, a maintenance flag the operator pushed).
The algorithm does not weight all three equally. The explicit request is a hard filter on the candidate set. History and live feed data determine the order within that set.
Scoring: what goes into each dimension
Each candidate space receives a score across three dimensions that are combined into a single match score.
The first dimension is location relevance. DIC is not uniform. The eastern cluster around Building 3 and Building 4 has a different pedestrian flow than the western cluster near Gate Village. A member who has consistently booked in the eastern cluster in the past is less likely to walk fifteen minutes to a space in the west, even if that space has a higher availability signal. The location score accounts for historical behavior, not just proximity to the member's stated current location.
The second dimension is amenity match. Members specify requirements: phone booths, standing desks, monitor provision, meeting room access. We score how closely the operator's listed amenities align with what the member has historically selected or filtered for. An operator who lists all amenities accurately benefits here. An operator with stale or incomplete amenity data sees their score depressed relative to what their physical space might deserve.
The third dimension is time-slot fit. This is more nuanced than it sounds. A member requests 9am to 2pm. An operator offers a desk that is available from 8am to 6pm. That is a strong fit. Another operator's desk is available from 9am to 1pm with a gap before the next booking at 3pm. That is a partial fit, and the score reflects it. Members who routinely run long often see partial-fit slots ranked lower after a few sessions, because the history suggests they will overrun.
The location weighting mistake we made early on
In the first version of the model, we over-weighted proximity. The distance penalty was steep enough that members in the eastern end of DIC almost never saw results from operators in the western end, even when those spaces had high availability and the walk was under five minutes. The result was that eastern-cluster operators absorbed more demand than their capacity warranted, while western-cluster operators sat at lower utilization even on high-demand days.
Two things revealed this. Operators in the west flagged it directly: they could see in their dashboards that search impressions for their spaces were low relative to what they expected given their listed capacity. And when we looked at the distribution of first-position results by DIC building address, the skew was obvious. We recalibrated the location weight so that it is meaningful within about 300 meters but flattens out quickly beyond that. Five minutes of walking should not meaningfully disadvantage a well-matched space.
This is worth stating directly: we are not saying location is irrelevant. A member who works in a specific DIC building all week should see nearby results ranked higher. We are saying the original model expressed location as a dominant signal when it should be a tie-breaker between otherwise similarly scored spaces.
Why the ranking matters for operators, not just members
A coworking space that appears in position one or two in relevant searches books meaningfully more often than a comparable space in position four or five, even when availability and price are similar. This is not surprising. It mirrors what e-commerce and hospitality booking platforms have known for years. What is specific to workspace matching is that the ranking is not primarily determined by paid placement or star ratings. It is determined by how well the operator's inventory fits the current demand signal.
That creates an alignment we designed deliberately. Operators who maintain accurate availability calendars, keep amenity listings current, and respond quickly to booking requests get better ranking signals than operators who leave stale data in their profiles. The platform's incentives run in the same direction as the quality behaviors we want to encourage. We are not rewarding operators who pay more. We are rewarding operators whose spaces are a genuine fit for the members searching.
What happens when availability changes mid-session
The current version of the matching layer has one meaningful limitation: the ranking is static once a session starts. If a member opens a search, sees five candidates, and takes three minutes to read through the results, any bookings made during that window by other members are not reflected in what they see until they refresh. In a high-demand slot on a Tuesday morning, this means the second or third result may already be gone by the time the member taps through.
The fix is a live availability subscription at the session level, where the candidate set updates as bookings arrive. We have the infrastructure pieces to do this. The constraint is ensuring the update latency is low enough to feel immediate rather than flickery. We expect to ship this in the next build cycle. Until then, the booking flow includes a graceful handling state when the selected desk has just been taken: the member is returned to their ranked list with a brief explanation, and the next best match is pre-highlighted.
What we are measuring to know if it is working
The clearest measure of matching quality is not booking volume. It is re-booking rate at the same space. If a member books a space, uses it, and books it again within the next 30 days, that is a strong signal that the match was right. If they never return to that space, we look at whether they reported an issue or whether the space's amenities drifted from what was listed. Match quality compounds over time: a platform with better early matches builds member histories faster, which makes future matches more accurate.
Across our early-access network, re-booking rates at specific spaces within 30 days have been a useful proxy for ranking accuracy. When we introduced the recalibrated location weight, that number improved. We track it as a product metric alongside raw booking volume because a high volume of one-time bookings can mask a poor matching experience.
