22 de agosto de 2026

O problema do segundo fluxo de trabalho: por que a ativação morre depois da primeira vitória

O cadastro é instrumentado nos mínimos detalhes. O momento que decide a retenção vem depois, quando o usuário tenta usar o produto para aquilo que ele realmente serve — e ninguém está olhando.

Três colegas trabalhando juntos em um notebook

Toda reunião de análise de onboarding de que já participei segue o mesmo roteiro. Alguém mostra o funil de cadastro, aponta a queda entre “conta criada” e “ativado”, e a sala concorda em consertar os cinco primeiros minutos. Formulário mais curto. Estado vazio melhor. Um product tour. Aí os números mal se mexem, porque o usuário que vai embora raramente se perdeu nos cinco primeiros minutos. Ele se perdeu na segunda semana, tentando fazer aquilo que veio fazer — e ninguém estava olhando esse momento.

Quero dar um nome a esse momento, mostrar como encontrá-lo nos seus próprios dados e defender que ele é o lugar de maior alavancagem que existe para colocar ajuda dentro de um produto.


Dois fluxos de trabalho, um funil

Todo produto tem um primeiro e um segundo fluxo de trabalho, e os dois são de naturezas diferentes.

O primeiro fluxo de trabalho é a configuração. Criar um workspace, convidar um colega, conectar uma fonte, importar um arquivo. É linear, é igual para todo mundo e, justamente por ser igual para todo mundo, é fácil de colocar num tour, fácil de instrumentar e fácil de otimizar. É para cá que vai a maior parte do esforço de onboarding e, sinceramente, a maioria dos produtos vai bem aqui.

O segundo fluxo de trabalho é a tarefa de verdade. Montar o primeiro relatório real. Disparar a primeira campanha. Fazer a primeira conciliação. É o que o usuário descreveria se você perguntasse por que ele se cadastrou. Tem várias etapas, se ramifica conforme os dados dele, depende das escolhas feitas na configuração e muda entre uma startup de duas pessoas e uma empresa com 400 licenças.

O funil trata os dois como um número só. “Ativado” costuma ser definido pelo primeiro fluxo — porque é ele que emite eventos limpos — e assim o painel fica verde exatamente no momento em que o risco real começa.

Olhe a sua definição de ativação. Se todos os eventos dela podem ser concluídos por um usuário que ainda não produziu nada de valor com o seu produto, a sua métrica de ativação está medindo configuração, não sucesso.


Por que é no segundo fluxo de trabalho que os usuários vão embora

Não é que o segundo fluxo seja mais difícil, embora costume ser. É que ele fica sem apoio de um jeito bem específico.

O tour já passou. Product tours disparam uma vez, na primeira visita, num caminho conhecido. O segundo fluxo acontece no quarto dia, numa página por onde o tour nunca passou, partindo de um estado que quem escreveu o tour não previu.

A documentação é genérica. Ela explica a funcionalidade. Não consegue explicar a funcionalidade para esta conta, com estes dados, neste plano, depois que o usuário pulou o terceiro passo da configuração. Quanto mais o seu produto se adapta ao cliente, menos uma documentação genérica consegue dizer.

Ninguém do seu lado sabe que isso está acontecendo. Um usuário travado na configuração às vezes escreve para o suporte. Um usuário travado no segundo fluxo normalmente não escreve: acha que a culpa é dele, pretende voltar depois e não volta. Não há ticket, nem gravação de sessão que alguém assista, nem alerta. A conta fica em silêncio e cancela na renovação, com um histórico de suporte impecável.

O segundo fluxo é onde o produto deixa de ser uma demo e passa a ser trabalho. É também o momento em que a maioria dos produtos para de ajudar.


Como encontrá-lo nos seus dados

Você quase certamente já tem os eventos; só não traçou a linha no lugar certo. Este é o exercício que eu faria esta semana.

1. Escreva, em uma frase, a tarefa que um novo cliente veio fazer quando se cadastrou. Não uma funcionalidade — uma tarefa. “Enviar uma campanha para uma lista real.” “Fechar o mês.”

2. Associe essa tarefa à menor sequência de eventos que prove que ela aconteceu. De três a seis eventos, terminando em algo que existe no mundo real: um e-mail enviado, um período fechado, uma página publicada.

3. Meça a parcela de usuários que conclui essa sequência em até 14 dias depois de terminar a configuração. Chame isso de conclusão do segundo fluxo de trabalho.

4. Coloque esse número ao lado da sua métrica de ativação atual.

A diferença entre esses dois números é o seu verdadeiro problema de onboarding e, na maioria dos produtos, é o maior número do funil.

1º — fluxo de trabalho é a configuração — linear, com tour, instrumentado

2º — fluxo de trabalho é a tarefa de verdade — cheio de ramificações, sem tour, onde os usuários vão embora

