
Quarenta pessoas. Catorze secretárias. Uma sala de reuniões e um lugar de estacionamento. Este é o escritório da Lynxmind, e é a razão pela qual o Be.seated existe.
O trabalho híbrido transformou a capacidade do escritório de um facto fixo numa negociação diária. Quando a procura excede genuinamente a oferta, a coordenação informal deixa de funcionar, e a falha não é meramente inconveniente. É um problema de exatidão num sistema que ninguém construiu.
O Problema Técnico: Lugares Fantasma e o Custo da Falta de Coordenação
Coordenar a ocupação através de conversas no Teams produz duas falhas distintas.
A primeira é o conflito de reservas. Dois colaboradores planeiam utilizar a mesma secretária, ou o mesmo lugar de estacionamento, e um deles descobre a colisão à chegada. Não há um árbitro, porque uma conversa no Teams não tem o conceito de uma reivindicação exclusiva.
A segunda é mais dispendiosa e menos visível: os lugares fantasma. Uma secretária aparece como ocupada e permanece vazia durante todo o dia. Bloqueia um colega que precisava dela e, ao mesmo tempo, corrompe os dados de ocupação. Qualquer decisão sobre capacidade baseada apenas em registos de reservas é inflacionada exatamente pelas reservas que ninguém honrou. As empresas renovam contratos de arrendamento com base nestes dados.
O Be.seated substitui a intenção informal por um sistema de reservas determinístico, e depois verifica essa intenção face à realidade.
Concorrência e Transacionalidade
Tratar as secretárias como recursos exclusivos partilhados significa que o caminho de reserva tem de ser correto sob carga concorrente. Dois pedidos sobrepostos para o mesmo lugar e data não podem ser ambos bem-sucedidos, e a janela de tempo não é apenas uma questão de cliques simultâneos: duas transações sobrepostas em qualquer medida podem produzir uma dupla reserva se a verificação e a inserção forem operações separadas.
Delegamos isto à base de dados em vez de à lógica da aplicação ou validação no frontend. A verificação de disponibilidade e a inserção da reserva correm em conjunto dentro de uma única transação PostgreSQL no isolamento Serializable, o nível mais rigoroso que o Postgres oferece. Se duas transações genuinamente concorrentes produzirem um resultado conflituoso, o Postgres deteta a situação e aborta uma delas com um erro de serialização em vez de permitir que ambas sejam confirmadas. O pedido perdedor é rejeitado e repetido; nunca se torna uma segunda reserva.
A interface reflete a base de dados, e não o inverso. Uma mensagem de sucesso aparece apenas após a transação ter sido confirmada, garantindo que a confirmação que um colaborador vê corresponde a uma reivindicação duradoura e exclusiva sobre aquele lugar.

Eliminação de Lugares Fantasma: Check-in e Recuperação
Uma reserva é uma declaração de intenção. A ocupação é um facto. A lacuna entre ambos é onde vivem os lugares fantasma, pelo que o ciclo de vida do lugar tem de ser impulsionado pela confirmação em vez de pela reserva original.
No dia de uma reserva, uma automação do n8n notifica o utilizador e pede-lhe que confirme a presença. Se a confirmação não chegar dentro da janela definida, o sistema liberta o lugar automaticamente e devolve a capacidade ao fundo comum. A secretária recuperada fica imediatamente disponível para reserva por qualquer outra pessoa, no próprio dia e no momento.

Isto é deliberadamente implacável. Um colaborador que chegue depois de a sua janela ter fechado perdeu o lugar, e este pode já pertencer a outra pessoa. Essa é a troca correta: um sistema que guarda secretárias para pessoas que possam vir a aparecer é o sistema que, em primeiro lugar, produziu o problema dos lugares fantasma.
O ciclo de recuperação é também o que torna a secção 4 possível. Os dados de check-in representam a diferença entre saber o que as pessoas reservaram e saber o que as pessoas utilizaram, e apenas um destes é uma base sólida para uma decisão de arrendamento.
Governação de Privacidade e Analítica de Ocupação
Saber quem está no escritório é útil para colaboração e perigoso como ferramenta de gestão. Os dados de assiduidade são dados pessoais, e uma plataforma de trabalho híbrido que se torne discretamente num monitor de assiduidade será rejeitada pelos colaboradores, comissões de trabalhadores, ou ambos.
O Be.seated trata, portanto, a visibilidade como uma política configurável e não como uma predefinição. O acesso pode ser limitado para que um colaborador veja apenas os membros diretos da sua equipa, equipas de projetos satélite e os respetivos chefes no mapa do escritório. O que cada papel pode ver é uma decisão de implementação tomada com o cliente, e não um comportamento fixo do produto.

