Principal Boas práticas na construção de Eddies
📐

Boas práticas na construção de Eddies

Winderlly
Róger Lenhart
Por Winderlly and 2 outros
7 artigos

Como monitorar e melhorar continuamente os fluxos do Eddie via Hub

Quando usar - Você precisa auditar fluxos Eddie em produção e identificar gargalos - Você quer rastrear quando um Eddie é chamado, o que aconteceu durante a execução, e quando o fluxo terminou - Você quer estabelecer um processo seguro de teste e melhoria dos fluxos antes de publicar Pré-requisitos - Acesso ao Hub do projeto ClaudIA - Pelo menos um fluxo Eddie publicado e ativo Sobre este artigo Para garantir que os fluxos operem corretamente, é essencial monitorar os processos da ClaudIA e do Eddie. O Hub centraliza todos os atendimentos que passam pela ClaudIA — incluindo fluxos chamados pelo Eddie — e permite identificar oportunidades de melhoria. Visão geral do HUB Visão geral do Hub: tela principal exibindo o histórico de conversas da ClaudIA O Hub funciona como um painel central que permite auditar, analisar e aprimorar o atendimento ao cliente. Ele oferece visão detalhada do fluxo das conversas, ajudando a identificar gargalos e facilitando a otimização contínua. Rastreamento de Fluxo no HUB Rastreamento de fluxo: exemplo de conversa com indicação do início do fluxo no Eddie e o sinalizador de retorno para a ClaudIA ao final. Funcionalidades do Hub - Registro completo das conversas — todas as mensagens trocadas entre clientes e a ClaudIA ficam armazenadas para análise e auditoria - Monitoramento dos fluxos do Eddie — sempre que a ClaudIA aciona um fluxo, o Hub exibe sinalização com o nome do fluxo e as mensagens trocadas, permitindo rastrear a jornada do cliente - Indicação do fim de fluxo — quando um fluxo é finalizado, há sinalização de retorno para a ClaudIA, mostrando o momento em que a IA reassumiu o atendimento - Auditorias para melhoria contínua — possibilita ajustes estratégicos: refinamento de conteúdos N1/N2, criação de fluxos interativos, identificação de pontos de falha - Monitoramento de erros nas requisições — falhas em chamadas de API ou integrações aparecem como bloco de log no momento exato em que ocorreram, facilitando o diagnóstico Exemplo de log no Hub Exemplo de log no Hub: indicação de falha na requisição do Eddie Identificação do momento de chamada do Eddie - No Hub é possível visualizar exatamente quando um Eddie foi chamado dentro de uma conversa - O início e o término do fluxo são registrados, permitindo rastreamento claro do que aconteceu durante a execução Processo sugerido de teste e melhoria Para garantir qualidade e evolução contínua dos fluxos Eddie, siga um processo estruturado. Como o Eddie não tem controle de versão nativo, as boas práticas envolvem backup, testes isolados e validação antes da publicação. Construção e modularização - Divida fluxos complexos em partes menores e reutilizáveis sempre que possível - Use chamadas entre fluxos para facilitar manutenção e evitar retrabalho - Certifique-se de que todas as condições (if/else) estejam corretamente preenchidas Testes antes da publicação - Antes de publicar qualquer alteração, duplique o fluxo e teste em ambiente isolado - Execute simulações completas: lógica de decisão, mensagens enviadas, integrações configuradas - Valide os tempos de resposta observando o intervalo entre mensagem do cliente e resposta da ClaudIA no Hub. Isso ajuda a identificar lentidões nas requisições :::error Evite requisições que possam ultrapassar o tempo limite de 45 segundos. Após esse limite, a requisição é cancelada automaticamente. ::: Backup e controle de alterações :::warning Como não há sistema nativo de versionamento: - Baixe uma cópia do fluxo antes de qualquer modificação - Publique apenas após todas as alterações estarem validadas - Se precisar fazer downgrade, use a versão salva para restaurar rapidamente ::: Monitoramento e aprimoramento contínuo - Acompanhe a execução dos fluxos no Hub, verificando quais foram chamados e se houve falhas - Analise logs e mensagens de erro para identificar pontos de otimização - Em casos de falhas recorrentes, ajuste condições de decisão e fluxos alternativos :::success Esse processo estruturado minimiza erros, otimiza o desempenho do Eddie e melhora a experiência do cliente, garantindo que cada fluxo funcione da melhor forma possível. ::: Observações - Para evitar falhas comuns: Como identificar e evitar falhas nos fluxos e requisições do Eddie - Para reduzir erros e aumentar retenção: Como reduzir erros de chamada do Eddie para aumentar a retenção - Para validações automáticas no editor: Validação de erros nos fluxos Eddie

