Be.seated: Engineering Space Management and Conflict Prevention for Hybrid Work

Forty people. Fourteen desks. One meeting room and one parking spot. That is the Lynxmind office, and it is the reason Be.seated exists.

Hybrid work turned office capacity from a fixed fact into a daily negotiation. When demand genuinely exceeds supply, informal coordination stops working, and the failure is not merely inconvenient. It is a correctness problem in a system nobody built.

The Technical Problem: Ghost Seats and the Cost of Miscoordination

Coordinating occupancy through Teams threads produces two distinct failures.

The first is booking conflict. Two employees plan around the same desk, or the same parking spot, and one of them discovers the collision on arrival. There is no arbiter, because a teams thread has no concept of an exclusive claim.

The second is more expensive and less visible: ghost seats. A desk shows as taken and stays empty all day. It blocks a colleague who needed it, and it corrupts your occupancy data at the same time. Any capacity decision built on booking records alone is inflated by exactly the reservations nobody honoured. Companies renew leases on this data.

Be.seated replaces informal intent with a deterministic booking system, and then verifies that intent against reality.

Concurrency and Transactionality

Treating desks as shared exclusive resources means the booking path has to be correct under concurrent load. Two overlapping requests for the same seat and date must not both succeed, and the window is not a matter of simultaneous clicks: two transactions overlapping by any amount at all can produce a double booking if the check and the insert are separate operations.

We delegate this to the database rather than to application logic or frontend validation. The availability check and the booking insert run together inside a single PostgreSQL transaction at Serializable isolation, the strictest level Postgres offers. If two genuinely concurrent transactions would produce a conflicting result, Postgres detects it and aborts one of them with a serialization error rather than allowing both to commit. The losing request is rejected and retried; it never becomes a second reservation.

The interface reflects the database, not the other way around. A success message appears only after the transaction has committed, so the confirmation an employee sees corresponds to a durable, exclusive claim on that seat.

Eliminating Ghost Seats: Check-in and Reclamation

A booking is a statement of intent. Occupancy is a fact. The gap between them is where ghost seats live, so the seat lifecycle has to be driven by confirmation rather than by the original reservation.

On the day of a booking, an n8n automation notifies the user and asks them to confirm presence. If confirmation does not arrive inside the defined window, the system releases the seat automatically and returns the capacity to the pool. The reclaimed desk is immediately bookable by anyone else, same day, on the spot.

This is deliberately unforgiving. An employee who arrives after their window has closed has lost the seat, and it may already belong to someone else. That is the correct trade: a system that holds desks for people who might show up is the system that produced the ghost seat problem in the first place.

The reclamation loop is also what makes section 4 possible. Check-in data is the difference between knowing what people booked and knowing what people used, and only one of those is a sound basis for a lease decision.

Privacy Governance and Occupancy Analytics

Knowing who is in the office is useful for collaboration and dangerous as a management tool. Attendance data is personal data, and a hybrid work platform that quietly becomes an attendance monitor will be rejected by employees, works councils, or both.

Be.seated therefore treats visibility as a configurable policy rather than a default. Access can be scoped so an employee sees only direct team members, satellite project teams, and their respective managers on the office map. What each role can see is a deployment decision made with the client, not a fixed product behaviour.

For Facilities and HR, the platform reports on bookings by day of week, bookings by period, seat popularity, check-in rate, no-show rate, and total volume, with booking history exportable for any date range. These come directly from the relational engine, so leadership evaluating a downsizing or a floor reconfiguration is working from verified traffic rather than from assumptions about how full the office feels.

Mapping, and What Is Shipped Versus Planned

Office layouts are driven by a layout engine built on vector files. Each graphical node in an SVG floor plan maps to a database identifier, which is what allows a new office to be modelled without touching application code.

Two capabilities are on the near-term roadmap and are not shipped today. We are labelling them as such deliberately.

E-ink seat tags. A physical tag at each desk showing booking status, the name of the person holding the seat, and an LED indicating availability, with a QR code for on-desk check-in. This closes the loop between the digital reservation and the physical space, and makes an available reclaimed desk visible to someone walking past it.

AI-assisted floor plan digitization. Converting PNG floor plans or photographs directly into manipulable SVG matrices, removing the manual mapping step when onboarding a new office.

Six Months in Production

Be.seated has run inside Lynxmind for six months, with around 40 users competing for 14 desks, one meeting room and one parking spot. The contention ratio matters: this is not a system idling in an empty building, it is arbitrating genuine daily scarcity.

The deployment is hybrid, running on a self-hosted Supabase instance alongside AWS infrastructure. As with our other products, we own the code, so where a client’s deployment lives is their decision rather than ours.

Build vs. Buy

Be.seated took four engineers two months. That is the number to weigh against buying, and it is only the build: it excludes the six months of production use that surfaced the behaviours no design document predicts, including how people respond to losing a seat they booked and forgot.

Implementation is consultative. Our team handles the physical mapping of your office into the layout engine and the Azure AD integration for single sign-on, and delivers an isolated production environment ready to operate.

What We Are Looking For

We are direct about maturity. Be.seated has six months of real use in one office, which is enough to prove the model works and not enough to claim it generalizes. We are looking for a proof of concept partner: one company willing to run it in their own space and tell us where it breaks.

The ideal partner has genuine contention, because a company with more desks than employees will not exercise anything interesting, and enough interest in the outcome to give us real feedback rather than polite feedback. Setup and mapping are on us.

If you are managing hybrid occupancy on a spreadsheet and you have run out of patience with it, we should talk.