Projetos / Método Base Ativa
Da operação fragmentada a um produto guiado por dados — e preparado para escalar.
Case em 30 segundos
Problema
O gestor não conseguia relacionar investimento, quantidade de leads, origem, vendedor e resultado comercial sem cruzar marketplaces, CRM, planilhas e informações dispersas.
Meu papel
Conduzo o produto de ponta a ponta: discovery dentro da operação, estratégia, UX/UI, regras, automações, código, infraestrutura, deploy e documentação.
Resultado até aqui
A operação ganhou distribuição automática, visão de origens e vendas, reativação da base, processos de estoque e dashboards usados em decisões reais; agora a fundação está sendo preparada para escalar.
O problema começou antes do dashboard
Os leads chegavam por 5–6 marketplaces e caíam em um CRM que funcionava principalmente como receptor. O pré-venda copiava manualmente nome, interesse e data, identificava o próximo vendedor da fila e encaminhava o contato pelo WhatsApp. Depois disso, a jornada ficava praticamente invisível. Para entender investimento, volume, conversão por vendedor e retorno por canal, o gestor precisava reconstruir a operação juntando CRM, planilhas, marketplaces e conversas individuais.
Fluxo anterior — a distribuição dependia de trabalho manual e a jornada perdia rastreabilidade ao chegar ao WhatsApp pessoal do vendedor.
Discovery dentro da operação
Observar
Estou diariamente dentro da Cerol acompanhando gargalos reais de distribuição, estoque, vendas, CRM e trabalho do gestor.
Cruzar evidências
As decisões partem de planilhas, CRM, dados dos marketplaces, informações comerciais e conversas recorrentes com quem usa a operação.
Validar em uso
Gestor, vendedores e consignadoras usam partes do produto e trazem necessidades que voltam diretamente para o ciclo de evolução.
Primeira intervenção: tirar a distribuição do caminho manual
A primeira solução foi menor do que o produto atual: uma automação em n8n para remover o gargalo do pré-venda. O fluxo passou a receber o lead e distribuí-lo automaticamente para o WhatsApp do próximo vendedor. Isso eliminou uma etapa manual importante, mas também revelou um limite que permanece até hoje: como a conversa acontece no WhatsApp pessoal do vendedor, o sistema ainda não consegue confirmar se houve resposta ou tentativa de contato.
Distribuição automática — o lead deixa de depender do repasse manual do pré-venda e chega diretamente ao próximo vendedor da fila.
Resolver a distribuição revelou um problema maior
Distribuir melhor não bastava. O gestor ainda precisava saber quantos leads entravam, de onde vinham, quanto cada canal custava e qual vendedor convertia melhor. A partir daí nasceu Origens e Vendas: uma camada para consolidar volume, origem, conversão e investimento em uma mesma leitura. O dashboard passou a apoiar decisões reais, como cortar marketplaces com baixo retorno e mudar a estratégia de investimento para geração de leads.
Origens e Vendas — canais, volume, investimento e conversão organizados para apoiar decisões comerciais.
Da mensuração para a reativação da base
Com os dados mais organizados, apareceu outra oportunidade: havia uma base de clientes parada, sem processo recorrente de reativação. O primeiro caso real nasceu do estoque. Quando um novo carro entrava, a automação recebia o veículo, consultava a base histórica, identificava pessoas que já haviam demonstrado interesse naquele modelo e enviava uma mensagem avisando sobre a disponibilidade. O histórico deixou de ser apenas arquivo e passou a funcionar como gatilho de oportunidade comercial.
Reativação por estoque — um novo veículo aciona a busca por leads com interesse anterior e cria uma nova oportunidade de contato.
O roadmap veio das necessidades
Entrou porque doía
Inbox para reduzir dependência do Chatwoot, Importações para facilitar entrada de dados, Estoque para centralizar consulta e Follow-up para reativar oportunidades.
Critério de prioridade
A regra prática é simples: a dor mais urgente observada na operação vem primeiro. O roadmap não foi definido como uma lista fixa de features.
Ficou para depois
Um relatório consolidado dos carros vendidos no fim do mês foi considerado útil, mas perdeu prioridade para problemas mais urgentes.
Iteração real: a ficha de veículos mudou depois do uso
O fluxo de cadastro e estoque evoluiu a partir de necessidades trazidas pelos próprios usuários. A ficha ganhou checklist de entrada do veículo, saída temporária de carro consignado e upload do documento com preenchimento automático dos dados. O efeito observado foi menos preenchimento manual, mais organização e a criação de processos operacionais que antes não estavam estruturados. A validação acontece diretamente com gestor e time, dentro da operação real.
Evolução da ficha de veículos — feedback de uso virou checklist, saída temporária e preenchimento automático a partir do documento.
O ponto de virada: de solução da Cerol para hipótese de produto
A pergunta sobre escala surgiu quando decidi preparar a solução para ser vendida a outro cliente. Copiar a estrutura da Cerol para cada nova operação criaria automações, regras e configurações independentes até virar uma bagunça difícil de manter no servidor. Padronizar tudo, por outro lado, ignoraria diferenças reais. A direção atual é manter uma fundação comum e tornar configuráveis as capacidades que variam por operação.
Hipótese de escala — manter uma fundação comum e tornar configuráveis as capacidades que variam por operação.
Deep dive: Portal e configuração por operação
O Portal concentra a complexidade menos visível do produto. Ele precisa permitir criar uma operação, configurar nome e acesso, cadastrar usuários, definir funcionalidades habilitadas e preparar automações n8n conforme o contexto. Já sabemos que mensagem, origem do lead, interesse, dados e funcionalidades podem variar; dashboards, linguagem de interface e padrões de interação tendem a permanecer compartilhados. Ainda não existe um segundo cliente em produção, então esta camada representa preparação para escala e será validada de verdade no primeiro onboarding externo.
Portal — estrutura administrativa para criar operações, usuários, acessos e funcionalidades sem duplicar um produto inteiro por cliente.
Arquitetura em evolução — uma fundação compartilhada com capacidades configuráveis, preparada para reduzir duplicação e desorganização técnica ao escalar.
Design System virou infraestrutura
À medida que dashboards, estoque, follow-up, inbox, portal e outros módulos cresceram sobre a mesma base, decisões visuais isoladas começaram a custar consistência e velocidade. O Design System passou a organizar tokens, componentes, estados e padrões de interação compartilhados. Aqui, UI Craft não entra como acabamento: ele sustenta a expansão do produto sem exigir que cada módulo reinvente a experiência.
Design System — componentes, tokens e padrões compartilhados para manter consistência entre módulos em expansão.
O produto já está dentro da operação
Uso real
Consignadoras usam o sistema diariamente para acompanhar estoque; vendedores consultam o estoque e o gestor acompanha dashboards, vendas e operação.
Decisão de negócio
Origens e Vendas já apoia cortes de marketplace e mudanças na estratégia de investimento em geração de leads.
Processos melhores
Distribuição ficou menos dependente do pré-venda manual e a ficha de veículos reduziu preenchimento, organizando entrada, saída temporária e documentação.
O que ainda não está resolvido
O case ainda tem fronteiras claras. Depois que o lead vai para o WhatsApp pessoal do vendedor, falta visibilidade sobre resposta e tentativa de contato. A arquitetura multi-cliente ainda não foi validada com um segundo cliente em produção. O Portal e a modularização das automações precisam provar o modelo no primeiro onboarding externo, e métricas quantitativas de impacto ainda precisam ser consolidadas. O próximo estágio não é adicionar mais telas; é fechar esses pontos cegos e provar que a fundação se sustenta fora da Cerol.
Aprendizados e próximos passos
Automatizar um gargalo revelou um problema de produto maior. Estar dentro da operação transformou discovery em um ciclo contínuo de observar, construir e validar. Também ficou claro que padronizar cedo demais apenas congela suposições: primeiro é preciso entender o que realmente varia, depois separar fundação compartilhada de regras configuráveis. Os próximos passos são aumentar a rastreabilidade após a distribuição, expandir a adoção do estoque pelo time, amadurecer o Portal, modularizar automações n8n, validar a arquitetura no primeiro cliente externo e começar a consolidar métricas de produto e operação.