Última atualização em May 21, 2026

Como identificar e evitar falhas nos fluxos e requisições do Eddie

Quando usar - Você está construindo um fluxo Eddie e quer conhecer os modos de falha mais comuns - Você teve um timeout ou cancelamento de requisição e quer entender por que - Você quer mitigar falhas com fallback adequado e tratamento de erros Pré-requisitos - Acesso ao Hub do projeto ClaudIA para investigação de logs - Conhecimento básico de construção de fluxos no Eddie Sobre este artigo Para garantir um atendimento eficiente e fluido, é essencial entender os principais modos de falha que podem ocorrer nos fluxos do Eddie e na comunicação entre Eddie e ClaudIA. Identificar e mitigar essas falhas permite aprimorar a experiência do cliente e evitar interrupções indesejadas. Detalhes Timeout e cancelamento de requisição A comunicação entre ClaudIA e Eddie precisa ser rápida e eficiente para garantir um atendimento fluido. Existe uma limitação de tempo para a execução de cada requisição. Se esse tempo for ultrapassado, a requisição é cancelada automaticamente, interrompendo o fluxo. Como funciona o timeout - Quando a ClaudIA chama um fluxo do Eddie, a execução das ações dentro do fluxo deve ocorrer em até 45 segundos - Esse limite existe para garantir que a conversa aconteça em tempo real, sem atrasos perceptíveis - Se uma requisição demorar mais, o Eddie não consegue completar a ação — a operação é cancelada e a ClaudIA fica sem resposta :::error Limite duro: 45 segundos por requisição. Acima disso, cancelamento automático. ::: Principais causas de timeout e cancelamento 1. APIs com tempo de resposta alto Quando o fluxo faz uma chamada a uma API externa, o tempo de resposta pode ultrapassar o limite. Algumas APIs não são otimizadas para consultas rápidas. Como evitar: :::success - Use APIs com tempo de resposta rápido (idealmente menos de 2-3 segundos) - Priorize APIs assíncronas ou com respostas em cache - Para APIs lentas, divida a requisição em partes menores ou use soluções intermediárias (como armazenar dados temporários) ::: 2. Falha no retrieval Pode acontecer por erro de configuração, alterações recentes no fluxo ou falha na indexação de dados. Como mitigar: revise e teste regularmente os conteúdos anexados ao fluxo. 3. Erro de execução interna no Eddie O Eddie pode apresentar falhas internas que impedem a execução correta. Causas comuns: - Configurações incorretas - Blocos mal estruturados - Uso inadequado de condições lógicas (IF/ELSE) Como mitigar: - Teste cada fluxo antes da publicação - Revise os logs de erro no Hub quando ocorrer 4. Erro na execução de integrações Integrações externas (chamadas de API, Google Sheets) podem retornar mensagens de erro ou falhar completamente. Quando isso acontece, o Eddie pode seguir um caminho incorreto ou não responder ao cliente. Como mitigar: configure tratamentos de erro adequados: - Retornar uma mensagem explicativa para o cliente - Escalar o atendimento para um agente humano (N2) 5. Fluxo incorreto de execução Em fluxos que usam LLMs (GPT) para definir a rota, pode haver falhas na escolha do próximo passo. Isso ocorre quando a interpretação do modelo leva a um caminho inesperado ou quando as condições não estão bem definidas. Como evitar: - Defina prompts claros e bem estruturados - Configure respostas condicionais para diferentes cenários - Teste variações do fluxo para garantir previsibilidade Falha total do Eddie Em casos extremos, o Eddie pode falhar completamente, impedindo a continuidade do fluxo. Para evitar que o cliente fique preso, existe uma feature de segurança que escala automaticamente a conversa para N2. :::success Mesmo em cenário de falha geral, o atendimento ao cliente não é interrompido — a feature de fallback garante a continuidade via N2. ::: Fallback automático Observações - Para monitorar fluxos via Hub: Como monitorar e melhorar continuamente os fluxos do Eddie via Hub - Para reduzir erros e aumentar retenção: Como reduzir erros de chamada do Eddie para aumentar a retenção - Para validar fluxos antes de publicar: Validação de erros nos fluxos Eddie - Para evitar loop infinito no mesmo fluxo: O que é o Eddie Repeat Handover e como usar

