Os stakeholders defendiam manter quase todo o processo sob controle do CS, liberando ao usuário apenas ações muito básicas. A premissa era que expor complexidade desde o início geraria confusão, aumentaria o volume de suporte e afastaria novos clientes.

Eu não tinha certeza de qual era o caminho certo, mas acreditava que a decisão não deveria ser tomada por premissa. Os usuários provavelmente tinham mais capacidade do que os stakeholders estimavam. Propus uma fase de discovery para mapear esse limite com evidência antes de definir direção. Recebi apoio da PO, que compartilhava dessa visão comigo e, logo após, a proposta foi aceita e deu origem à fase de discovery.

1. Workshops cross-funcionais com CS e Support
   Mapeamento das fricções recorrentes, informações essenciais de serem cadastradas, pontos de falha no fluxo legado e das tarefas que mais consumiam capacidade operacional do time, estabelecendo a linha de base do problema antes de qualquer decisão de design.
2. Pesquisa com usuários
   Entrevistas no início da jornada para entender modelos mentais, nível de conforto com configurações complexas e o que os usuários realmente esperavam conseguir fazer sozinhos — testando diretamente a premissa dos stakeholders.
3. Shadowing com o time de CS
   Acompanhei reuniões com clientes recém-contratados, observando em primeira mão onde surgiam dúvidas, hesitações e dependências do suporte durante o processo de configuração. Foi o método que gerou os insights mais ricos sobre o comportamento real dos usuários no momento de maior vulnerabilidade da jornada.

1. A entrega do produto não correspondia à expectativa do usuário
   tanto nos workshops com CS e Support quanto no shadowing de reuniões, ficou evidente uma frustração recorrente com o tempo entre a contratação e o momento em que o cliente conseguia de fato usar a plataforma. Os usuários chegavam com expectativa de agilidade e encontravam uma espera que muitas vezes não conseguiam dimensionar nem acompanhar.
2. Quando o produto chegava, chegava tudo de uma vez
   A entrega do onboarding pelo CS despejava o acesso completo à plataforma. Para o usuário, a experiência era a de se deparar com um mar de informações sem saber por onde começar, dependendo completamente do CS para começar a desbravar a plataforma, o que gerava paralisia, não engajamento.
3. O mercado corroborou a necessidade de um onboarding mínimo e estruturado
   O benchmarking mostrou um cenário misto: algumas plataformas operavam com modelo totalmente high-touch, outras já sinalizavam movimentos em direção a mais autonomia do usuário nas etapas iniciais. Esse padrão confirmou que não havia uma resposta única — e que havia espaço real para um modelo intermediário, desde que bem estruturado.

A direção central foi tratar a ativação não como um cadastro técnico, mas como uma jornada de construção progressiva. Em vez de entregar a plataforma completa de uma vez, o fluxo foi estruturado em torno de uma sequência que fazia sentido para o usuário, começando pelos dados core da empresa no Essential Settings e avançando para os Single-Module Setups conforme a base estava estabelecida.

O hub de configuração reforçava essa lógica: deixava claro o que era obrigatório, o que era opcional, e permitia que o usuário saísse e voltasse a qualquer momento sem perder o progresso.

O CS não foi removido do processo, foi reposicionado. Em vez de conduzir o onboarding completo, passou a acompanhar a evolução do usuário: presente nas etapas que exigiam suporte, acionado em sua maioria, por escolha nas demais. O onboarding deixou de ser algo feito exclusivamente pelo CS, e passou a ser algo construído pelos dois juntos.

O shadowing e os workshops revelaram duas dores centrais: o TTV do produto não acompanhava o momento do usuário, o tempo entre a contratação e o primeiro uso real era longo demais e quando o acesso chegava, chegava como uma onda, tudo de uma vez, necessitando dependência do CS e suporte para dar os primeiros passos.

O benchmarking apontava para um modelo high-touch como padrão do mercado. Mas as pesquisas indicavam que o problema não era a complexidade do produto, mas sim a ausência de estrutura para navegá-lo. Isso abriu espaço para uma terceira via: não entregar tudo pelo CS, nem abandonar o usuário sozinho, mas construir um modelo de parceria onde os dois andassem lado a lado, um modelo híbrido.

1. Autonomia vs. Dependência residual do CS.
   O usuário ganhou controle sobre a ativação inicial, mas ainda existia a dependencia do CS na configuração de alguns módulos e em alguns casos, na configuração de todos, como antes. Reduzimos o atrito de entrada sem eliminar completamente a mediação humana e essa foi uma escolha consciente dentro das restrições do modelo de negócio
2. Progressão guiada vs. Liberdade de exploração
   A jornada estruturada em etapas reduzia a paralisia, mas retirava do usuário a possibilidade de explorar a plataforma toda de uma vez. Optamos pela estrutura porque os dados mostravam que a liberdade sem referência não gerava exploração, gerava abandono.

A sequência de 3 etapas não é apenas uma decisão de fluxo, é uma aplicação deliberada de progressive disclosure. O usuário nunca vê a complexidade total da plataforma de uma vez.

No primeiro acesso, apenas o essencial está disponível e ativo; os módulos adicionais existem no hub, mas só ganham protagonismo depois que a base obrigatória está completa. Isso reduz a carga cognitiva no momento de maior vulnerabilidade da jornada e permite que o usuário construa confiança antes de enfrentar decisões mais complexas.

O wizard segue uma sequência de 3 etapas:

1. Essential Settings (obrigatório)
   Dados institucionais, MFA configurável e gestão de acesso por usuário.
2. Single-Module Setup (obrigatório)
   Ativação de ao menos um módulo core.
