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

Monitoramento e Melhoria Contínua dos Fluxos no Eddie

Para garantir que os fluxos operem corretamente, é essencial monitorar os processos da ClaudIA e do Eddie. Temos uma plataforma chamada HUB, onde todas as interações que passaram pela ClaudIA ficam registradas. No HUB, é possível visualizar os atendimentos, acompanhar fluxos chamados pelo Eddie e identificar oportunidades de melhoria, garantindo um atendimento cada vez mais eficiente e bem monitorado. 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 uma visão detalhada do fluxo das conversas, ajudando na identificação de possíveis gargalos e facilitando ações para otimização contínua. Rastreamento de Fluxo no HUB: Exemplo de conversa com a indicação do início do fluxo no Eddie e o sinalizador de retorno para a ClaudIA ao final da interação. Funcionalidades do HUB ✔ Registro completo das conversas: todas as mensagens trocadas entre os clientes e a ClaudIA ficam armazenadas para análise e auditoria. ✔ Monitoramento dos fluxos do Eddie: sempre que a ClaudIA aciona um fluxo do Eddie, o HUB exibe uma sinalização com o nome do fluxo e as mensagens trocadas dentro dele, permitindo rastrear a jornada do cliente. ✔ Indicação do fim de fluxo: quando um fluxo é finalizado, há uma sinalização de retorno para a ClaudIA, permitindo entender em que momento o atendimento voltou para a IA. ✔ Auditorias para melhoria contínua: O HUB possibilita ajustes estratégicos, como refinamento de conteúdos N1 e N2, criação de fluxos interativos e identificação de pontos de falha que impactam a experiência do cliente. ✔ Monitoramento de erros nas requisições do Eddie: Caso ocorra alguma falha em chamadas de API ou integrações dentro do Eddie, o HUB permite a identificação dessas falhas, possibilitando correções ágeis para evitar impacto no atendimento. Um bloco alto nível com um log é exibido no momento da falha para facilitar a identificação do problema. Exemplo de log no Hub: indicação de falha na requisição do Eddie O Hub é uma ferramenta essencial para garantir a eficiência, a transparência e a evolução constante do atendimento, proporcionando uma visão estratégica sobre a interação entre ClaudIA, Eddie e os clientes. Os seguintes recursos estão disponíveis para análise e otimização: 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 para Teste e Melhoria de Eddie Para garantir a qualidade e evolução contínua dos fluxos criados no Eddie, é essencial seguir um processo estruturado de testes e melhorias. Como o Eddie não possui um controle de versão nativo, as boas práticas incluem backup, testes isolados e validação antes da publicação. Construção e Modularização - Sempre que possível, divida fluxos complexos em partes menores e reutilizáveis. - Utilize chamadas entre fluxos para facilitar a manutenção e evitar retrabalho. - Certifique-se de que todas as condições (if/else) estejam corretamente preenchidas para evitar decisões incorretas. Testes Antes da Publicação - Antes de publicar qualquer alteração, duplique o fluxo e realize testes em um ambiente isolado. - Execute simulações completas, verificando a lógica de decisão, as mensagens enviadas e as integrações configuradas. - Valide os tempos de resposta observando o intervalo entre a mensagem do cliente e a resposta da ClaudIA no HUB. Isso ajuda a identificar possíveis lentidões nas requisições, mesmo sem um detalhe exato da duração. Evite requisições que possam ultrapassar o tempo limite de 45 segundos. Backup e Controle de Alterações - Como não há um 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 para evitar falhas inesperadas. - Caso seja necessário um downgrade, utilize a versão salva para restaurar rapidamente o fluxo anterior. Monitoramento e Aprimoramento Contínuo - Acompanhe a execução dos fluxos no HUB, verificando quais foram chamados e se houve falhas ou desvios inesperados. - Analise logs e mensagens de erro para identificar pontos de otimização. - Caso ocorram falhas recorrentes, ajuste as condições de decisão e fluxos alternativos para garantir um atendimento mais fluido. 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.