Última atualização em May 21, 2026

Como evitar mensagens concatenadas no início de um fluxo Eddie

Quando usar - Você criou um fluxo Eddie que começa com várias bubbles em sequência e elas chegam todas grudadas ao cliente - Você quer entender por que isso acontece e qual é o workaround disponível - Você quer ser avisado quando a correção for publicada Pré-requisitos - Workspace Eddie criado - Fluxo com múltiplas bubbles logo no início (sem input do cliente antes) Sobre este artigo Quando o fluxo começa com várias mensagens (bubbles) em sequência, elas são concatenadas e enviadas todas de uma vez só — sem a separação esperada. Este artigo explica por que isso acontece, quando não acontece, e o workaround atual. O problema Quando o fluxo começa com várias mensagens em sequência (bubbles), elas chegam agrupadas em uma única mensagem: Mensagens concatenadas no envio Mesmo que no Eddie elas estejam separadas: Mensagens separadas no editor Por que isso acontece? :::warning Esse é um comportamento indesejado ainda não resolvido pelo Eddie. Quando a primeira ação do fluxo é o retorno de bubbles sem uma interação anterior do cliente, o sistema agrupa tudo em uma única mensagem. ::: Quando isso não ocorre? Se houver uma interação (pedido de informação ao cliente) antes da sequência de mensagens, as bubbles são retornadas separadas, conforme o esperado: Pedido de input antes das bubbles Com a adição desse input, os bubbles seguintes são enviados de forma separada: Bubbles separadas após input Roadmap :::info Este comportamento já foi identificado pelo nosso time de tecnologia e está no roadmap para correção, mas ainda sem data definida. Se quiser ser avisado assim que a correção for publicada, é só informar o time de suporte da Cloud Humans — você é adicionado à lista de notificação. ::: Observações - Para entender boas práticas de construção de fluxo: Como usar as funcionalidades e botões básicos do Eddie - Para validações automáticas no editor: Validação de erros nos fluxos Eddie - Para evitar outros tipos de falha: Como identificar e evitar falhas nos fluxos e requisições do Eddie

Última atualização em May 21, 2026

Como configurar o Eddie Repeat Handover (limite de repetições do mesmo fluxo)

Quando usar - Você quer evitar que o cliente fique em loop chamando o mesmo Eddie várias vezes - Você quer limitar quantas vezes a ClaudIA pode repetir o mesmo fluxo antes de escalar para humano - Você precisa melhorar a experiência em casos onde o cliente reaciona o Eddie repetidamente sem resolução Pré-requisitos - Acesso de administrador ao Hub do projeto ClaudIA - Pelo menos um fluxo Eddie publicado e ativo Sobre este artigo O Eddie Repeat Handover é uma configuração que define quantas vezes a ClaudIA pode repetir o mesmo fluxo do Eddie com o cliente dentro da mesma conversa, antes de escalar para atendimento humano (N2). Garante que o cliente não fique em loop no mesmo fluxo. Passo a passo Etapa 1 — Acessar a configuração No Hub, dentro da aba Configurações: 1. Vá até a categoria Eddie 2. Ative a opção Eddie Repeat Handover 3. Preencha o campo Max Repeat Per Flow com o número máximo de repetições desejado (ex: 2) 4. Salve as alterações Configuração Eddie Repeat Handover Como funciona na prática 1. A ClaudIA chama um fluxo do Eddie 2. O cliente passa pelo fluxo e retorna para a ClaudIA 3. Se o cliente aciona novamente o mesmo fluxo, a ClaudIA pode repetir — desde que dentro do limite configurado 4. Ao ultrapassar o número definido em Max Repeat Per Flow, a ClaudIA não repete e escala o atendimento para N2 Para que serve :::success Essa funcionalidade evita que o cliente fique em loop no mesmo fluxo do Eddie e garante uma experiência mais fluida, evitando repetições desnecessárias. ::: Observações - Para evitar falhas que podem desencadear loops: Como identificar e evitar falhas nos fluxos e requisições do Eddie - Para reduzir erros e aumentar retenção: Como reduzir erros de chamada do Eddie para aumentar a retenção - Para entender as terminações de fluxo (incluindo N2): Diferença entre terminações de fluxo: End Flow, Answer Ticket, Forward to Human e Close Ticket