Para as Instalações e os RH, a plataforma gera relatórios sobre reservas por dia da semana, reservas por período, popularidade dos lugares, taxa de check-in, taxa de não comparência e volume total, com o histórico de reservas exportável para qualquer intervalo de datas. Estes dados vêm diretamente do motor relacional, permitindo que a liderança, ao avaliar uma redução de espaço ou a reconfiguração de um piso, trabalhe a partir de tráfego verificado em vez de pressuposições sobre quão cheio o escritório parece estar.

Mapeamento, e o que está Lançado face ao que está Planeado
Os layouts de escritório são impulsionados por um motor de layout construído sobre ficheiros vetoriais. Cada nó gráfico numa planta baixa SVG mapeia para um identificador da base de dados, o que permite que um novo escritório seja modelado sem tocar no código da aplicação.

Duas capacidades estão no roteiro a curto prazo e não estão lançadas atualmente. Estamos a rotulá-las como tal deliberadamente.
Etiquetas de lugares E-ink. Uma etiqueta física em cada secretária mostrando o estado da reserva, o nome da pessoa que tem o lugar e um LED a indicar a disponibilidade, com um código QR para check-in na secretária. Isto fecha o ciclo entre a reserva digital e o espaço físico, e torna uma secretária recuperada e disponível visível para quem passa por ela.

Digitalização de plantas assistida por IA. Conversão de plantas em PNG ou fotografias diretamente para matrizes manipuláveis SVG, removendo o passo de mapeamento manual aquando da integração de um novo escritório.

Seis Meses em Produção
O Be.seated funcionou dentro da Lynxmind durante seis meses, com cerca de 40 utilizadores a competir por 14 secretárias, uma sala de reuniões e um lugar de estacionamento. O rácio de disputa importa: este não é um sistema a trabalhar inativo num edifício vazio, está a arbitrar escassez diária genuína.
A implementação é híbrida, correndo numa instância auto-alojada da Supabase lado a lado com a infraestrutura AWS. Como nos nossos outros produtos, somos os proprietários do código, pelo que o local onde reside a implementação do cliente é uma decisão deles, não nossa.
Construir vs. Comprar
O Be.seated demorou dois meses a quatro engenheiros. Esse é o número a ponderar face à compra, e representa apenas a construção: exclui os seis meses de uso em produção que revelaram os comportamentos que nenhum documento de design prevê, incluindo a forma como as pessoas respondem à perda de um lugar que reservaram e esqueceram.
A implementação é consultiva. A nossa equipa encarrega-se do mapeamento físico do seu escritório no motor de layout e da integração com o Azure AD para autenticação única (single sign-on), e entrega um ambiente de produção isolado pronto a operar.
O Que Procuramos
Somos diretos sobre a maturidade. O Be.seated tem seis meses de uso real num escritório, o que é suficiente para provar que o modelo funciona, mas não o suficiente para afirmar que generaliza. Estamos à procura de um parceiro para prova de conceito: uma empresa disposta a corrê-lo no seu próprio espaço e dizer-nos onde falha.
O parceiro ideal tem uma disputa genuína de lugares, pois uma empresa com mais secretárias do que colaboradores não irá testar nada de interessante, e interesse suficiente no resultado para nos dar feedback real em vez de feedback educado. A configuração e o mapeamento ficam por nossa conta.
Se está a gerir a ocupação híbrida através de mensagens Teams e já não tem paciência para isso, devíamos falar.
