```html
💡 Dica: Antes de começar, lembre-se de que um Cortex é um único assistente. Os nós não são assistentes distintos, mas etapas de uma mesma conversa. Ao passar de um nó para outro, o assistente mantém a memória de tudo o que foi conversado; apenas muda seu objetivo naquele momento específico.
🌳 Passo 1: Pense a estrutura
Antes de escrever qualquer instrução na plataforma, faça um esboço em papel (ou em um quadro virtual) respondendo a duas perguntas-chave:
🙋 O que o cliente pode querer? (Ex. pedir informações, agendar uma consulta ou falar com uma pessoa).
🏁 De que formas a conversa pode terminar? (Ex. com uma consulta agendada, com a dúvida resolvida ou encaminhada para um agente humano).
Com essas respostas, monte sua estrutura visual como se fosse uma árvore de decisões.
Aplique sempre estas três regras simples:
Crie um nó novo apenas quando muda o objetivo: Responder dúvidas e agendar uma consulta são objetivos distintos; saudar e fazer a primeira pergunta não são.
Não conecte entre si os nós que saem da mesma origem: Se seus nós de "Informação" e "Agendamento" nascem da "Boas-vindas", já podem fazer transição entre si automaticamente conforme o contexto. Se você forçar uma conexão manual entre eles, o assistente pode pular a coleta de dados obrigatórios.
Cada nó precisa de pelo menos uma saída: Seja para outro nó ou para um ramo de saída final. Se um nó não tiver vias de escape, a conversa ficará presa.
💡 Dica: A regra de ouro: Se você não conseguir explicar em uma única frase a diferença entre dois nós, eles provavelmente devem ser fundidos em um único.
🎯 Passo 2: Defina cada nó
🧬 Primeiro: A identidade (Configuração Global)
No System Prompt da Configuração Global ⚙️, escreva quem é o assistente, qual empresa representa, seu tom, seu idioma e quais restrições tem (o que não deve fazer). Essa identidade aplica a toda a conversa, portanto não desperdice espaço repetindo-a em cada nó individual.
✍️ O objetivo do nó (Conversation Goal)
Deve ser curto e concreto. Explique o que o assistente deve alcançar naquela etapa e em que momento se considera que terminou. Três ou quatro linhas são suficientes.
✅ Assim se faz: "Descubra qual serviço o cliente precisa e se já nos visitou antes. Faça uma pergunta de cada vez. Quando tiver ambos os dados, continue."
❌ Evite isto: "Ajude o cliente com o que precisar." (É muito geral e a IA não saberá quando cumpriu sua meta).
🔀 Quando passar para outro nó (Transições)
Cada conexão entre nós tem uma condição. Sempre a escreva descrevendo algo que o cliente disse ou fez:
✅ Correto: "O cliente confirmou que quer agendar uma consulta."
✅ Correto: "O cliente pediu explicitamente para falar com uma pessoa."
❌ Incorreto: "Ir para agendamento." (É uma ordem para o sistema, não uma ação do cliente).
❌ Incorreto: "Se está interessado." (É ambíguo e quase sempre se cumprirá).
⚠️ Importante: Cuide para que duas condições de transição não possam ser verdadeiras ao mesmo tempo; se isto ocorrer, o assistente escolherá a rota aleatoriamente.
🛠️ Ferramentas (Tools)
Adicione apenas as ferramentas que o nó realmente precisa. Quanto mais ferramentas tiver habilitadas ao mesmo tempo, mais propenso estará a se confundir.
Escreva uma descrição muito clara do que a ferramenta faz e exatamente quando deve ser usada.
No objetivo do nó, mencione-a usando seu nome exato com o formato
@[NomeFerramenta]e explique o que fazer com a resposta. Ex: "Consulte @[VerificarEstoque] antes de prometer disponibilidade. Se não houver estoque, ofereça as alternativas."
🔘 Formatos interativos (Botões, Listas, Carrosséis)
Use-os exclusivamente quando o cliente deve escolher entre opções fechadas.
Formato | Ideal para | Limite Técnico Rigoroso |
🔘 Botões | Escolher entre 2 ou 3 opções rápidas | Máximo 3 botões (20 caracteres c/u) |
📋 Lista | Abrir um menu de múltiplas opções | Máximo 10 linhas |
🎠 Carrossel | Mostrar produtos, serviços ou horários visualmente | Máximo 10 cartões |
⚠️ Importante: Se ultrapassar o limite de elementos configurados, o que exceder se perderá sem aviso prévio ao ser enviado para WhatsApp. Sempre indique em seu Prompt quando usar o formato e finalize com a instrução: "Em qualquer outro caso, responda com texto."
📚 Documentos (Base de Conhecimento)
Anexe a cada nó apenas os documentos que precisa consultar naquela etapa específica. Preencher um nó com PDFs desnecessários não melhora as respostas, piora por saturação de contexto.
🏁 Passo 3: Defina os ramos de saída
Os ramos de saída representam as formas definitivas em que a interação com Cortex pode terminar.
🏷️ Nomeie por ação: O nome deve refletir o que aconteceu no chat, não o que o sistema deve fazer depois. (Ex: ✅
consulta_agendada| ❌enviar_confirmacao).🟢🟡🔴 Cubra sempre os 3 cenários: Certifique-se de ter ramos para quando tudo correu bem, quando o cliente rejeitou a oferta/serviço, ou quando solicitou ajuda humana.
🔗 Conexão vital: Cada ramo de saída que criar aqui aparecerá depois em Flowbuilder e deverá ser conectado a um bloco de ação. Se já existe um ramo que funciona, reutilize-o.
💡 Dica: O Cortex não atribui conversas aos assessores humanos diretamente. Seu papel é avisar ao cliente que alguém de sua equipe assumirá seu caso e então enviar a conversa por um ramo (ex. requer_humano). A atribuição à caixa de entrada se configura posteriormente em Flowbuilder, vinculando esse ramo a um bloco de atribuição.
⚠️ Importante: O que acontece se o cliente deixar de responder? A falta de resposta não é um ramo de saída. Isso é gerenciado com a ferramenta de recuperação por inatividade. Se o cliente ignorar os lembretes, Flowbuilder fechará a conversa automaticamente pela sua própria saída de inatividade.
📥 Passo 4: Colete informações (Campos e Variáveis)
A regra de ouro da coleta de dados é: Nem tudo o que o cliente diz precisa ser guardado em um campo. O assistente já recorda toda a conversa por padrão.
Use este guia para decidir qual ferramenta de armazenamento utilizar:
Seu objetivo operacional | Ferramenta a utilizar |
Que o assistente recorde o que o cliente disse | Nada. O modelo já recorda. |
Exigir um dado obrigatório antes de avançar | 🔒 Campo no nó |
Guardar um dado passivo se aparecer na conversa | 📝 Campo em Configuração Global |
Usar um dado que o cliente já tinha em seu perfil anterior |
|
Passar um dado coletado para uma Ferramenta (API) | 🔧 Parâmetro da ferramenta ( |
🔒 Campo no nó (Obrigatório): O assistente não avançará até obtê-lo. Use apenas para dados críticos sem os quais a operação não pode continuar (ex. CPF ou Email).
📝 Campo em Configuração Global (Passivo): Ao terminar a conversa, o sistema o salva se o cliente o mencionou organicamente, mas não bloqueia o fluxo para exigi-lo.
💡 Dica: Dúvida sobre qual usar? Faça a si mesmo esta pergunta: Se o cliente se recusar a dar este dado, a conversa deveria ser completamente bloqueada? Se a resposta for Sim, use um campo no nó. Se for Não, use a Configuração Global.
Considerações técnicas:
O uso de
/{campo}no prompt apenas lê informações que já existiam na base de dados do Atom antes de iniciar o chat. Não serve para guardar dados novos.Para enviar um dado para uma ferramenta (API), use parâmetros. Em uma HTTP Tool se injeta como
{{variavel}}, e o assistente o completará inteligentemente com o que o cliente disse sem fazer perguntas redundantes.
📊 Passo 5: Qualifique leads com Etapas, Tipificações e Tags
Além de conversar, um Cortex pode auditar a interação e deixar registrado em que estado cada cliente ficou. Isso é vital para que sua equipe de vendas saiba quem ligar sem ter que ler o histórico completo.
O que é | Quantas podem ser aplicadas por chat | Exemplo prático |
📊 Etapa (Stage) | Múltiplas (Todas as que alcançou em ordem) | Lead novo → Qualificado → Consulta agendada |
📌 Tipificação | Apenas uma (Aplica a última que foi cumprida) |
|
🏷️ Tag (Etiqueta) | Múltiplas (Todas as que se aplicarem ao contexto) |
|
💡 Dica: Toda essa categorização se configura na Configuração Global ⚙️. Quando o chat finaliza, o motor de IA lê o histórico e decide quais classificações correspondem. Não é necessário (nem funciona) pedir ao assistente dentro do Prompt.
✍️ Escreva boas condições de qualificação
Assim como nas transições, a condição de qualificação deve descrever algo factual que aconteceu:
✅ Correto: "O cliente confirmou uma consulta com data e hora."
❌ Incorreto: "Marcar como agendado." (É uma ordem para o sistema).
❌ Incorreto: "Cliente interessado." (É subjetivo e ambíguo).
🧭 Exemplo: Qualifique um lead em 4 passos
Defina seus critérios comerciais: Ex. Que produto precisa, para quando e seu orçamento.
Crie o nó de Qualificação: Atribua um objetivo simples: "Descubra o que o cliente precisa, para quando o precisa e qual é seu orçamento aproximado. Faça uma pergunta de cada vez. Quando tiver os três dados, continue."
Conecte suas saídas:
Para o nó Agendamento: "O cliente atende aos critérios e aceitou avançar."
Para o ramo de saída
nao_qualifica: "O orçamento ou o prazo do cliente estão fora do que a empresa oferece."
Configure o registro na Configuração Global: Mapeie as condições para que o sistema atribua automaticamente as etapas, tipificações e campos se forem detectados no texto.
⚠️ Importante sobre as validações:
As tipificações não devem sobrepor-se uma à outra. Se várias condições se cumprem simultaneamente, o sistema apenas aplicará a última da lista.
As Etapas, Tipificações e Tags devem estar previamente criadas na configuração geral de sua conta do Atom para poder selecioná-las em Cortex.
Certifique-se de configurar as Etapas no funil correto (Venda ou Serviço); caso contrário, não serão registradas.
💡 Dicas Extras para seu Cortex
🚫 Não exija ações fora do Prompt: O assistente não tem controle físico sobre a plataforma. Instruções como "guarde o email no campo X", "busque no PDF de preços" ou "passe para o nó de Agendamento" serão ignoradas. Tudo isto se consegue vinculando corretamente campos, documentos e condições de transição na interface.
🕐 Configure seu fuso horário: Use formatos padrão internacionais (ex.
America/Sao_PauloouAmerica/Argentina/Buenos_Aires). Evite abreviações como GMT-3. Se não configurar, o cérebro da IA operará em horário UTC e agendamentos como "amanhã às 3 da tarde" terão erros.💬 Domine as mensagens de inatividade: Um cliente inativo pode ter esquecido sobre o que conversavam. Sua mensagem de recuperação deve dar contexto e uma saída elegante: "Oi de novo. Eu escrevia sobre a consulta que estávamos agendando. Você ainda se interessa? Se preferir, retomamos outro dia." Fuja de mensagens robóticas como "Você ainda está aí?".
🧪 Teste como um cliente real:
Teste o fluxo perfeito, mas também tente quebrá-lo: escreva apenas "oi", recuse-se a dar um dado crítico, ou peça um humano imediatamente.
Explore pelo menos uma vez cada ramo de saída.
Revise o Rastreamento da simulação. Ali verá exatamente a lógica da IA, por quais nós passou e quais ferramentas consumiu.
(Nota: Os testes no simulador não guardam dados em perfis reais, apenas mostram o que seria guardado).
📞 Peça dados no momento certo: Exigir um número de telefone antes de responder uma dúvida básica dispara a taxa de abandono. Peça-o apenas quando houver um valor real em troca (ex. para coordenar uma ligação ou enviar uma cotação formal).
✅ Checklist antes de publicar
Antes de lançar seu Cortex em produção, certifique-se de marcar todas essas caixas:
[ ] A identidade da empresa está definida uma única vez (no System Prompt global).
[ ] A estrutura lógica é uma árvore e cada nó tem uma saída válida.
[ ] Cada nó possui um objetivo curto, claro e acionável.
[ ] As condições de transição descrevem ações do cliente e não se sobrepõem nem se pisam mutuamente.
[ ] Cada nó tem estritamente as ferramentas e documentos que precisa atribuídos (sem enchimento).
[ ] Os formatos interativos (botões e listas) respeitam os limites de caracteres e linhas do WhatsApp.
[ ] Existem ramos de saída claros para sucesso, rejeição comercial e escalonamento para um humano.
[ ] Os ramos de saída estão corretamente vinculados a um bloco de ação em Flowbuilder.