Última atualização em May 21, 2026

Como transformar seu Google Sheets em uma API consultável pelo Eddie

Quando usar - Você tem dados em uma planilha Google Sheets que precisa ler/criar/atualizar/deletar via HTTP - Você quer substituir uma API real por algo mais simples para casos pequenos ou MVPs - Você quer expor dados gerenciáveis por times não técnicos diretamente para o Eddie consumir Pré-requisitos - Conta Google com acesso ao Google Sheets - Planilha com cabeçalho na primeira linha e dados estruturados - Permissão para publicar Web Apps no Google Apps Script com a sua conta :::warning A aba da planilha não pode ter nome com acentos (, ´ ~ ^). Use nomes simples (ex: Clientes, Pedidos). ::: Sobre este artigo Esta solução transforma sua planilha do Google Sheets em uma API web dinâmica, permitindo que você (ou seus clientes) leiam, criem, atualizem e deletem dados via requisições HTTP. Tudo rodando no Google Apps Script gratuitamente — sem servidores complexos. Com essa API, você pode: - Ler todos os dados - Buscar registros específicos - Adicionar novas linhas - Atualizar linhas existentes - Deletar linhas Tudo via GET e POST simples. Passo a passo Etapa 1 — Copiar o código completo da API Cole o script abaixo no Google Apps Script: /** * API Planilha Google – Versão FINAL CORRIGIDA * Busca com igualdade exata (===) * Lógica de métodos corrigida */ const PLANILHA_ID = '[PLANILHA_ID]'; const SHEET_NAME = '[ABA_SHEET_NAME]'; const CACHE_TTL = 10 * 60 * 1000; // 10 minutos let cache = { data: [], headers: [], lastUpdate: 0 }; // Entradas da Web App function doGet(e) { return handleRequest(e, 'GET'); } function doPost(e) { return handleRequest(e, 'POST'); } function handleRequest(e, httpMethod) { let payload = {}; // Lê o body JSON (apenas em POST) if (httpMethod === 'POST' && e.postData && e.postData.type === 'application/json') { try { payload = JSON.parse(e.postData.contents || '{}'); } catch (err) { return jsonResponse({ status: 'error', message: 'JSON inválido no body' }); } } // Atualiza cache se necessário if (Date.now() - cache.lastUpdate > CACHE_TTL) { refreshCache(); } // Detecta método simulado (PATCH ou DELETE) const simulatedMethod = (payload._method || e.parameter.method || '').toUpperCase(); // GET → Lista tudo if (httpMethod === 'GET') { return jsonResponse({ status: 'success', total: cache.data.length, data: cache.data }); } // POST if (httpMethod === 'POST') { // PATCH simulado if (simulatedMethod === 'PATCH') { if (!payload.filter || !payload.updates) { return jsonResponse({ status: 'error', message: 'PATCH precisa de "filter" e "updates"' }); } return jsonResponse(updateRow(payload.filter.column, payload.filter.value, payload.updates)); } // DELETE simulado if (simulatedMethod === 'DELETE') { if (!payload.filter) { return jsonResponse({ status: 'error', message: 'DELETE precisa de "filter"' }); } return jsonResponse(deleteRow(payload.filter.column, payload.filter.value)); } // Busca com filtro (igualdade exata) if (payload.filter && payload.filter.column && payload.filter.value !== undefined) { const col = payload.filter.column.trim(); const val = payload.filter.value.toString(); const resultados = cache.data.filter(row => String(row[col] || '') === val ); return jsonResponse({ status: 'success', found: resultados.length > 0, total: resultados.length, data: resultados }); } // Criação de nova linha if (Object.keys(payload).length > 0) { return jsonResponse(createRow(payload)); } return jsonResponse({ status: 'error', message: 'Body vazio ou inválido para POST' }); } return jsonResponse({ status: 'error', message: 'Método HTTP não suportado' }); } // Atualiza cache function refreshCache() { const sheet = SpreadsheetApp.openById(PLANILHA_ID).getSheetByName(SHEET_NAME); const [header, ...rows] = sheet.getDataRange().getValues(); const headers = header.map(h => String(h).trim()); const data = rows.map(row => { const obj = {}; headers.forEach((h, i) => obj[h] = row[i]); return obj; }); cache = { data, headers, lastUpdate: Date.now() }; } // Cria nova linha function createRow(obj) { const sheet = SpreadsheetApp.openById(PLANILHA_ID).getSheetByName(SHEET_NAME); const headers = cache.headers; const invalidos = Object.keys(obj).filter(k => !headers.includes(k)); if (invalidos.length > 0) { return { status: 'error', message: `Campos inválidos: ${invalidos.join(', ')}` }; } const novaLinha = headers.map(h => obj[h] !== undefined ? obj[h] : ''); sheet.appendRow(novaLinha); const novoObj = {}; headers.forEach((h, i) => novoObj[h] = novaLinha[i]); cache.data.push(novoObj); return { status: 'success', message: 'Linha criada', data: novoObj }; } // Atualiza linha (primeira ocorrência) function updateRow(coluna, valor, updates) { const idx = cache.data.findIndex(row => String(row[coluna] || '') === String(valor) ); if (idx === -1) return { status: 'error', message: 'Linha não encontrada' }; const sheet = SpreadsheetApp.openById(PLANILHA_ID).getSheetByName(SHEET_NAME); const headers = cache.headers; const linha = idx + 2; Object.keys(updates).forEach(chave => { if (headers.includes(chave)) { const col = headers.indexOf(chave) + 1; sheet.getRange(linha, col).setValue(updates[chave]); cache.data[idx][chave] = updates[chave]; } }); return { status: 'success', message: 'Linha atualizada', data: cache.data[idx] }; } // Deleta linha function deleteRow(coluna, valor) { const idx = cache.data.findIndex(row => String(row[coluna] || '') === String(valor) ); if (idx === -1) return { status: 'error', message: 'Linha não encontrada' }; const sheet = SpreadsheetApp.openById(PLANILHA_ID).getSheetByName(SHEET_NAME); sheet.deleteRow(idx + 2); const deletado = cache.data.splice(idx, 1)[0]; return { status: 'success', message: 'Linha deletada', deletedData: deletado }; } // Resposta JSON function jsonResponse(obj) { return ContentService .createTextOutput(JSON.stringify({ data: obj }, null, 2)) .setMimeType(ContentService.MimeType.JSON); } Etapa 2 — Configurar as informações da planilha Antes de salvar, substitua dois valores no código: [PLANILHA_ID] — ID único da sua planilha - Abra sua planilha no navegador - Olhe a URL: https://docs.google.com/spreadsheets/d/ABC123XYZ456/edit#gid=0 - O ID é a parte entre /d/ e /edit — no exemplo, ABC123XYZ456 - Substitua [PLANILHA_ID] por esse valor (sem aspas extras) Onde encontrar o ID da planilha [ABA_SHEET_NAME] — Nome da aba da planilha - Na parte inferior da planilha, veja o nome da aba (padrão: Planilha1 ou Sheet1) - Use exatamente o nome que aparece (sensível a maiúsculas/minúsculas) - Sem acentos (evite , ´ ~ ^) Onde ver o nome da aba Etapa 3 — Abrir o editor de scripts e colar o código 1. Na planilha aberta, clique em Extensões → Apps Script Acessar Apps Script 2. Apague todo o código padrão (ex: function myFunction() {}) Apagar código padrão 3. Cole o código completo (com PLANILHA_ID e SHEET_NAME substituídos), clique em Salvar (disquete) e dê um nome ao projeto Salvar projeto Etapa 4 — Publicar como Web App 1. No editor, clique em Implantar → Nova implantação 2. Clique em Selecionar tipo → Aplicativo da web 3. Preencha: - Executar como: Eu (sua conta) - Quem tem acesso: Qualquer pessoa 4. Clique em Implantar 5. Autorize as permissões (pode pedir confirmação — clique em Avançado → Ir para o projeto → Permitir) 6. Copie a URL do aplicativo web (ex: https://script.google.com/macros/s/.../exec) — essa é a sua API URL do Web App Como usar a API (exemplos) Substitua SUA_URL_AQUI pela URL copiada na etapa 4. Para POST, sempre inclua o header Content-Type: application/json. Listar todos os dados (GET) curl "SUA_URL_AQUI" Resposta: { "data": { "status": "success", "total": 2, "data": [ { "id": "1", "nome": "João Silva", "email": "[email protected]", "saldo": 1500 }, { "id": "2", "nome": "Maria Oliveira", "email": "[email protected]", "saldo": 3200 } ] } } Buscar com filtro (POST) curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "filter": { "column": "id", "value": "1" } }' Adicionar nova linha (POST) curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "id": "3", "nome": "Carlos Santos", "email": "[email protected]", "saldo": 5000 }' Atualizar linha existente (POST com _method: PATCH) curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "_method": "PATCH", "filter": { "column": "id", "value": "3" }, "updates": { "nome": "Carlos Santos Atualizado", "saldo": 6000 } }' Deletar linha (POST com _method: DELETE) curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "_method": "DELETE", "filter": { "column": "id", "value": "3" } }' Conclusão :::success Pronto! Agora você tem uma API funcional rodando no Google Apps Script gratuitamente, pronta para ser consumida pelo Eddie via blocos HTTP Request. Se precisar de ajuda, o time de suporte da Cloud Humans está disponível para acelerar suas integrações. ::: Observações - Para conectar Eddie à API que você acabou de criar: Como criar um fluxo no Eddie com API externa - Para fluxo Eddie consumindo Google Sheets diretamente (sem API): Como criar um fluxo no Eddie acessando informações em um Google Sheets - Para boas práticas de Sheets como fonte de dados: Requisitos de Google Sheets para utilização no Eddie