3. Optional Expansion (livre)
   Configuração adicional de módulos no ritmo do usuário, pós-ativação.

1. Fluxo linear não-restritivo
   O usuário é guiado por uma sequência pré-definida, login, hub, Essential Settings, Single-Module Setup e após não tem obrigatoriedade de continuidade. É possível pausar, sair e retomar de onde parou sem perda de progresso.
2. Hub como ponto de orientação persistente
   A tela de configuração não é uma introdução descartável, é um espaço de referência. O usuário pode voltar a ela a qualquer momento para entender o que já completou, o que está pendente e o que é obrigatório vs. opcional.
3. Progressão por contexto, não por bloqueio
   A sequência das etapas segue uma lógica de dependência natural. A ordem faz sentido pelo contexto, não porque o sistema impõe uma trava.

Passo 1 — Essential Settings

Passo 2 — Single-Module Setup

Um dos pilares estruturais do fluxo foi antecipar e neutralizar os pontos de atrito antes que eles se tornassem erros. O Proactive Error Prevention se manifestou em três camadas:

• Alertas contextuais no hub indicando a próxima ação obrigatória antes de o usuário tentar avançar sem ela
• Templates pré-validados na etapa de importação de dados do Smart Inventory, eliminando o ciclo de tentativa e erro em uploads
• Restrições técnicas explicitamente comunicadas antes do input, não depois da falha

O resultado foi uma redução de fricção que não dependia de o usuário ler documentação, a própria interface ensinava as regras do sistema no momento certo.

Passo 3 — Optional Expansion

• O protótipo foi revisado com o time de CS que tinha um maior conhecimento do fluxo anterior.
• Em seguida, conduzimos sessões de teste com usuários recém-contratados — o perfil mais próximo do momento real de onboarding — acompanhados pelo CS durante as sessões.

Sinais monitorados: tempo de conclusão por etapa, taxa de avanço sem intervenção externa, hesitação antes de iniciar novas etapas, necessidade de confirmação visual durante entradas de dados, comportamento espontâneo de navegação entre módulos opcionais e dependência do CS para tomada de decisão dentro do fluxo.

• Smart Inventory oficializado como fluxo obrigatório primário
  Os testes confirmaram aderência espontânea ao módulo, usuários o priorizavam naturalmente antes mesmo de serem direcionados. Como o módulo concentrava o maior valor de negócio, a decisão foi torná-lo o ponto de entrada obrigatório.
• Indicadores de tempo e progresso nos cards
  A ausência de referência sobre o esforço esperado gerava hesitação antes de iniciar cada etapa. Indicadores de tempo estimado e progresso foram adicionados nos cards para reduzir a incerteza e dar ao usuário controle sobre como distribuir sua atenção.
• Guia de lógica da plataforma persistente
  Usuários demonstravam dúvidas recorrentes sobre como as configurações se relacionavam entre si. Um guia de lógica persistente foi adicionado, sempre acessível, nunca intrusivo, funcionando como âncora de referência sem interromper o fluxo.
• Banner de Setup Progress contextual e adaptativo
  Mesmo com o hub estruturado, havia hesitação sobre qual ação tomar a seguir. Foi adicionado um banner que atualiza dinamicamente conforme o progresso do usuário, sinalizando sempre a próxima ação esperada, uma orientação contextual presente no momento exato em que o usuário precisava de certeza para seguir em frente.

• 68% dos usuários completaram o fluxo obrigatório de ativação sem nenhuma intervenção externa.
• 52% dos usuários que completaram o fluxo avançaram para um módulo opcional de forma autônoma.
• 73% de redução em tarefas de suporte relacionadas ao onboarding no primeiro trimestre após o deploy.
• Redução do TTV de até 12 dias para 1 dia.

• Sinais de intenção capturados via módulos opcionais permitiram correlacionar features específicas com segmentos de alto valor
• Feedback qualitativo do CS confirmou melhora significativa na autonomia dos novos usuários e na compreensão da lógica da plataforma

• Aceleração do TTV: Ativação de alta velocidade mesmo para setups complexos de ERP.
• Paradoxo do Engajamento: Observou-se um aumento estratégico em tickets sobre fluxos avançados nos primeiros 60 dias, indicando que usuários motivados pelo TTV rápido exploram a plataforma com mais profundidade e confiança.
• Dados como Descoberta: O uso de módulos opcionais passou a servir como sinal de intenção para futuras iterações do produto.

• Complexidade é design, não problema: o risco não está na profundidade da tarefa, mas na ausência de guia. Um fluxo bem estruturado pode tornar configurações avançadas acessíveis.
• O medo interno como dado de pesquisa: a resistência dos stakeholders ao self-service foi tratada como hipótese a ser validada, não como restrição de design e foi refutada pela evidência.
• Métricas de suporte como proxy de qualidade 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.

O aumento estratégico de tickets sobre fluxos avançados — observado nos primeiros 60 dias pós-implementação — não foi tratado apenas como uma métrica de impacto, mas como um sinal de produto. Esses tickets revelaram, com precisão, quais fluxos geravam maior atrito após a ativação inicial, fornecendo o insumo necessário para um mapeamento orientado por comportamento real.

Esse conjunto de dados comportamentais abre caminho para uma próxima camada de intervenção de design: a implementação de contextual tips direcionadas nos pontos de maior fricção identificados. Em vez de suposições sobre onde os usuários travam, teríamos evidência direta para priorizar quais fluxos entram na backlog — garantindo que cada intervenção futura seja cirúrgica, relevante e com alto potencial de redução de carga para o CS.