Última atualização em Dec 02, 2025

Como Identificar e Evitar Falhas nos Fluxos e Requisições do Eddie

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. Timeout e Cancelamento de Requisição A comunicação entre ClaudIA e Eddie precisa ser rápida e eficiente para garantir um atendimento fluido ao cliente. No entanto, existe uma limitação de tempo para a execução de cada requisição dentro do Eddie. Se esse tempo for ultrapassado, a requisição é cancelada automaticamente, interrompendo o fluxo e impedindo que o cliente receba uma resposta adequada. Como Funciona o Timeout? - Quando ClaudIA chama um fluxo do Eddie, a execução das ações dentro do fluxo deve ocorrer dentro de um tempo limite de 45 segundos. - Esse limite existe para garantir que a conversa aconteça em tempo real, sem atrasos perceptíveis para o cliente. - Se uma requisição demorar mais do que esse período, o Eddie não consegue completar a ação, resultando no cancelamento da operação e na ausência de resposta para ClaudIA. Principais Causas de Timeout e Cancelamento de Requisição APIs com Tempo de Resposta Alto - Quando um fluxo do Eddie faz uma chamada a uma API externa, o tempo de resposta pode ser muito longo, ultrapassando o limite permitido. - Algumas APIs não são otimizadas para consultas rápidas e podem demorar para processar e retornar dados. - Se a API não responder dentro dos 45 segundos, a requisição será cancelada automaticamente, prejudicando a experiência do usuário. 🔹 Como evitar: Utilize APIs que tenham tempo de resposta rápido (idealmente menos de 2-3 segundos). Priorize APIs assíncronas ou com respostas em cache para evitar atrasos. Se precisar de uma API lenta, considere dividir a requisição em partes menores ou usar soluções intermediárias (como armazenar dados temporários). Falha no Retrieval - Isso pode acontecer por erro de configuração, alterações recentes no fluxo ou falha na indexação de dados. - Para mitigar esse problema, é essencial revisar e testar regularmente os conteúdos anexados ao fluxo. Erro de Execução Interna no Eddie - O Eddie pode apresentar falhas internas que impedem a execução correta do fluxo. - Isso pode ocorrer devido a configurações incorretas, blocos mal estruturados ou uso inadequado de condições lógicas (IF/ELSE). - Para minimizar esse risco, é recomendado testar cada fluxo antes da publicação e revisar logs de erro no Hub caso ocorra. Erro na Execução de Integrações - Integrações externas (como 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. - Para mitigar esse problema, configure tratamentos de erro adequados, como: - Retornar uma mensagem explicativa para o cliente. - Escalar o atendimento para um agente humano (N2). 5. Fluxo Incorreto de Execução - Em fluxos que utilizam LLMs (Modelos de Linguagem como GPT) para definir a rota de execução, 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 dentro do fluxo não estão bem definidas. - Para evitar esse tipo de erro: - 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 na conversa, existe uma feature de segurança que escala automaticamente a conversa para N2. - Essa escalabilidade garante que, mesmo em um cenário de falha geral, o atendimento ao cliente não seja interrompido.

Última atualização em Dec 02, 2025

Transforme seu Google Sheets em uma API

Essa 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 diretamente via requisições HTTP. É perfeito para gerenciar dados de vários clientes sem precisar de servidores complexos – tudo rodando no Google Apps Script de graça! Vamos do básico ao avançado, com passos detalhados. Se você seguir à risca, em 5 minutos terá sua API no ar. Você pode adaptar para suas necessidades, como gerenciar integrações para diferentes clientes. Com essa API, você ou seus sistemas podem: - Ler todos os dados - Buscar registros específicos - Adicionar novas linhas - Atualizar linhas existentes - Deletar linhas Tudo via requisições HTTP simples (GET e POST). 1. O Código Completo da API (Copie e Cole) Aqui está o script pronto que você vai colar no Google Apps Script. Ele já está testado e funcionando perfeitamente: /** * 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 (qualquer JSON sem filter nem _method) 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); } 2. Como Configurar as Informações da Sua Planilha no Código Antes de colar o código, você precisa substituir duas partes: 1. [PLANILHA_ID] → O ID único da sua planilha Google Sheets. - 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). 2. [ABA_SHEET_NAME] → O nome da aba (guia) da planilha que você quer usar. - Na parte inferior da planilha, veja o nome da aba (padrão é "Planilha1" ou "Sheet1"). - Use exatamente o nome que aparece na aba (sensível a maiúsculas/minúsculas). - Nunca use nome de aba com acentos (` ´ ~ ^). - Exemplo: se a aba se chama "Clientes", coloque 'Clientes' Depois de substituir esses dois valores, o código está pronto para uso! 3. Abrindo o Editor de Scripts e Colando o Código 1. Na sua planilha aberta, clique no menu superior: Extensões > Apps Script. 2. No editor que abrir, apague todo o código padrão (ex: function myFunction() {}): 3. Cole o código completo da seção 1 (já com PLANILHA_ID e SHEET_NAME substituídos), clique em Salvar (disquete) e dê um nome ao projeto.: 4. Publicando como Web App (Tornando sua API pública) 1. No editor do Apps Script, 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 que aparece no final (ex: https://script.google.com/macros/s/.../exec). Essa é sua API! 5. Como Usar a API (Exemplos Práticos) Agora que sua API está publicada, você pode usá-la de qualquer ferramenta que faz requisições HTTP, como curl (no terminal), Postman ou código em qualquer linguagem. Sempre substitua SUA_URL_AQUI pela URL que você copiou no passo 4. Abaixo, explicamos cada método disponível separadamente. Para os métodos que usam POST, inclua sempre o header Content-Type: application/json. Retornar Todas as Informações (GET) Esse método retorna uma lista completa de todos os registros da planilha, como uma array de objetos JSON (cada objeto representa uma linha, com chaves baseadas nos cabeçalhos). - Como usar: Basta acessar a URL diretamente no navegador ou via GET, sem body ou parâmetros extras. - Exemplo com curl: curl "SUA_URL_AQUI" - Body necessário: Nenhum (não envie body). - Resultado esperado: Um JSON com todos os dados. Exemplo (supondo 2 linhas na planilha): { "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 } ] } } Retornar com Filtro (POST) Esse método busca e retorna apenas as linhas que correspondem exatamente ao valor especificado em uma coluna (filtro exato, não parcial). Útil para consultar dados específicos de um cliente. - Como usar: Envie uma requisição POST com o body contendo o filtro (coluna e valor). - Exemplo com curl: curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "filter": { "column": "id", "value": "1" } }' - Body necessário (formato espaçado): { "filter": { "column": "id", "value": "1" } } - Resultado esperado: Um JSON com as linhas filtradas (pode ser vazio se nada for encontrado). Exemplo: { "data": { "status": "success", "found": true, "total": 1, "data": [ { "id": "1", "nome": "João Silva", "email": "[email protected]", "saldo": 1500 } ] } } Adicionar uma Nova Linha (POST) Esse método adiciona uma nova linha à planilha com os valores fornecidos. As chaves do body devem corresponder exatamente aos cabeçalhos da planilha. - Como usar: Envie uma requisição POST com o body contendo os dados da nova linha (sem filtro ou _method). - Exemplo com curl: curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "id": "3", "nome": "Carlos Santos", "email": "[email protected]", "saldo": 5000 }' - Body necessário (formato espaçado): { "id": "3", "nome": "Carlos Santos", "email": "[email protected]", "saldo": 5000 } - Resultado esperado: Confirmação da criação com os dados adicionados. Exemplo: { "data": { "status": "success", "message": "Linha criada", "data": { "id": "3", "nome": "Carlos Santos", "email": "[email protected]", "saldo": 5000 } } } Atualizar uma Linha Existente (POST) Esse método atualiza os valores de uma linha existente, usando um filtro para identificar qual linha alterar (atualiza a primeira que corresponde exatamente). Apenas os campos enviados em "updates" são modificados. - Como usar: Envie uma requisição POST com _method: "PATCH", filtro e os campos a atualizar. - Exemplo com curl: 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 } }' - Body necessário (formato espaçado): { "_method": "PATCH", "filter": { "column": "id", "value": "3" }, "updates": { "nome": "Carlos Santos Atualizado", "saldo": 6000 } } - Resultado esperado: Confirmação da atualização com os dados da linha modificada. Exemplo: { "data": { "status": "success", "message": "Linha atualizada", "data": { "id": "3", "nome": "Carlos Santos Atualizado", "email": "[email protected]", "saldo": 6000 } } } Deletar uma Linha (POST) Esse método deleta uma linha existente, usando um filtro para identificar qual remover (deleta a primeira que corresponde exatamente). - Como usar: Envie uma requisição POST com _method: "DELETE" e o filtro. - Exemplo com curl: curl -X POST "SUA_URL_AQUI" \ -H "Content-Type: application/json" \ -d '{ "_method": "DELETE", "filter": { "column": "id", "value": "3" } }' - Body necessário (formato espaçado): { "_method": "DELETE", "filter": { "column": "id", "value": "3" } } - Resultado esperado: Confirmação da deleção com os dados da linha removida. Exemplo: { "data": { "status": "success", "message": "Linha deletada", "deletedData": { "id": "3", "nome": "Carlos Santos Atualizado", "email": "[email protected]", "saldo": 6000 } } } Pronto! Agora você tem uma API profissional rodando. Se precisar de ajuda, pode contar com o nosso time! Estamos aqui para acelerar suas integrações! 🚀

Última atualização em Dec 18, 2025

Como reduzir Erros de Chamada do Eddie para aumentar a retenção

O que são Erros de Chamada do Eddie e por que devo analisá-los? 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 em Erros de Chamada do Eddie, consulte a FAQ de Como acompanhar e aumentar a retenção da Claudia. Este guia orienta como agir imediatamente nos Erros de Chamada do Eddie que mais geram transferências, ajudando a reduzir o volume de tickets enviados para humano. ⚡ Como usar esta FAQ: 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, na aba Transferido por falha na chamada do Eddie, conforme imagem abaixo, você encontra tabelas que vão auxiliar das falhas na chamada do Eddie. Essas tabelas ajudam a identificar rapidamente onde estão os maiores impactos na retenção. Tabelas principais Tabela “% 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. Importante analisar pela última semana completa e ver quais são os maiores ofensores. Para ordenar, clique em cima do seu nome. Tabela “Tickets com Erro de Chamada por Fluxo”→ indica quais tickets estão vinculados ao fluxos do Eddie que houveram falhas. Nesta tabela é possível ordenar os fluxos por ordem alfabética para facilitar as análises e auditorias. 1. 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 ✅ Corrigir fluxos com maior percentual de erros. ✅ Criar fallback para evitar má experiência.

Última atualização em Dec 02, 2025

Validação de erros nos fluxos Eddie

Este artigo mostra os tipos mais comuns de erros que devem ser validados antes de publicar fluxos Eddie, bem como indica como identificá-los e corrigi-los. Adotar essas boas práticas ajuda a garantir que o fluxo funcione de forma coesa, que todos os caminhos estejam cobertos e que 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. 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.). 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 de ClaudIA, desde que não haja nenhum bloco de Input posicionado entre eles. 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. Links Quebrados Indica que algum bloco de link aponta para um fluxo que não existe mais ou ainda não foi publicado. Esse aviso pode ser ignorado durante a construção do fluxo, mas é fundamental que seja resolvido no momento da publicação. 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. 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. Conclusão 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 Cláudia. 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.

Última atualização em Dec 02, 2025