Última atualização em May 21, 2026

Como reduzir erros de chamada do Eddie para aumentar a retenção

Quando usar - Você identificou no dashboard que Erros de Chamada do Eddie estão impactando a retenção da ClaudIA - Você precisa de um roteiro prático para priorizar quais fluxos corrigir primeiro - Você quer um checklist de análise para auditar fluxos com falhas recorrentes Pré-requisitos - Acesso ao dashboard de retenção da ClaudIA - Permissão para editar fluxos Eddie do projeto - (Recomendado) Ler antes: Como acompanhar e aumentar a retenção da ClaudIA Sobre este artigo Erros de Chamada do Eddie são uma das razões de transferências da ClaudIA para agentes humanos. Para validar se o foco deve ser nesses erros, consulte primeiro a FAQ de Retenção da ClaudIA. Este artigo orienta como agir imediatamente nos erros que mais geram transferência, ajudando a reduzir o volume de tickets enviados para humano. :::info Como usar este guia: leia tudo primeiro para entender os conceitos e o passo a passo. Depois, abra o dashboard para colocar as orientações em prática. ::: Por onde começar a análise Dentro do dashboard, acesse a aba Transferido por falha na chamada do Eddie. Lá você encontra tabelas que ajudam a identificar rapidamente os maiores impactos na retenção. Aba Transferido por falha Tabelas principais Tabelas principais % de Erros de Chamada do Eddie por Fluxo Mostra, para cada fluxo do Eddie, a porcentagem semanal de tickets que voltaram ao N2 porque o bot falhou. :::info Dica: analise pela última semana completa e ordene clicando no nome da coluna para ver os maiores ofensores primeiro. ::: Ordenando os maiores ofensores Tickets com Erro de Chamada por Fluxo Indica quais tickets específicos estão vinculados aos fluxos com falhas. É possível ordenar por nome do fluxo para facilitar análises e auditorias. Hora de agir Checklist de análise - As integrações/APIs estão corretas? - Dados de entrada/variáveis estão validados? - Existem condições conflitantes no fluxo? - O erro ocorre em fluxos críticos de alto volume? Sugestões práticas :::success - Corrigir fluxos com maior percentual de erros (foco em volume) - Criar fallback para evitar má experiência do cliente em casos de falha ::: Observações - Para entender as causas técnicas das falhas: Como identificar e evitar falhas nos fluxos e requisições do Eddie - Para monitorar fluxos pelo Hub: Como monitorar e melhorar continuamente os fluxos do Eddie via Hub - Para evitar loops desnecessários no mesmo fluxo: Como configurar o Eddie Repeat Handover - Para validar fluxos antes de publicar: Validação de erros nos fluxos Eddie

