Case Atlas: ERP/CRM comercial com pipeline visual, faturamento e dashboard executivo

Por que não TOTVS ou SAP

O cliente era uma distribuidora de materiais industriais com 3 filiais, 45 vendedores externos e faturamento de R$ 180 milhões/ano. Antes de nos procurar, avaliaram TOTVS Protheus, SAP Business One e Bling.

A avaliação durou 4 meses. O resultado: TOTVS Protheus atendia 70% das necessidades, mas o custo de customização dos outros 30% era estimado em R$ 800 mil, mais licenciamento de R$ 22 mil/mês. SAP Business One tinha custo de implantação de R$ 1,2 milhão e prazo de 14 meses. Bling era barato mas não tinha a profundidade que o processo comercial exigia.

O problema específico era o fluxo comercial. A distribuidora vende para indústrias com ciclo de venda longo (45 a 90 dias), negociação técnica (especificação de material, compatibilidade, certificações), múltiplos decisores, e condições comerciais complexas (tabela de preço por cliente, desconto por volume, prazo de pagamento vinculado a histórico de crédito). Nenhum ERP de prateleira modelava isso sem customização pesada.

A decisão foi construir sob medida. O sistema ganhou o nome Atlas.

Stack e justificativas

React (frontend)

O time comercial passava 6 horas por dia no sistema. A experiência precisava ser rápida e fluida. React com Vite nos deu: hot module replacement durante desenvolvimento (ciclo de feedback de 200ms), bundle otimizado em produção (bundle inicial de 180KB gzipped), e um ecossistema maduro de componentes (usamos Radix UI como base e customizamos).

Não usamos Next.js porque o Atlas não precisa de SEO (é sistema interno, autenticado) e a complexidade de SSR não se justificava. SPA puro com React Router.

Node.js (backend)

O backend roda em Node.js com Express e TypeScript. A escolha foi prática: o time já dominava o ecossistema, e o padrão de uso do Atlas é I/O bound (consultas ao banco, integrações com API de nota fiscal, envio de emails). Para workloads I/O bound, Node.js com event loop é eficiente. Não temos processamento CPU-intensivo que justificasse Go ou Rust.

Organizamos o backend em módulos por domínio: vendas (pipeline, propostas, pedidos), cadastro (clientes, produtos, tabelas de preço), faturamento (NF-e, boleto, contas a receber), e analytics (dashboards, relatórios).

MongoDB

A escolha mais controversa. Por que MongoDB e não PostgreSQL?

O motivo: o schema das propostas comerciais varia por linha de produto. Proposta de aço inox tem espessura, acabamento, norma ABNT. Proposta de fixadores tem rosca, tratamento superficial, torque. MongoDB com documentos flexíveis resolveu: cada proposta é um documento com a estrutura que precisa. Indexes compostos por tenant e status garantem performance.

Para dados relacionais (cadastro, tabela de preço, contas a receber), usamos references com $lookup. O p95 das queries do dashboard executivo é de 340ms.

Redis

Redis entrou por dois motivos. O primeiro: cache de sessão e de tabelas de preço. A tabela de preço da distribuidora tem 180 mil SKUs com preço variável por cliente. Carregar isso do MongoDB a cada consulta era inviável. Redis com TTL de 15 minutos mantém a tabela quente para os vendedores ativos.

O segundo: fila de processamento. A geração de NF-e via Sefaz é síncrona e lenta (2 a 8 segundos por nota). Usamos Redis com Bull (agora BullMQ) como fila de jobs. O vendedor clica em "faturar", o pedido vai para a fila, e ele continua trabalhando. Quando a nota é autorizada, uma notificação aparece na tela.

O pipeline visual

O coração do Atlas é o pipeline de vendas. É um board Kanban com colunas configuráveis por etapa do funil: prospecção, qualificação, proposta enviada, negociação, fechado ganho, fechado perdido.