14 dias — uma janela razoável para a conclusão do segundo fluxo de trabalho


Alguém trabalhando no notebook, sentado no sofá

Como esse número costuma ser

Todo time a quem pedi esse exercício encontrou o mesmo padrão: ativação na faixa de 40–60%, conclusão do segundo fluxo em algum ponto entre 10% e 25%. Metade dos usuários que o seu painel chama de ativados nunca faz aquilo que veio fazer. Isso não é um problema de documentação nem de acabamento de UX. É um problema de ajuda na hora certa.


Por que as soluções óbvias rendem pouco

Mais tours. Os times tentam criar um tour para o segundo fluxo e descobrem por que ninguém faz isso: ele se ramifica. Um tour que funciona numa conta vazia quebra numa conta com dados importados; um tour para o plano Growth aponta para um botão que o plano Launch não tem. Você acaba mantendo uma árvore de tours que apodrece a cada mudança na interface.

Documentação melhor. A documentação é a resposta certa para consulta e a resposta errada para um usuário travado. O usuário travado precisa sair do produto, achar a página certa, traduzir instruções gerais para a tela específica dele e voltar — tudo isso guardando de cabeça o que deixou pela metade. A maioria não volta.

Um widget de chat. Chega mais perto, porque pelo menos a ajuda está dentro do produto. Mas um bot que leu a sua documentação responde em texto corrido, e texto ainda precisa ser traduzido em cliques. Ele também não vê a tela do usuário, então não tem como saber que o botão que está descrevendo está desativado no plano dele.

Cada uma dessas soluções melhora um pouco o número, o que dá a impressão de que é o caminho certo. Não é. Todas batem no mesmo teto: descrevem o produto para o usuário em vez de fazer o fluxo junto com ele.


O que realmente muda esse número

Os clientes que concluem o segundo fluxo em taxas altas são os que têm um Customer Success Manager humano dedicado. Não é coincidência, e não é porque o CSM conhece o produto melhor do que a documentação. É porque o CSM faz três coisas que a documentação não faz:

– Vê a situação real do usuário — a tela, os dados, o plano dele — e dá o próximo passo específico, não o genérico.

– Conduz o usuário pelo caminho, ao vivo, em vez de descrevê-lo. Apontar o botão é melhor do que dizer o nome do botão.

– Percebe o silêncio. Quando uma conta empaca no segundo fluxo, o CSM entra em contato antes que o usuário conclua que o produto não é para ele.

A conta de um CSM humano só fecha acima de um certo valor de contrato. O que torna esse problema tão interessante para mim é que os três comportamentos agora são coisas que um software consegue fazer: ler a interface renderizada, levar o cursor até o elemento, acompanhar o uso e falar primeiro. É toda a tese por trás do Barkan — um Customer Success Manager para cada conta, não só para as grandes — e o segundo fluxo é exatamente onde ele justifica o seu lugar.

– Sua métrica de ativação provavelmente mede configuração, não sucesso. Defina e acompanhe a conclusão do segundo fluxo de trabalho separadamente.

– Os usuários vão embora no segundo fluxo porque ele não tem tour, não tem documentação no contexto e acontece em silêncio — não porque seja difícil demais.

– A solução é uma ajuda que vê a tela, mostra o passo e fala primeiro. Descrever melhor o produto tem um teto baixo.


Um plano prático para os próximos 30 dias

1. Esta semana: defina o segundo fluxo de trabalho e meça a conclusão. Prepare-se para um número desconfortável.

2. Segunda semana: analise dez sessões de usuários que começaram o segundo fluxo e não terminaram. Anote o passo exato em que cada um empacou. Os pontos vão se concentrar.

3. Terceira semana: coloque ajuda nos dois pontos em que mais gente empaca — dentro do produto, naquela tela, específica para a situação do usuário. Se você não tem uma camada de orientação, um aviso contextual que abre um chat com um humano é melhor do que nada.

4. Quarta semana: meça de novo. A conclusão do segundo fluxo é o número que importa; todo o resto é só um indicador indireto.

O primeiro fluxo de trabalho coloca o usuário para dentro do prédio. O segundo decide se ele fica. Instrumente esse fluxo, ponha gente cuidando dele e pare de se parabenizar por um funil que termina na porta.

O Barkan vê a tela do usuário, mostra o próximo passo com um cursor ao vivo e fala primeiro quando uma conta empaca. Uma tag de script, US$ 25 em créditos, sem cartão.

“A maioria dos usuários não quer mais uma resposta. Quer que mostrem o caminho, ou quer a tarefa pronta. O produto inteiro é isso.” 

Gabriel Lancelot

Cofundador, Barkan

Gabriel Lancelot, cofundador do Barkan