Última atualização em May 21, 2026

Como validar erros automaticamente nos fluxos Eddie antes de publicar

Quando usar - Você está construindo um fluxo Eddie e quer rodar a validação automática antes de publicar - Você viu um alerta no editor e quer entender o que ele significa - Você quer adotar boas práticas para que seus fluxos sejam robustos e previsíveis Pré-requisitos - Workspace Eddie com fluxo aberto no editor - Conhecimento básico dos blocos do Eddie Sobre este artigo Este artigo mostra os tipos mais comuns de erros que devem ser validados antes de publicar fluxos Eddie, bem como como identificá-los e corrigi-los. Adotar essas boas práticas ajuda a garantir que o fluxo funcione de forma coesa, todos os caminhos estejam cobertos e a experiência do usuário final seja consistente. Validação automática no editor A validação dos fluxos Eddie é executada automaticamente após cada alteração feita no editor, fornecendo feedback em tempo real sobre inconsistências e pontos de atenção. :::warning A validação não impede que o fluxo seja publicado, mas é recomendado que todos os problemas sejam revisados e resolvidos antes do fluxo entrar em produção. ::: Erros conhecidos Bloco ClaudIA ausente nas ramificações Em cada ramificação do fluxo deve haver pelo menos um bloco ClaudIA antes do final do caminho. A ClaudIA precisa dessa informação para identificar que o fluxo acabou e tomar as ações necessárias (continuar atendimento, resolver N1, escalar N2 etc.). Bloco ClaudIA ausente Texto faltando junto ao bloco ClaudIA O bloco ClaudIA existe, mas está sem nenhum texto associado. O bloco de texto pode estar posicionado antes ou depois do bloco ClaudIA, desde que não haja nenhum bloco de Input entre eles. Texto faltando Condições incompletas Avisa quando blocos condicionais (IF, ELSE) não estão devidamente preenchidos. É importante que todas as saídas do condicional estejam conectadas a algum bloco, para que o fluxo possa seguir sua execução sem erros. Condições incompletas Links quebrados Indica que algum bloco de link aponta para um fluxo que não existe mais ou ainda não foi publicado. :::info Esse aviso pode ser ignorado durante a construção do fluxo, mas é fundamental que seja resolvido no momento da publicação. ::: Links quebrados Texto ausente entre blocos de input Ocorre quando há sequências de blocos de input de texto conectadas diretamente, sem uma mensagem de texto entre eles. :::warning Para que não ocorram erros na integração com a ClaudIA, é necessário que sempre seja enviada uma mensagem antes de qualquer coleta de informações. ::: Texto ausente entre inputs Conclusão :::success Garantir que todos os fluxos Eddie sejam validados antes da publicação é essencial para assegurar uma experiência de usuário fluida, reduzir erros operacionais e manter a integridade da lógica da ClaudIA. A partir das validações e boas práticas descritas aqui, sua equipe pode construir fluxos mais robustos, previsíveis e fáceis de manter. ::: Observações - Para evitar falhas em chamadas externas: Como identificar e evitar falhas nos fluxos e requisições do Eddie - Para monitorar fluxos no Hub: Como monitorar e melhorar continuamente os fluxos do Eddie via Hub - Para reduzir erros e aumentar retenção: Como reduzir erros de chamada do Eddie para aumentar a retenção - Para entender o problema de bubbles concatenadas: Como evitar mensagens concatenadas no início de um fluxo Eddie

Última atualização em May 21, 2026