Cada card mostra: nome do cliente, valor estimado, probabilidade (definida pelo vendedor), data prevista de fechamento, e o vendedor responsável. Cards são arrastáveis entre colunas. Quando um card move de "proposta enviada" para "negociação", o sistema registra a data e calcula automaticamente o tempo médio em cada etapa.

A parte que mais agregou valor foi o "forecast ponderado". O sistema multiplica o valor de cada oportunidade pela probabilidade e agrupa por mês. Se o vendedor tem R$ 500 mil em pipeline com probabilidade média de 40%, o forecast é R$ 200 mil. O gerente comercial vê o forecast consolidado de todos os vendedores e compara com a meta mensal.

Tecnicamente, o drag-and-drop usa @dnd-kit/core com virtualização (react-window) para boards com mais de 200 cards. O estado é otimista: ao arrastar, a UI atualiza imediatamente, o backend confirma via API, e se houver conflito (outro vendedor moveu o mesmo card), o sistema reconcilia com last-write-wins e notifica.

Faturamento

O módulo de faturamento conecta vendas ao financeiro. Quando um pedido é aprovado, o sistema: gera a NF-e (integração com a Sefaz via API do Focusnfe), emite boleto (integração com Pagarme), registra a conta a receber, e atualiza o estoque.

A integração com Sefaz foi o módulo mais frágil. A Sefaz de SP rejeita notas por motivos que variam desde CNPJ inválido até "serviço indisponível". Implementamos retry com backoff exponencial, parsing detalhado dos códigos de rejeição (são mais de 700), e dashboard de monitoramento de taxa de rejeição por tipo.

A conciliação bancária importa o extrato OFX, faz matching por valor e data com contas a receber, e apresenta para confirmação manual. Taxa de match automático: 87%.

Dashboard executivo

O dashboard consolida: faturamento mensal vs meta, pipeline por etapa e por vendedor, taxa de conversão por etapa, ticket médio, ciclo de venda médio, top 10 clientes por receita, e inadimplência por faixa de atraso.

A implementação usa aggregation pipeline do MongoDB. Queries pesadas rodam em read replica. O dashboard atualiza a cada 5 minutos (decisão consciente para reduzir carga).

Os gráficos usam Recharts. Testamos Tremor, Chart.js e D3. Recharts ganhou por balancear flexibilidade e produtividade.

O que o cliente ganhou

Antes do Atlas, o ciclo de venda era controlado em planilhas Excel. Cada vendedor tinha a sua. O gerente consolidava manualmente toda sexta-feira. Propostas se perdiam. Follow-ups não aconteciam. A taxa de conversão era de 12%.

Depois de 6 meses com o Atlas: taxa de conversão subiu para 19%. O tempo médio de ciclo de venda caiu de 72 para 54 dias. A inadimplência com mais de 30 dias caiu de 9.2% para 5.8% (porque a régua de cobrança agora é automática). O gerente comercial tem visão em tempo real do pipeline, sem esperar a sexta-feira.

Em números absolutos: o aumento de 7 pontos percentuais na conversão, aplicado ao pipeline médio mensal de R$ 4,5 milhões, gera aproximadamente R$ 315 mil adicionais de faturamento por mês. O projeto inteiro custou R$ 420 mil. ROI em 40 dias.

Decisões que faríamos diferente

Se começássemos hoje, usaríamos PostgreSQL com JSONB em vez de MongoDB. O MongoDB funcionou, mas a falta de transações ACID em operações cross-collection causou bugs sutis no faturamento (duplicação de NF-e em condição de race condition). Resolvemos com distributed locks no Redis, mas era complexidade evitável.

Também investiríamos mais em testes de integração desde o sprint 1. Os primeiros 3 sprints foram sem testes. Quando adicionamos, encontramos 14 bugs que já estavam em produção. O custo de corrigir depois foi 4x maior que prevenir.

Stack completa: React, Vite, Radix UI, Recharts, Node.js, Express, TypeScript, MongoDB, Redis, BullMQ, Focusnfe, Pagarme, Docker, AWS EC2.

---

Precisa de um ERP/CRM sob medida? Fale com a Bradata.