A maioria dos times começa o kanban para “organizar o WhatsApp”. Em poucas semanas, vira um depósito de mensagens: cards abertos, nenhum sinal do que foi decidido
Quando o kanban vira “arquivo de mensagens”, os cards ficam abertos e a decisão não aparece. e follow-up sempre atrasado.
No Spark, a virada é conceitual e simples: o kanban não deve refletir fluxo de conversa. Ele deve refletir decisões. E isso começa quando cada conversa vira um card com 3 campos obrigatórios: intenção, decisão verificável e próxima ação.
Se você fizer isso direito, o follow-up deixa de depender de memória humana e passa a depender de critério.
Por que kanban vira “fila” quando não existe decisão
Quando o card guarda apenas o histórico (ou a última frase do cliente), o time perde a pergunta que manda na operação: “O que ficou combinado?”
Na prática, sem decisão verificável, você tem três problemas típicos:
- O lead volta a esfriar porque ninguém consegue comprovar o status no meio da semana.
- O atendimento em paralelo cria contradições, porque dois cards parecem “iguais”, mas não são.
- A automação e as tarefas não conseguem disparar no momento certo, porque o sistema não tem um critério de passagem.
A consequência é conhecida: follow-up vira “tentativa”, não processo.
O modelo do Spark: card com 3 campos obrigatórios
A regra é direta para o uso diário do kanban no Spark. Cada conversa que entra em avaliação vira um card com três campos.
1) Intenção: o que o cliente está tentando resolver
Intenção não é assunto solto. É uma leitura funcional do objetivo do cliente naquele momento.
Boas intenções são frases que você consegue usar para orientar resposta e ação. Exemplos:
- “Quer orçamento para instalação até sexta”
- “Está comparando planos e pediu diferenças”
- “Solicitou segunda via e tem dúvida sobre pagamento”
Intenção serve para filtrar e classificar sem depender de interpretação longa. É o que dá velocidade.
2) Decisão verificável: o que foi aceito ou confirmado
Aqui mora a diferença entre “fila” e “processo”. Decisão verificável é algo que pode ser checado.
Em vez de registrar “vamos ver” ou “talvez”, você registra um resultado confirmável, como:
- “Cliente confirmou agenda: terça 10h”
- “Cliente aprovou proposta (valor e condições enviados)”
- “Cliente recusou proposta, aguardando retorno”
- “Agendamento não confirmado, pendência de endereço”
Repare no detalhe: a decisão precisa reduzir ambiguidade. Se alguém olhar depois, sabe se avançou ou travou e por quê.
3) Próxima ação: o passo único e acionável
Próxima ação é o que deve acontecer em seguida, com começo e fim claros para virar tarefa.
Evite ações genéricas do tipo “acompanhar”. Use ações que viram trabalho objetivo:
- “Enviar link do agendamento e pedir confirmação”
- “Checar disponibilidade do técnico e responder com 2 opções”
- “Rodar atualização de proposta com ajuste solicitado”
- “Solicitar documento X e somente após enviar o passo seguinte”
Quando a ação está bem definida, o follow-up deixa de ser “voltar no chat”. Vira “cumprir uma condição”.
Como isso muda o follow-up na prática (com exemplos curtos)
A melhor forma de entender é comparar dois cenários: um sem decisão verificável e outro com o card preenchido do jeito certo.
Exemplo 1: orçamento
Sem card com decisão: o time deixa um card aberto porque “o cliente pediu valores”. O follow-up acontece quando alguém lembra. Resultado: atraso e respostas fragmentadas.
Com card do Spark:
- Intenção: “Solicitou orçamento de produto X”
- Decisão verificável: “Cliente confirmou dados para proposta (CNPJ e prazo)”
- Próxima ação: “Enviar proposta até 15h e perguntar se aprova para agendar”
Quando a proposta sai, o time passa a ter critério. Se aprovou, o card muda de estágio com base na confirmação. Se não aprovou, existe uma próxima ação definida, não uma conversa solta.
Exemplo 2: negociação com travas
Sem decisão verificável: o cliente pergunta “tem desconto?”. O time responde, mas o card não registra o que ficou acordado. O follow-up vira “mais uma mensagem”.
Com card do Spark:
- Intenção: “Cliente pediu desconto por fechamento”
- Decisão verificável: “Cliente aceitou condição com pagamento à vista”
- Próxima ação: “Enviar boleto e coletar comprovante para liberar entrega”
Aqui, o follow-up é consequência da decisão, não esforço repetido.
Exemplo 3: atendimento que depende de dados
Sem decisão verificável: “precisa de endereço” fica implícito. O lead some, porque ninguém sabe que a pendência está faltando.
Com card do Spark:
- Intenção: “Solicitou serviço e precisa concluir cadastro”
- Decisão verificável: “Pendência confirmada: endereço incompleto”
- Próxima ação: “Pedir endereço completo e confirmar CEP antes de agendar”
O sistema e o time passam a cobrar o dado certo na janela certa.
O que configurar primeiro no kanban para isso funcionar
A ideia do kanban com 3 campos parece simples, mas exige consistência operacional. Comece pelo que faz o cartão “fechar” decisão.
Defina a regra de passagem entre estágios como consequência de decisão
Se seus estágios são, por exemplo, “novo”, “em análise”, “proposta”, “agendado”, “perdido”, cada um precisa ter uma condição verificável.
Sem essa amarra, mesmo com os 3 campos, o card vira “status por sensação”. O ganho acontece quando o estágio muda por critérios.
Garanta que a próxima ação vira tarefa ou automação
O kanban não é lugar de lembrança. Ele é lugar de trabalho.
Quando a próxima ação estiver escrita como tarefa, você consegue:
- disparar tarefas automaticamente quando a decisão verificável for registrada
- manter a operação rastreável em filtros avançados
- revisar gargalos por canal, estágio e tag
Use as tags para intenção, não para nostalgia de mensagens
Tags são úteis quando representam escolhas de negócio. Se você usar tags como “o cliente escreveu sobre X”, volta ao problema da fila.
Prefira tags ligadas a intenção e situação, como “orçamento”, “comparação de planos”, “pós-venda”, “pendência de dados”.
Um recorte: por que isso é melhor que “só automatizar”
Automação ajuda quando você já sabe o critério de passagem. Sem decisão verificável no card, a IA tende a responder com contexto incompleto, porque a base do processo não está dizendo qual foi a decisão.
O que o modelo entrega é disciplina operacional: a IA apoia a conversa, mas o kanban registra decisão e direciona a próxima ação.
Resultado: follow-up consistente, menos conversa em loop e menos cards “parados”.
Takeaways
- Transforme cada conversa em card com 3 campos obrigatórios: intenção, decisão verificável e próxima ação
No Spark, cada conversa vira um card estruturado: intenção, decisão verificável e próxima ação. .
- Decisão verificável é o que pode ser checado, não o que “parece que avançou”.
- Próxima ação precisa ser acionável para virar tarefa e sustentar automações.
- Estágios do kanban devem mudar por critério, não por sensação.
Se você quer reduzir lead sumido e destravar follow-up no dia a dia, comece fazendo o kanban deixar de ser arquivo de mensagens e virar registro de decisões. Salve este guia e aplique na sua próxima triagem no WhatsApp e Instagram, com um card por conversa, do jeito que ele foi desenhado para funcionar.