Consultoria PJ · 2026
Onboarding digital de um ERP financeiro
Construí do zero o novo front de onboarding do ERP, em Vue 3 e TypeScript, e depois a autocontratação no mesmo repositório. O onboarding caiu de 12 para 3–4 minutos.
- 8etapas no novo onboarding
- 2jornadas no mesmo front, isoladas
- 12 → 3–4 mintempo de onboarding
- +20%conversão até virar cliente
O problema
Num ERP financeiro B2B, o onboarding é o primeiro contato do cliente com o produto. Se ele é longo ou confuso, o cliente desiste antes de usar o sistema.
O onboarding antigo era uma SPA em Vue 3 que tinha crescido por acúmulo. A jornada se organizava em macroestados com subetapas: contratos, lojas, valores, assinatura e parametrização. O que aparecia mudava conforme o contrato e o status do lead. Parte das entradas ainda passava pelas telas MVC do ERP. Era difícil saber em que ponto o cliente estava e mais difícil ainda mudar o fluxo sem quebrar outro caminho.
O que eu fiz
Um front novo, do zero
Comecei o repositório e construí a SPA nova com Vue 3.5, TypeScript, Vite e Pinia, organizada por features. Cada etapa tem a sua página, o seu estado e o seu serviço. Componentes, validação e o cliente HTTP ficam numa camada compartilhada.
O onboarding virou uma jornada linear de oito etapas: contato, código de confirmação, usuários, empresas, confirmação cadastral, proposta, termos e conclusão.
O back-end como fonte da verdade
O front valida para orientar a pessoa, mas quem decide é o servidor. Sessão, elegibilidade e progresso ficam no back-end, e a interface só avança quando ele confirma. Isso evita um problema clássico de wizard: o navegador achar que a etapa terminou enquanto o servidor discorda.
Uma segunda jornada sem duplicar o front
Depois veio a autocontratação: contato, produtos, resumo, comercial e sucesso. Ela tem regras de navegação e dados diferentes do onboarding. Coloquei as duas no mesmo repositório com routers, stores e builds separados por jornada, e extraí os componentes visuais comuns para uma camada compartilhada. Um checkpoint local permite retomar o rascunho, mas catálogo, preço e conclusão continuam confirmados pelo servidor.
Back-end em .NET
Também trabalho no back-end em C# e .NET com MongoDB. Ajustei os casos de uso de aceite de termos e de sincronização de empresas, com testes. Tornei atômica e idempotente a geração do link de onboarding, com nova tentativa só no conflito de transação previsto.
Decisões e trade-offs
Oito etapas explícitas em vez de estados implícitos. Cada etapa tem entrada e saída claras, o que facilita medir o funil e mudar uma parte sem mexer no resto. O custo: uma jornada linear é mais rígida, e cada exceção de negócio precisa virar uma regra explícita de navegação.
Isolar as jornadas e compartilhar só a apresentação. Duplicar o front inteiro seria mais rápido no primeiro dia e caro em todos os outros. Juntar tudo num router só acoplaria regras que mudam por motivos diferentes. Separar estado e navegação e compartilhar componentes é o meio-termo. O custo é disciplina: decidir caso a caso o que é comum de verdade.
Migrar por entrada, não por big bang. As entradas antigas foram redirecionadas para a experiência nova aos poucos. O legado continua de pé enquanto houver consumidor.
Resultado
O novo onboarding substitui o antigo nas entradas migradas. O tempo médio de onboarding caiu de 12 para 3–4 minutos, e a conversão até virar cliente subiu 20%.
A autocontratação ganhou uma jornada própria sem duplicar a base de código.
O que eu faria diferente
Instrumentaria o funil por etapa desde o primeiro commit, com eventos padronizados, para conseguir dizer qual mudança pesou mais no ganho de tempo.
Também escreveria testes de contrato entre o front e o back para as transições de etapa. Os testes unitários cobrem componentes, stores e guards, mas o ponto mais frágil de um wizard é o front e o back discordarem sobre em que etapa a pessoa está.