Be.seated app main flow gif

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.

Be.seated app graph of bookings against check-ins

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.

Be.seated app concurrency diagram

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.

Be.seated code snippet

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.

Be.seated app seat lifecycle diagram

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.

Be.seated app check-in notification example

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.

Be.seated app screenshot of the privacy features in the main map

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.

Be.seated app screenshot of heatmap indicator sections Be.seated app analytics dashboard

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.

Be.seated app floor plan edition

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.

Be.seated e-tag seat companion

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.

Be.seated app screenshot

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.

Be.seated no show graph

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.

Marco Gonçalves
Marco Gonçalves

Como Diretor de Experiência Digital na Lynxmind, lidera a visão e a estratégia para o desenvolvimento web e mobile, combinando profunda competência técnica com uma abordagem centrada em quem usa. Com bases sólidas em desenvolvimento frontend e um olhar criativo para o design, impulsiona a inovação nas plataformas digitais, assegurando experiências intuitivas e de elevada qualidade. Acompanha de perto as tecnologias web mais recentes e alimenta na equipa uma cultura de exigência e de aprendizagem contínua, contribuindo para o crescimento e o impacto digital da empresa.