Um recepcionista identificou falhas operacionais reais, ouviu a equipe, e construiu do zero — sem budget, sem TI, sem pedir autorização — um sistema completo de gestão que eliminou perdas, criou visibilidade e mostrou o que acontece quando funcionários engajados têm ferramentas à altura do seu empenho.
Meu papel, por que o sistema existe, e o que ele significa além do código.
Fui o único responsável por tudo — identificação do problema, pesquisa com a equipe, definição de escopo, arquitetura da informação, design de interface, desenvolvimento front-end, testes e iterações contínuas. Não há equipe de UX, não há squad de produto. Há um recepcionista que ouviu a equipe, sentiu as mesmas frustrações, e decidiu transformar insatisfação coletiva em solução concreta.
O sistema adota as cores oficiais da WPM (#FFC20F e #111111), tipografia Montserrat, e uma linguagem visual densa e executiva — pensada para monitores de recepção em ambiente de alta demanda.
O design comunica profissionalismo sem exigir designers. É a única ferramenta visual que a equipe usa no turno.
Este projeto nasceu dessa realidade. Não apenas da minha — mas de conversas reais com colegas de recepção, de feedbacks que se repetiam em unidades diferentes, de uma insatisfação comum: funcionários que entregam mais não são visíveis. E o que não é visível, não é valorizado.
Trabalho na recepção da WPM Pampulha em Belo Horizonte. Sou responsável pelo atendimento de novos alunos, controle de pendências, acompanhamento de NPS e gestão operacional do dia a dia. Paralelamente, curso CST Gestão Comercial na UNINTER e carrego uma visão de liderança humanizada — a crença de que quem está na linha de frente tem os dados mais valiosos.
O sistema hoje está na v34, com arquitetura de camadas, IndexedDB dual, suíte de autotestes, backup JSON, exportação CSV, Painel de Recados e 9 módulos operacionais completos. Avaliado com 9,5/10 em avaliação de QA sênior (Gemini Pro).
A escolha não foi limitação técnica — foi decisão de design. Um arquivo HTML que roda em qualquer navegador, sem instalação, sem login, sem servidor, é universalmente acessível pela equipe da unidade. É a solução mais democrática possível para o contexto de uma academia. O arquivo pode ser passado por pen-drive, WhatsApp ou e-mail — e funciona imediatamente.
Como a recepção funcionava antes do sistema — e o que estava sendo perdido todos os dias.
O controle operacional era feito de forma manual: planilhas fragmentadas, anotações em papel, WhatsApp para pendências. Dados de alunos novos, vendas de addons, NPS e escala de trabalho não tinham uma fonte única da verdade.
Cada recepcionista registrava informações de forma diferente. Relatórios mensais levavam horas para compilar. Pendências se perdiam entre turnos. Recados urgentes não chegavam a quem precisava.
Além dos dados — o que a falta de visibilidade faz com as pessoas que trabalham na linha de frente.
Sem dados, o esforço individual desaparece. Quem atende mais alunos, vende mais addons ou resolve mais pendências não tem como provar — e não é reconhecido por isso.
A falta de ferramentas adequadas para o nível de responsabilidade exigido cria uma dissonância: você tem exigências de gestor com recursos de auxiliar.
Cada troca de turno sem registro formal é uma oportunidade de erro. Alunos importantes, pendências críticas e avisos operacionais se perdem entre conversas informais.
Conversas reais, frustrações reais — a base para todas as decisões de design.
9 módulos operacionais, 34 versões, arquitetura de camadas — tudo em um único arquivo HTML.
O sistema é uma Single Page Application (SPA) single-file — um único arquivo .html com ~11.500 linhas de HTML, CSS e JavaScript. O estado é armazenado em IndexedDB como backend primário e localStorage como espelho de fallback, segregado por período no formato YYYY-MM.
A arquitetura é dividida em 7 camadas explícitas: config → persistência → schema → domínio/seletores → renderização → UI/eventos → diagnósticos. Todo o contrato de atualização é explícito: Ação → Mutação → saveData() → requestRender().
A passagem de turno era a principal dor identificada na pesquisa. O Painel de Recados resolve isso diretamente: o recepcionista que encerra o turno deixa avisos para quem assume, com controle de destinatário (colega específico ou "Todos").
Os recados são persistidos por período no mesmo storage do sistema. Um contador de "recados não lidos" aparece na interface assim que a aba é acessada, criando urgência de leitura sem notificações externas.
A aba de Configurações evoluiu para uma central de operações técnicas com 5 painéis independentes:
Design system completo, acessibilidade real e UX pensada para uso em ambiente de alta demanda.
Custom properties CSS cobrindo toda a paleta: --primary (#FFC20F), variantes soft/strong, estados danger/ok/warning. Topbar sticky com backdrop-filter: blur(12px), sempre visível durante scroll.
Tipografia Montserrat + JetBrains Mono para valores numéricos. Cards com mouse glow via CSS custom properties. Transições em 180ms para feedback imediato.
/ foca busca da aba ativa. Esc fecha modais. Todos os botões com type="button".aplicarHtmlSeMudou() compara string HTML nova com o DOM atual antes de qualquer update. Zero reflow desnecessário. Patch por ID em listas via aplicarPatchCards().
Toda derivação de dados passa por lerSelectorMemorizado() indexado por período + assinatura JSON. Cache com limite de 120 entradas antes de limpeza automática.
IndexedDB primário + localStorage espelho. Fila serializada via queueStorageOperation() elimina race conditions. Broadcast cross-tab sincroniza múltiplas abas abertas.
Regras que não podem ser quebradas em nenhuma versão presente ou futura do sistema.
persistStoredValue() que trata QuotaExceededError explicitamente — nunca falha silenciosamente.Cada versão com um objetivo. Cada regressão com uma lição. Cada milestone com um critério de aprovação.
Um sistema em produção, avaliado externamente e pronto para evoluir.
Que quem está na linha de frente tem os dados mais valiosos — e tem capacidade de transformá-los em sistema quando recebe a oportunidade.
Que uma SPA de 100+ horas, sem backend e sem equipe, pode atingir nível de qualidade avaliado em 9,5/10 por um QA sênior externo.
Que a próxima fase — full-stack com React, Fastify e PostgreSQL — não começa do zero. Começa com regras de negócio validadas em produção real.
O sistema foi submetido a uma avaliação de QA sênior completa considerando: arquitetura de camadas, qualidade de código, robustez de persistência, pipeline de renderização, segurança XSS, acessibilidade e completude funcional. Resultado: 9,5/10, considerando as limitações inerentes à arquitetura browser-only single-file.
A fase browser-only foi o laboratório de regras de negócio. A próxima fase é a migração para arquitetura profissional: React + TypeScript + Vite no frontend, Node.js + Fastify + PostgreSQL + Prisma no backend, com CI/CD via GitHub Actions e deploy na Vercel + Railway + Neon.
O v34.html passa a ser a referência funcional oficial — jamais reescrito, mas lido como fonte da verdade de comportamento e regras de negócio para a nova arquitetura.