Como transformar cada resposta do onboarding em arquitetura real no Kommo — sem improvisar no meio da construção.
Existe um abismo entre o diagnóstico e a implementação. O analista faz um onboarding caprichado, enche o documento de informação — e na hora de configurar o Kommo, começa do zero, no feeling. O diagnóstico vira um papel arquivado, e o sistema sai parecido com o de todo mundo, não com o do cliente.
Cada resposta do diagnóstico é uma instrução de configuração. “Vendo para dois públicos diferentes” → dois funis. “Perco lead por demora” → automação de primeira resposta. O diagnóstico não é formalidade — é a planta da obra. Quem implementa sem consultar o diagnóstico está construindo sem planta.
Implementação rastreável, decisão por decisão, ao que o cliente disse. Quando o cliente perguntar “por que está desse jeito?”, a resposta é sempre “porque você me disse X no onboarding”.
Se o analista não consegue apontar qual resposta do cliente justifica uma etapa, um campo ou uma automação, então ou falta informação no diagnóstico, ou aquela configuração não deveria existir.
Configurar o que o cliente não pediu — o analista adiciona complexidade “porque é boa prática”, inflando o sistema e derrubando a adoção.
Esquecer o que o cliente pediu — uma dor real fica sem solução porque ninguém ligou o ponto do diagnóstico à configuração.
Cada bloco do diagnóstico se traduz em uma categoria de configuração. Os exemplos abaixo são falas reais de um onboarding da Go Up Mobi (loja de bikes elétricas).
Nem tudo cabe nessas 4 categorias. A própria Go Up Mobi trouxe dois casos especiais: o lead que diz “compro quando virar meu cartão” vira uma tarefa/lembrete manual (não automação), e os comentários de preço no Instagram pedem um funil separado pra não bagunçar as métricas. Por isso o Montador abaixo tem 6 gavetas.
O analista confia na lembrança da reunião e configura sem voltar ao documento. Detalhes se perdem, dores ficam sem solução.
O diagnóstico fica aberto ao lado durante toda a configuração; cada bloco é “dado baixa” conforme vira config.
“Vou colocar esse campo porque é útil”, “vou criar essa etapa porque outros clientes têm”. O sistema incha com coisas que ninguém vai usar, e a adoção despenca.
Toda configuração precisa de origem no diagnóstico. Sem origem, não entra.
O cliente diz “meu time não dá conta dos leads” e o analista cria um funil novo — quando o problema era distribuição e capacidade, não estrutura.
Entender a causa da dor antes de escolher a solução. A mesma frase pode apontar para automação, permissão ou processo.
Configura o sistema inteiro e só então mostra ao cliente — e descobre que entendeu errado um ponto central, tendo que refazer.
Validar os pontos críticos com o cliente durante a construção, não só no go-live.
Loja de bicicletas elétricas com assistência técnica. Leads chegam por Instagram e TikTok, todos pelo WhatsApp. As falas abaixo são reais do onboarding. Para cada uma, escolha a tradução correta para o Kommo.
-
Leia cada trecho real do onboarding da Go Up Mobi e classifique em qual gaveta da implementação ele entra. Ao final, você terá montado o blueprint completo — a planta que vira o sistema no Kommo.
-