Escalando operações para um ERP de ativos
Overview
O produto
NexFlow é um SaaS B2B que centraliza controle de ativos e gestão financeira. Com o crescimento da base, o onboarding — feito inteiramente pelo CS em nome de cada cliente — virou o gargalo entre fechar o contrato e o cliente extrair valor real.
Meu papel
Product Designer responsável pelo design end-to-end. Conduzi a pesquisa avaliativa, fiz shadowing com clientes recém-contratados, facilitei workshops cross-funcionais com CS e produto, arquitetei a solução e coordenei os testes de usabilidade.
Time e duração
Eu, um Product Owner, desenvolvedores de frontend e backend, e o CTO participando das decisões de direção. CS e Support atuaram como stakeholders e fontes de pesquisa. Aproximadamente 1 mês do discovery ao deploy.
Discovery
O contexto
Os dados internos mostravam o quê, mas não o porquê. Para formular uma hipótese de solução, precisei entender o que acontecia do lado do usuário e do lado do CS durante o onboarding.
O que investigamos
O que encontramos
Espera sem régua
O shadowing revelou a maior frustração: o tempo entre contratar e conseguir usar. O cliente chegava esperando agilidade e encontrava uma espera que não conseguia dimensionar — sem visibilidade de quando começaria a operar.
Tudo de uma vez = paralisia
Nas entrevistas com usuários, ficou claro o que acontecia quando o acesso finalmente chegava: vinha completo, de uma só vez. O usuário encarava um mar de informação sem saber por onde começar — paralisia, não engajamento.
CS e Support como mapa
Os workshops com CS e Support revelaram quais módulos concentravam mais dúvidas, mais dificuldades e mais valor percebido pelos usuários — um norte direto para priorizar o que o onboarding precisava cobrir primeiro.
Capacidade subestimada
A pesquisa com usuários revelou que muitos já usavam outras plataformas e ferramentas para gerenciar seus ativos, e tinham mais capacidade técnica do que o time interno estimava. O gap não era de habilidade, era de estrutura.
Nenhum modelo dominante
O benchmark não apontou uma abordagem padrão — de high-touch a self-service, cada modelo resolvia um pedaço do problema. Nenhum ERP do mesmo porte operava 100% self-service.
"Queria ter isso quando eu contratei"
A decisão central
A direção
Três caminhos foram avaliados antes de definir a direção.
Full self-service (descartado)
A complexidade do ERP tornava o risco de abandono alto demais sem nenhum apoio. O benchmark confirmou: nenhum ERP do mesmo porte operava 100% self-service.
CS com automação parcial (descartado)
Automatizar tarefas do CS sem mudar o processo poderia ser mais seguro, mas o outcome seria menor: o TTV continuaria alto e a dependência do time interno permaneceria intacta.
Modelo híbrido (escolhido)
Dar autonomia ao usuário com o CS reposicionado como suporte estratégico, não executor. O usuário conduz; o CS acompanha e intervém apenas quando a etapa exige.
Progressão, não formulário
A paralisia vinha de receber tudo de uma vez. A mudança foi tratar a ativação como construção progressiva — cada etapa entrega valor antes de pedir a próxima.
Hub como âncora
A espera sem régua mostrava que faltava referência. O hub resolve isso: o usuário vê o que já fez, o que falta e o que é opcional — sai e volta sem perder contexto.
CS reposicionado, não removido
Em vez de conduzir o onboarding inteiro, o CS passou a acompanhar a evolução do usuário — presente quando a etapa exige, acionado por escolha nas demais.
Os tradeoffs
| Decisão | Ganho | Custo |
|---|---|---|
| Autonomia vs. dependência residual do CS | O usuário ganha controle da ativação inicial | A mediação humana não foi totalmente eliminada — escolha consciente dentro do modelo de negócio |
| Progressão guiada vs. liberdade total | A jornada em etapas reduz a paralisia | Tira a exploração livre — mas os dados mostraram que liberdade sem referência gerava abandono, não exploração |
A solução
A estrutura
Um wizard de 4 etapas como aplicação direta do progressive disclosure: o usuário nunca vê a complexidade toda de uma vez. No primeiro acesso, só o essencial está ativo — as etapas livres aparecem conforme a base se estabelece.
As etapas
- 01Fundação
Dados institucionais, MFA e gestão de acesso.
O MFA e a gestão de acesso são pré-requisitos técnicos, mas também o primeiro contato do usuário com a plataforma. O design tratou essa etapa como porta de entrada, não burocracia — cada campo tem contexto e o progresso é visível desde o início.
- 02Primeiro módulo
Ativação do módulo core prioritário.
O achado de que 'tudo de uma vez = paralisia' definiu essa decisão: em vez de liberar o sistema inteiro, o usuário ativa um módulo por vez. Nos testes, o Smart Inventory era priorizado espontaneamente — o módulo que o time via como complexo era o que o usuário mais queria configurar primeiro.
- 03Expansão livre
Módulos adicionais no ritmo do cliente.
Opcional, sem bloquear o uso da plataforma. O momento em que o usuário importava seus primeiros ativos e os via na tela era o ponto de virada — a prova tangível de que o sistema já conhecia o negócio dele.
- 04Acesso ao ambiente
Entrada na plataforma configurada.
O hub permanece como referência persistente — o que foi ativado, o que ainda pode ser explorado e onde o CS está disponível. A plataforma não 'começa' aqui; ela já começou na primeira etapa.
Prevenção de erros
Um pilar do fluxo foi antecipar o atrito antes que virasse erro, em três camadas: alertas contextuais no hub apontando a próxima ação obrigatória, templates pré-validados na importação do Smart Inventory eliminando tentativa e erro, e restrições técnicas comunicadas antes do input — não depois da falha.
Stakeholders Review
O cenário
Com o discovery concluído e a solução definida, apresentei a proposta para os stakeholders. Dois medos surgiram imediatamente: o risco de aumento nos tickets de suporte ao dar mais autonomia ao usuário, e o tempo de produção — a solução completa envolvia muitos fluxos e a entrega integral demoraria.
Adaptação para um processo Lean UX
Em vez de recuar diante da resistência, propus uma abordagem de Lean UX: delimitar o escopo em um MVP funcional — os fluxos mais críticos primeiro — para homologação rápida. Os dados reais de produção seriam o critério de expansão, não a aposta inicial.
Dados como argumento
Liberamos os primeiros fluxos, analisamos os números reais de resultado, e fomos homologando os demais dentro do hub conforme o comportamento se confirmava nos dados de produção. Os stakeholders passaram de resistentes a defensores da abordagem.
Validação e iteração
O método
Revisei o protótipo com o CS — quem mais conhecia o fluxo antigo — e testei com usuários recém-contratados, o perfil mais próximo do onboarding real.
As iterações
Smart Inventory virou ponto de entrada
Nos testes, os usuários priorizavam o Smart Inventory espontaneamente quando tinham liberdade de escolha. Como o módulo concentrava o maior valor de negócio, a evidência consolidou a decisão de posicioná-lo como passo obrigatório primário — decisão que nasceu do comportamento observado, não da hipótese inicial.
Tempo e progresso nos cards
A falta de referência sobre o esforço esperado gerava hesitação antes de cada etapa. Adicionei indicadores de tempo estimado e progresso para reduzir a incerteza — a mesma lógica de 'espera sem régua' do discovery, agora dentro do fluxo.
Guia de lógica persistente
Usuários demonstravam dúvidas recorrentes sobre como as configurações se relacionavam entre si. Adicionei um guia de lógica sempre acessível e nunca intrusivo, funcionando como âncora de referência sem interromper o fluxo.
Banner de progresso adaptativo
Mesmo com o hub, faltava certeza sobre a próxima ação. Criei 5 estados para o banner que atualiza dinamicamente conforme o progresso, sinalizando o próximo passo e incentivando configurações pendentes.
Impacto
O que os números revelaram
Paradoxo do engajamento
Nos primeiros 60 dias, tickets sobre fluxos avançados — não mais sobre onboarding básico — aumentaram. Usuários ativados rápido exploram mais e com mais confiança. O dado que os stakeholders temiam (mais tickets) virou a prova de que a autonomia funcionou.
Dados como descoberta
O uso de módulos opcionais virou sinal de intenção — correlacionando features a segmentos de alto valor e alimentando as próximas iterações do produto.
Expansão gradual validada
O fluxo foi liberado como MVP e expandido iterativamente conforme os dados confirmavam o comportamento esperado. Os módulos homologados aos poucos dentro do hub passaram de resistência dos stakeholders a referência interna de como validar e crescer uma feature.
Churn precoce reduzido em 12%
Com o TTV caindo de 12 dias para 1, o cliente passou a extrair valor real muito mais rápido. A queda de 12% no churn precoce — medido nos primeiros 90 dias pós-contratação — foi o impacto mais relevante para o negócio: retenção na fase mais crítica do ciclo de vida do cliente.
Aprendizados
Complexidade é design, não problema
O risco nunca esteve na profundidade da tarefa, mas na ausência de estrutura para navegá-la. Um fluxo bem estruturado tornou configurações avançadas de ERP acessíveis para usuários sem perfil técnico.
Dados abrem, qualitativo direciona
Os dados internos que abriram o projeto foram o gatilho, mas o discovery mostrou o que eles não diziam: o problema não era o onboarding ser manual, era a falta de referência e progressão para o usuário.
Tickets como proxy de UX
A queda em tickets operacionais e o surgimento de tickets de uso avançado, juntos, contam uma história mais rica do que cada métrica isolada.
What's next
O aumento de tickets sobre fluxos avançados não foi só métrica, foi sinal de produto: revelou exatamente onde o atrito aparece depois da ativação.
O próximo passo é usar esses dados para dar mais atenção para pontos específicos de maior fricção — importação de ativos em lote, configuração de permissões por filial e integração com APPs — usando comportamento real para priorizar, não suposição.