Dashboards Comerciais

Contexto e problema

O comercial de uma fintech de crédito decidia com números espalhados: réplicas de painéis de BI, planilhas paralelas e extrações pontuais. Cada consumidor aplicava a própria régua, e a mesma métrica aparecia com valores diferentes na TV da sala, na reunião de gestão e no relatório enviado por e-mail.

A plataforma junta tudo isso num só lugar: 13 dashboards para SDRs, closers, pós-venda, crédito e diretoria, painéis de TV que rodam sozinhos e uma API que entrega aos outros sistemas exatamente o mesmo número que aparece no card.

Restrições do ambiente

• A cota do CRM é da conta, não do token. Criar mais integrações não aumenta o throughput, só divide o mesmo orçamento. Tudo que fala com o CRM precisa ser controlado num ponto só.
• Fontes com comportamento traiçoeiro. O CRM devolve erro de lote dentro de um HTTP 200 e informa totais que não batem com filtros compostos; o data warehouse às vezes devolve menos linhas sem avisar.
• Número errado é pior que número atrasado. Uma métrica congelada com itens faltando fica errada para sempre.
• Acesso por papel, sem atrito. Login único da empresa, permissões por aba e por ação, e TVs que funcionam sem ninguém logado.

Decisões que definiram o produto

Arquitetura

Lições de operação

• Erro dentro de sucesso. Sub-erros de lote chegam em HTTP 200 e não abrem disjuntor sozinhos. O cliente inspeciona o corpo de cada resposta antes de tratá-la como sucesso, e nunca repete um erro de cota.
• Totais que mentem. Com filtros compostos, a paginação segue até páginas vazias consecutivas e deduplica por id, em vez de confiar no total informado.
• Linhas que somem. Consultas ao data warehouse levam um contador sentinela; se o número de linhas não bate, a leitura falha alto.
• Manada no restart. Sem escalonamento, todos os agendadores disparavam juntos a cada reinício e esgotavam a cota. Hoje eles sobem defasados.
• Reprocessar o passado com segurança. Reconstruções rodam em modo de simulação por padrão, com trava no banco e guarda de volume antes de escrever.

Meu papel

Concebi e construí a plataforma de ponta a ponta (produto, arquitetura, backend, frontend, integrações e operação), num fluxo guiado por especificações (59 specs) e com registro de incidentes no formato “meça, não opine”.

O que o produto entrega

• Login único com OAuth2 + PKCE, dois modos de entrada trocáveis sem deslogar ninguém e sessão com limite absoluto.
• Permissões por aba e por ação, mapeadas a partir dos grupos do diretório e editáveis no painel administrativo.
• Painéis de TV por link com token, em carrossel, sem login.
• Exportação para Excel ligada ou desligada por dashboard, e um relatório portátil em HTML único que roda os mesmos componentes offline.
• Snapshots diários, metas versionadas e trilha de auditoria.

O que eu faria diferente

• Rodar o CI também nos pull requests. Hoje a validação automática acontece só depois do merge.
• Uma fonte única para cada regra desde o início. Regras corrigidas num arquivo e esquecidas em outro geraram retrabalho até a criação dos testes de identidade.
• Planejar a saída do estado em memória mais cedo. O processo único foi a escolha certa, mas cada cache novo em memória aumenta o custo de escalar depois.