Use este artigo para diagnosticar por que um Workflow não está funcionando como esperado. Ele cobre as causas mais comuns: configurações do Messenger e automação, incompatibilidades de gatilho e público, conflitos de prioridade de workflow, ações e timing de colegas, configuração de canal, conflitos com Fin AI Agent e falhas em workflows de fechamento automático.
Este artigo é para colegas que constroem e gerenciam Workflows no Intercom. Você precisará de acesso ao construtor de Workflows para aplicar qualquer uma das correções descritas aqui.
Lista de Verificação para Solução de Problemas
Antes de começar, revise rapidamente estas áreas-chave onde problemas ocorrem com frequência:
Configurações Fundamentais: O Messenger está ativo e os Workflows estão habilitados para o público correto?
Regras e Gatilhos: As condições para seu público, canais e gatilhos estão configuradas exatamente como pretendido?
Prioridade do Workflow: Um workflow diferente e mais geral está rodando em vez do que você espera?
Timing e Ações do Colega: A resposta, agendamento ou horário de expediente de um colega impediu o workflow de rodar?
Condições Avançadas: Pontos de dados específicos, como status do Ticket, estão correspondendo perfeitamente?
Ferramenta de Solução de Problemas de Workflow
Use a Ferramenta de Solução de Problemas de Workflow para identificar condições incompatíveis. Se a ferramenta identificar uma condição incompatível, atualize a regra de gatilho relevante, a configuração do público ou o atributo de dados no seu workflow para corresponder ao estado esperado, e então teste novamente na mesma conversa para confirmar que o problema foi resolvido.
Navegue até a visão geral dos Workflows.
Clique em “Troubleshoot” e cole a URL da conversa.
Revise os resultados para ver quais condições corresponderam e quais não — a ferramenta destaca qualquer regra que esteja bloqueando o acionamento do workflow.
Por que meu Messenger não está acionando o workflow?
Antes de verificar o workflow em si, certifique-se de que as configurações do Messenger e da automação estão corretamente configuradas para permitir o início das conversas.
Configurações de Conversa de Entrada
Controlar o volume de conversas de entrada é uma configuração do Messenger que pode ser ajustada para limitar quem tem a capacidade de iniciar uma conversa. Como isso pode impedir que clientes iniciem uma conversa, Workflows com um gatilho baseado em conversa (ex.: “Customer opens a new conversation in the Messenger”, “Customer sends their first message”, “Customer sends any message”) nunca serão acionados para esses clientes.
Messenger Desativado
Mostrar o Lançador do Messenger é uma configuração do Messenger que pode ser ajustada para ocultar o Messenger dos clientes. Se o Messenger estiver oculto dos clientes, qualquer Workflow que envolva uma interação com o Messenger (ex.: “When a customer visits your site”, “When a customer clicks on a website element”, “When a customer opens the Messenger”) nunca será acionado para esses clientes.
Noções Básicas de Automação
Se você ativou avaliações de conversa nas suas configurações de automações simples para Leads e Users, isso pode atrapalhar os gatilhos de inatividade funcionando como deveriam. Pode ser interrompido de forma não intencional, bloqueando outros Workflows voltados para o cliente de serem acionados.
Para evitar esse problema, use a seguinte solução alternativa:
Em vez de enviar a avaliação da conversa pelas configurações básicas, você deve criar um Workflow para enviar essas avaliações. Isso evitará o problema daqui para frente.
Por que o tipo de gatilho correto não está acionando?
Incompatibilidades de gatilhos de email e outbound
Tipos específicos de gatilho, como "Customer sends their first message" ou "Customer sends any message", determinam quais workflows serão ativados. Por exemplo, "Customer sends their first message" dispara uma vez por conversa, enquanto "Customer sends any message" dispara para cada mensagem subsequente. Essa compreensão é essencial para estruturar workflows de forma eficaz, sem sobreposições inesperadas. O gatilho que você escolhe para seu workflow e como configura as configurações do gatilho decidirão quem/o que pode corresponder ao workflow e se ele será acionado. Por exemplo, usar um gatilho "When a ticket is created" para tickets criados via API do Intercom (Application Programming Interface) pode não incluir uma mensagem iniciada pelo cliente, o que pode impedir o acionamento do workflow.
Filtros de conteúdo de mensagem
Se seu workflow não está acionando para ações específicas, verifique incompatibilidades nos seus critérios-alvo. Por exemplo, se um workflow não dispara para um email específico, verifique se as condições de email nas configurações do gatilho estão corretas. Para rotear emails de entrada de forma eficaz, use o gatilho "Customer Sends First Message" e filtre por atributos de email em vez de usar filtros de email. Lembre-se também que workflows outbound, como "Customer visits a page", são projetados para gatilhos específicos e normalmente não estão ligados ao início da conversa.
Se seu workflow usa filtros de conteúdo de mensagem, verifique se eles não são muito restritivos. Usar "Message content is" requer uma correspondência exata, enquanto "Message content contains" é mais flexível e aumenta as taxas de sucesso do gatilho.
Incompatibilidades de tipo de perfil (Users, Leads e Visitors)
Ao configurar gatilhos de workflow, verifique se a configuração do seu público corresponde à sua intenção. Se um workflow estiver configurado para atingir apenas 'Users', ele não será acionado para conversas iniciadas por 'Leads'. Para garantir a ativação correta do workflow para todos os públicos pretendidos, expanda suas regras de público para incluir todos os grupos relevantes.
Ao configurar um workflow “Customer sends their first message”, note que se um visitante pela primeira vez abrir o Messenger e acionar o workflow, ele será considerado um lead depois, mas avaliado como visitante dentro do workflow, pois ele usa uma captura instantânea do perfil.
Se o Workflow só atingir Leads e User, ele não será acionado para este Visitor. Considere adicionar todos os tipos de Perfil para garantir que todos correspondam ao Workflow.
Além disso, certifique-se de que o endereço de email para o qual os clientes estão enviando mensagens esteja adequadamente definido dentro do público-alvo e das configurações de gatilho do workflow, usando filtros como 'Email to' ou 'Email recipient' para precisão. Workflows destinados a tratar emails encaminhados devem sempre verificar se o endereço de destino do encaminhamento foi configurado corretamente e se o encaminhamento automático está ativado.
Exemplo:
Você configurou um workflow com o gatilho "When customer opens a new conversation in the Messenger" e adicionou uma etapa para marcar todas essas conversas.
Um cliente responde a uma postagem que você enviou do Outbound.
Esta conversa não seria marcada porque eles não iniciaram a conversa no Messenger (eles responderam a uma mensagem outbound).
Se você quiser que todas as conversas sejam marcadas, deve usar o gatilho "When customer sends any message" em vez disso.
Você está segmentando as pessoas certas (Users vs. Leads)?
Se um workflow (por exemplo, uma resposta fora do horário) não for acionado porque ele segmenta "Users" mas a conversa é com um "Lead", sua automação não funcionará como esperado. Sempre verifique se seu workflow deve incluir tanto Users quanto Leads nas configurações de gatilho. Regras de público mal configuradas podem resultar em leads ou users não tratados.
Regras de segmentação de público podem influenciar quem será afetado por um Workflow. Se o cliente não corresponder aos critérios de público especificados, o Workflow não será acionado. Ao testar workflows, esteja ciente de que workflows configurados para "users only" podem falhar ao testar no modo anônimo ou em navegadores onde o usuário não é reconhecido (frequentemente identificado como visitante ou lead). Para testes abrangentes, atualize as configurações de público do seu workflow para incluir todos os tipos relevantes de participantes (visitors, leads e users). Por exemplo, um workflow que segmenta apenas Users não será acionado para Leads. Da mesma forma, se um workflow requer tags ou atributos específicos (ex.: uma tag como to_drop_off_detected), ele não será acionado se essas condições não forem atendidas.
Por que apenas um workflow está rodando quando vários deveriam ser acionados?
Workflows voltados para o cliente vs Workflows em segundo plano
Workflows no Intercom são categorizados como voltados para o cliente ou em segundo plano. Workflows voltados para o cliente envolvem interações visíveis, como envio de mensagens automáticas, enquanto workflows em segundo plano executam ações que não são visíveis para o cliente, como marcar conversas ou fechar threads. Importante: para um único tipo de gatilho, apenas um workflow voltado para o cliente será executado, mas todos os workflows em segundo plano correspondentes podem ser executados. Essa distinção garante que diferentes workflows possam coexistir sem conflitos. Apenas um workflow voltado para o cliente é acionado por conversa. Quando múltiplos workflows correspondem ao mesmo gatilho, o Intercom prioriza e ativa o workflow com a classificação mais alta nas configurações do workflow.
Você pode ter apenas um workflow voltado para o cliente rodando em uma conversa por vez. Ações que interromperiam um workflow voltado para o cliente e permitiriam que outro workflow voltado para o cliente fosse acionado são ações de colegas e incluem:
Abrir
Abrir e reatribuir
Enviar um comentário
Soneca
Nota: Um workflow voltado para o cliente continua ocupando seu espaço mesmo enquanto espera a resposta do cliente — não apenas durante a execução ativa das etapas. Isso significa que eventos subsequentes (como criação de ticket ou nova mensagem do cliente) não dispararão um novo workflow voltado para o cliente enquanto o primeiro permanecer ativo, mesmo que o novo evento use um tipo de gatilho completamente diferente. Por exemplo, se um workflow de Sugestão de Artigo estiver ativo e aguardando entrada em uma conversa, um workflow 'Quando um ticket é criado' não será disparado até que o primeiro workflow seja interrompido ou desativado. Para resolver isso, desative ou pause o workflow bloqueador, ou use uma ação de teammate (abrir, re-atribuir, comentar ou sonecar) para interrompê-lo.
Nota: Workflows em segundo plano são projetados para executar automações independentemente das ações dos teammates e não param quando teammates respondem ou sonecam conversas.
Após um workflow voltado para o cliente ser interrompido, outro workflow voltado para o cliente pode assumir.
Respostas a mensagens enviadas só dispararão workflows configurados para 'cliente envia sua primeira mensagem', não aqueles configurados para 'cliente abre uma nova conversa'. Essa distinção ajuda a garantir que os workflows sejam configurados corretamente para diferentes tipos de conversa. Por exemplo, um gatilho "Primeira mensagem" não será disparado para respostas a e-mails enviados, pois são tratados como continuações de conversas existentes.
Por que minha regra de público não está correspondendo aos clientes certos?
Regras de segmentação de público podem influenciar quem será afetado por um Workflow. Se o cliente não corresponder aos critérios do público especificado, o Workflow não será disparado.
Suas regras AND / OR estão funcionando como esperado?
Se seu workflow usa múltiplas condições unidas por "AND" e os resultados não são satisfatórios, considere mudar para a lógica "OR" se disparar um workflow ao cumprir qualquer uma das condições atender às suas necessidades. Para casos que exigem todas as condições cumpridas, assegure o alinhamento correto dos atributos e valores na configuração. Ao usar "regras OR" na segmentação de público, apenas uma condição precisa ser verdadeira para a regra se aplicar. Isso significa que se qualquer uma das condições individuais corresponder, o workflow será disparado, mesmo que outras condições não correspondam.
Exemplo:
Suponha que você configure uma regra de público baseada no atributo Cidade com a seguinte lógica:
"Cidade não é Dublin" OU "Cidade não é Londres".
Se um usuário estiver em Londres, a regra será avaliada da seguinte forma:
Primeiro, verifica: Cidade não é Dublin → Como o usuário está em Londres, essa condição é verdadeira.
Como uma regra "OU" requer apenas uma condição verdadeira, o workflow não verifica a segunda condição (se a cidade não é Londres). A regra já está satisfeita e o workflow prossegue.
Isso significa que usuários em Dublin ou Londres ainda podem receber a mensagem ou disparar o workflow inesperadamente.
Regras OU disparam se qualquer condição for atendida.
Regras OU negativas podem levar a correspondências indesejadas porque, uma vez que uma condição é verdadeira, as outras são ignoradas.
Use regras E quando precisar que todas as condições sejam atendidas antes de disparar o workflow.
Garanta que as condições de ramificação estejam definidas nas regras de público e não dentro de etapas específicas do workflow.
Isso garante que apenas conversas elegíveis sejam roteadas pelo workflow desde o início.
Então, se você quiser excluir usuários em Dublin e Londres, precisa mudar da lógica "OU" para a lógica "E":
"Cidade não é Dublin" E "Cidade não é Londres".
Com essa configuração:
O usuário não deve estar em Dublin e não deve estar em Londres para que o workflow seja disparado.
Se estiver em qualquer uma das cidades, a regra de público não corresponde e o workflow não é disparado.
Principais conclusões
Ao configurar regras de público para Workflows Intercom:
Regras OU disparam se qualquer condição for atendida.
Regras OU negativas podem levar a correspondências indesejadas porque, uma vez que uma condição é verdadeira, as outras são ignoradas.
Use regras E quando precisar que todas as condições sejam atendidas antes de disparar o workflow.
Dados Pessoais & Dados da Empresa
Seu Workflow pode ter gatilhos específicos baseados em dados pessoais ou da empresa — estes podem ser quaisquer atributos de dados padrão ou atributos de dados personalizados disponíveis no Intercom. Você deve verificar os critérios e condições definidos para esses gatilhos e garantir que os dados estejam corretamente inseridos e correspondam às regras definidas.
Exemplo:
Ao usar ramificações em um workflow, se estiver verificando:
"Atributo da empresa não é".
O cliente deve estar vinculado a uma empresa para atender à regra da condição e corresponder. Se não tivermos uma empresa para verificar o atributo, não assumiremos que a condição é verdadeira - em vez disso, seguiremos outro caminho.
Quando uma conversa é roteada pela lógica do workflow, o sistema usará a empresa associada ao usuário que foi atualizada mais recentemente se nenhuma empresa específica estiver definida, e as condições de ramificação usando regras OR negativas podem resultar em roteamento inesperado se não forem cuidadosamente ordenadas. Certifique-se de especificar a empresa na sessão e revisar a ordem das ramificações para garantir o roteamento correto.
Regras de público usando "Última vez ouvido de" não correspondem ao contato que acabou de enviar uma mensagem
Se seu workflow usa uma regra de público como "Última vez ouvido é desconhecido" ou "Última vez ouvido foi há mais de X dias", você pode perceber que o workflow nunca dispara para o cliente que acabou de enviar uma mensagem — mesmo que ele apareça na prévia do tamanho do público.
Esse é um comportamento esperado: quando uma mensagem recebida chega, o Intercom atualiza o carimbo de data/hora "Última vez ouvido" do contato antes da correspondência da regra de público do workflow ser executada. Quando a correspondência avalia a regra, o contato acabou de ser ouvido, então ambas as condições avaliam como falso e o workflow não dispara para o remetente.
Nota: A prévia do tamanho do público (ex: "980 pessoas no seu público") lê os valores atuais dos atributos e pode ser enganosa. A correspondência ao vivo avalia o valor após a atualização da mensagem recebida — então um contato visível na prévia pode não corresponder quando realmente escrever. Isso se aplica igualmente a todos os canais de entrada: Messenger, e-mail, SMS e outros.
Alternativas recomendadas:
Para responder a todas as mensagens recebidas independentemente do histórico do contato: remova completamente a regra "Última vez ouvido" e direcione Leads e Users no canal relevante.
Para direcionar apenas contatos novos: use "Inscrito é desconhecido." Esse atributo não é redefinido por mensagens recebidas, então não há condição de corrida.
Para reengajar contatos inativos: use "Último contato foi há mais de X dias." O atributo "Último contato" registra quando você enviou a última mensagem enviada — não é atualizado quando um cliente escreve para você, então permanece preciso no momento da correspondência.
O tempo, agendamento ou uma ação de teammate podem estar bloqueando o workflow?
Usando agendamento você pode controlar quando e por quanto tempo um Workflow está ativo. Muitas vezes, um Workflow não dispara porque os critérios para quando o Workflow está agendado não são atendidos. Fatores externos podem impedir a execução do workflow, mesmo que todas as regras estejam corretas.
Um teammate respondeu ou tomou uma ação primeiro?
Se um teammate abrir, reatribuir ou enviar um comentário em uma conversa, isso pode interromper e encerrar qualquer workflow ativo voltado para o cliente. Da mesma forma, se um workflow tiver um atraso de tempo, um teammate respondendo antes do término do atraso o cancelará. Além disso, workflows que dependem de gatilhos não responsivos podem não ativar se a última mensagem foi enviada por um bot em vez de um teammate.
Agendamento de data personalizado
O Workflow pode ter um cronograma de data personalizado — por exemplo, para disparar apenas entre a noite de sexta-feira e a manhã de sábado. Nesse caso, testar o Workflow fora desse horário não acionará o Workflow — independentemente de qual trigger for selecionado. Por exemplo, se um workflow estiver configurado para rodar aos sábados entre 00:00–08:00 GMT, ele não será acionado para eventos ocorrendo às 20:01 UTC no mesmo dia.
Horário comercial
Você pode ter configurado Office Hours para seu Workflow disparar dentro — seja Durante o horário comercial ou Fora do horário comercial. Workflows usam apenas o horário comercial padrão, não os horários personalizados definidos para equipes individuais.
Recomendamos mover as regras de horário comercial para dentro dos seus Workflows como ramos condicionais, em vez de nas configurações de trigger de um Workflow.
As configurações de trigger são avaliadas quando seu cliente interage com o Messenger, enquanto os ramos são avaliados em tempo real durante uma conversa, sendo muito melhores para lidar com condições baseadas em tempo.
Workflows não se aplicam retroativamente
Workflows só disparam em conversas que começam após o workflow ter sido criado e ativado. Se uma conversa começou antes da existência do workflow, esse workflow não se aplicará — mesmo que a conversa atenda a todas as condições do trigger. Para lidar com conversas pré-existentes, gerencie-as manualmente ou use um workflow em segundo plano que atue sobre atributos existentes da conversa.
A configuração do canal pode estar impedindo o workflow?
Se seu Workflow estiver configurado para canais específicos como Email, SMS ou redes sociais, certifique-se de que o canal está corretamente conectado e ativo. Um canal desconectado pode ser a razão pela qual um Workflow não está disparando. Além disso, garanta que as configurações do canal do workflow estejam alinhadas com a forma como os users estão interagindo — se um workflow estiver configurado para disparar apenas via "email" e o user interagir via Messenger, o workflow não será acionado. Para workflows de email, certifique-se de que o canal Email está habilitado na configuração. Sem esse canal ativo, conversas por email não dispararão os workflows respectivos. Por exemplo, um workflow direcionado aos canais Web, iOS e Android não disparará para conversas por email.
Garanta que workflows envolvendo emails tenham o canal de email corretamente configurado e ativo nas configurações de trigger. Também verifique se o Simple Deploy foi habilitado, pois ele pode sobrescrever workflows de email.
Nota:
Ao usar um workflow "Quando o customer envia sua primeira mensagem" que contém elementos voltados para o cliente, deve haver um intervalo de mais de 2 minutos entre novas conversas iniciadas pelo mesmo customer para que o workflow dispare novamente. Se o intervalo for menor que 2 minutos, o workflow não será ativado.
Para conversas inbound por email especificamente, há um caso especial: quando múltiplos emails do mesmo remetente chegam em poucos segundos, apenas o primeiro ou os dois primeiros emails são capturados pelo trigger "Customer sends their first message". Emails simultâneos subsequentes correspondem apenas ao trigger "Customer sends any message". Se conversas estiverem chegando sem atribuição e sem automação, esse comportamento em rajada pode ser a causa. Como solução alternativa, dispare manualmente um workflow reutilizável de dentro da conversa afetada usando Cmd/Ctrl + K > Trigger reusable workflow.
Como faço para impedir que o mesmo workflow dispare várias vezes?
Ao configurar workflows que respondem a mensagens de customers, você pode querer evitar que o mesmo workflow dispare várias vezes dentro de uma conversa, especialmente quando os users enviam mensagens adicionais com mais detalhes.
Solução: Use tags de conversa para controlar os triggers do workflow
Adicione uma tag específica (por exemplo, "Pricing") às conversas quando seu workflow for executado.
Configure workflows para verificar a ausência dessa tag antes de disparar.
Essa abordagem garante que cada workflow dispare apenas uma vez por conversa, evitando respostas automáticas duplicadas.
Certifique-se de que a tag referenciada no workflow seja uma tag de Conversation, pois tags de User não podem ser usadas em filtros ou workflows a nível de conversa.
Esse sistema de tags é especialmente útil para workflows disparados por condições como "Customer sends their first message" ou "Customer sends any message", onde mensagens de acompanhamento poderiam potencialmente reativar sua automação. Além disso, note que uma tag só pode ser aplicada uma vez por conversa. Se a tag já foi adicionada anteriormente, o workflow não a reaplicará.
Por que meu workflow não está disparando na URL correta da página?
Certifique-se de que o Workflow está corretamente configurado para disparar nas Page URLs corretas ou dentro dos aplicativos corretos em dispositivos iOS e Android. Configurações incorretas podem impedir o disparo do Workflow.
Melhores práticas para segmentação por URL
A segmentação por Current page URL pode ser adicionada na seção "Where to send" ou na seção principal de segmentação de Audience dentro das configurações de Trigger rule. No entanto, sua funcionalidade difere conforme a seção em que está inserida:
Audience Targeting: Configurações de URL aqui segmentam users com base na última página visitada. Esses dados podem não estar sempre atualizados, o que pode levar a disparos imprecisos dos Workflows.
Where to send: Oferece uma segmentação mais confiável baseada na página atual em que o user está. Geralmente, isso corresponde ao resultado desejado.
Nota: Usar segmentação por URL na seção Where to send desativará o bot inbound em iOS e Android, pois apps móveis não reconhecem URLs. Se a segmentação por URL for crucial, crie um bot especificamente para o web Messenger e outro para iOS e Android sem regras de URL.
Current page URL em apps de página única (SPAs)
O atributo Current page URL nas condições do workflow reflete a URL que foi rastreada quando a sessão do Messenger começou — não a página atual real do customer. Em aplicações de página única (SPAs), onde a navegação ocorre sem recarregamento completo da página, isso significa que a URL pode parecer desatualizada e pode não corresponder ao que o customer está visualizando no momento.
Nota: Essa é uma limitação conhecida de como SPAs lidam com navegação. O Messenger JS é reinicializado apenas em carregamentos completos de página, então mudanças dinâmicas de URL não são rastreadas automaticamente.
Solução alternativa: Use a Intercom Messenger JS API para enviar a URL atual como um atributo de dado personalizado sempre que a rota mudar em sua SPA. Você pode então usar esse atributo de dado personalizado como condição de URL no workflow em vez de depender do Current page URL.
Problemas de sincronização com conversas criadas via API
Workflows que dependem de condições 'Current page URL' podem falhar para conversas criadas via API. Pode haver uma diferença de tempo entre quando a URL é reportada e quando a conversa é criada via API, o que significa que a condição de URL pode não ser correspondida a tempo. Se você está criando conversas via API e dependendo de triggers baseados em URL, teste cuidadosamente ou use condições que não dependam de URL.
Condições de URL em ramos de workflow
Condições de URL dentro de ramos de workflow são avaliadas no momento da criação da conversa. Se o customer navegar para uma URL diferente após o início da conversa, a condição do ramo não será atualizada para refletir a nova URL — em vez disso, o caminho Else será seguido. Projete a lógica de ramificação com isso em mente e considere usar atributos de dados atualizados via Messenger JS API para rastreamento dinâmico de URL.
Por que 'Current page URL' não funciona para conversas do Facebook/Instagram
O filtro "Current page URL" aplica-se apenas a páginas onde o Intercom Messenger está instalado. Isso significa que ele não captura URLs para conversas que se originam em plataformas externas como Facebook, porque essas interações acontecem fora do seu site.
Para filtrar corretamente conversas de diferentes canais (por exemplo, Facebook e Instagram), você deve usar o filtro "Page URL" em vez disso. Esse filtro pode rastrear a página de referência ou fontes externas, permitindo segmentar e disparar workflows corretamente com base em onde a conversa começou.
Workflows não disparam em páginas de artigos
Se um workflow não dispara em páginas de artigos, verifique regras de exclusão de audiência que podem estar bloqueando URLs de artigos:
Outro workflow pode estar tendo prioridade sobre o meu?
Se uma conversa atender às regras para múltiplos workflows ativos, o Intercom executará apenas aquele com a maior prioridade. Você só pode ter um workflow voltado para o customer rodando em uma conversa por vez.
Outro Workflow está rodando primeiro?
Workflows são priorizados em uma lista de cima para baixo nas suas configurações. Se um workflow geral estiver no topo da lista, ele pode disparar e impedir que um workflow mais específico abaixo seja executado. Ajuste a prioridade para garantir que workflows importantes tenham precedência.
Por exemplo: Um workflow geral "Welcome" no topo da sua lista substituirá um workflow especial "VIP Clients" abaixo dele, mesmo que o customer seja VIP.
Para corrigir isso:
As configurações do Fin AI Agent podem estar bloqueando meu workflow?
O Fin AI Agent às vezes pode interagir com Workflows de maneiras que levam a comportamentos inesperados. Veja como resolver problemas comuns relacionados ao Fin em workflows:
Prioritização de Fin e Workflows com implantação simples
Quando tanto a implantação simples do Fin quanto os workflows estão ativados para o mesmo público, a implantação simples tem prioridade e somente o Fin responderá. Para permitir que os workflows sejam acionados, ajuste o direcionamento do público para que não se sobreponham ou desative a implantação simples.
Ativando CSAT para Fechamentos de Workflow do Fin
Os Workflows de Customer Satisfaction Score (CSAT) não são acionados automaticamente quando o Fin fecha uma conversa. Para garantir que as pesquisas CSAT sejam enviadas, configure-as dentro do Workflow usando a etapa "Let Fin answer". Para instruções mais detalhadas, consulte a documentação do Fin CSAT.
Usuários Sendo Perguntados Repetidamente
Workflows configurados para "Get context about issue upfront" podem fazer com que usuários sejam solicitados repetidamente pelas mesmas informações (por exemplo, nome, e-mail). Para corrigir isso, desative essa configuração em Fin AI Agent > Simple Automation > Get context about issue upfront para usuários e leads.
Implantação simples para interferência do Fin
Se a implantação simples para Fin estiver ativa, ela pode substituir seus workflows personalizados, fazendo com que os visitantes vejam implantações do Fin em vez do workflow configurado no Intercom. Se seus workflows não estiverem sendo acionados como esperado e você estiver usando Fin, tente desativar "Simple Deploy for Fin" para garantir que seus workflows possam ser acionados para usuários.
Workflow do Fin Falhando ao Processar Emails
Workflows baseados em email podem falhar se os emails não forem encaminhados corretamente do endereço designado para o Intercom. Verifique novamente a configuração de encaminhamento de email, pois erros aqui frequentemente impedem o processamento de emails. Confirme que os emails encaminhados incluem corretamente o endereço de email do destinatário pretendido dentro dos filtros do workflow. Além disso, assegure que o status de encaminhamento automático esteja definido como "ON" e que sua configuração de workflow de email acomode totalmente os emails recebidos dos endereços de encaminhamento designados. Se os emails não acionarem workflows, verifique se o endereço de email correto foi definido no workflow ou através do direcionamento do público. Adicionar o email de suporte às condições de gatilho do workflow pode ajudar a resolver esses problemas.
Encaminhamento de email e regras de workflow
Quando emails são encaminhados por meio de listas de distribuição, as condições de domain podem não coincidir, pois a conformidade DMARC (Domain-based Message Authentication, Reporting and Conformance) reescreve os cabeçalhos.
Para preservar as informações do remetente original:
Encaminhe emails via roteamento do lado do servidor (por exemplo, redirecionamento Google ou Microsoft 365), evitando listas de distribuição como Google Groups.
Prevenção de condições de corrida na avaliação de workflow
Workflows podem ser acionados erroneamente se uma reatribuição for processada após a avaliação.
Minimize esses erros:
Revise a ordem das condições para garantir que exclusões sejam aplicadas primeiro.
Teste extensivamente os workflows durante cenários de reatribuição.
Evitando classificação incorreta pelo Fin
Se o Fin estiver classificando incorretamente conversas no seu workflow do Intercom, refine as descrições dos seus atributos para melhorar a correspondência:
Escreva descrições claras e contextuais para cada atributo.
Adicione palavras-chave específicas do domain comumente associadas a frases de clientes.
Teste as descrições com conversas de exemplo.
Por que meu workflow de auto-fechamento não está funcionando como esperado?
Workflows de auto-fechamento fecham automaticamente conversas com base em gatilhos e condições específicas — como inatividade do cliente ou ações predefinidas no workflow. Eles ajudam a manter seu inbox organizado e garantem a resolução oportuna das conversas. Use esta seção se seu workflow de auto-fechamento não estiver acionando, estiver fechando conversas cedo demais ou sendo interrompido inesperadamente.
Por que meu workflow de auto-fechamento não foi acionado?
Razões comuns para falha no acionamento do workflow de auto-fechamento:
Verifique se houve interrupções durante o período relevante — um incidente ativo pode ter impedido a execução do workflow.
Garanta que as condições de gatilho correspondam ao estado da conversa. Por exemplo, se seu público incluir apenas 'Users', o workflow não será acionado para 'Leads'. Expanda suas regras de público para incluir todos os tipos de perfil relevantes.
Se seu workflow de auto-fechamento estiver rodando quando não deveria, as causas mais comuns são:
Conflito de implantação simples: Se a implantação simples do Fin (uma configuração Fin de etapa única sem lógica completa de workflow) estiver ativa para o mesmo público, ela tem prioridade e pode impedir que workflows de auto-fechamento sejam acionados. Para resolver, desative a implantação simples ou ajuste o direcionamento do público para que não se sobreponham.
Ação de colega interrompeu o workflow: Ações de colegas — como abrir, reatribuir ou comentar uma conversa — podem interromper um workflow de auto-fechamento ativo e impedir que a conversa seja fechada. Workflows que dependem de gatilhos de inatividade também podem falhar se a ação de um colega reiniciar o temporizador de inatividade.
Cooldown de 2 minutos: Workflows com ações voltadas ao cliente (como enviar uma mensagem) têm um cooldown de 2 minutos entre gatilhos para o mesmo cliente. Isso evita loops com autoresponders, mas pode impedir o auto-fechamento se uma conversa foi reaberta dentro desse período. Para garantir auto-fechamento consistente, crie workflows separados usando apenas ações de fundo não visíveis (como fechar ou marcar) em vez de etapas de mensagem voltadas ao cliente.
Por que meu workflow de auto-fechamento foi acionado inesperadamente?
Se seu workflow de auto-fechamento estiver rodando quando não deveria, as causas mais comuns são:
Revise as regras do público — especialmente condições OR, que exigem apenas que uma condição seja verdadeira. Um cliente pode corresponder ao workflow inadvertidamente se qualquer condição for verdadeira.
Verifique mudanças no estado da conversa, como tickets marcados como 'waiting_on_customer', que podem satisfazer condições de gatilho inesperadamente.
Por que as conversas estão fechando cedo demais ou não fechando?
Cada bloco Let Fin answer em um workflow tem seu próprio temporizador de auto-fechamento. Se o temporizador estiver muito curto, as conversas podem fechar antes que o cliente tenha tempo suficiente para responder. Para corrigir, clique no bloco Let Fin answer, abra as configurações de auto-fechamento e aumente a duração do temporizador.
Se as conversas nunca estiverem fechando apesar do workflow estar rodando, verifique o seguinte:
Verifique se as regras de atribuição não estão reabrindo conversas após o workflow fechá-las.
Se você desativou a opção Set expectation for human support, a caixa de seleção Auto-close abandoned workflow conversations também será desativada — ela só está disponível quando a escalada para um humano está configurada. Se o objetivo é auto-fechamento sem escalada, ajuste o workflow conforme necessário.
Combine as configurações de auto-fechamento com o tipo de gatilho do workflow para consistência — por exemplo, gatilhos baseados em inatividade precisam de um temporizador de inatividade configurado no mesmo bloco.
Auto-fechamento para workflows de email
Para workflows baseados em email, certifique-se de que as configurações de auto-fechamento estejam configuradas para acomodar emails encaminhados. Verifique se a ação de auto-fechamento está alinhada com as condições de gatilho do workflow e se os emails encaminhados incluem o endereço do destinatário pretendido para que o workflow possa correspondê-los corretamente.
Nota: Adicionar uma etapa de ação Close em um workflow reutilizável é a maneira mais confiável de garantir o fechamento ao usar fluxos ramificados complexos — não confie apenas em temporizadores de inatividade em workflows reutilizáveis.
Por que meu conector de dados está falhando em um workflow acionado por visitante?
Conectores de dados exigem um contato identificado e uma conversa ativa para funcionar. Se um conector de dados for executado imediatamente quando um workflow for acionado na visita à página, ele falhará para visitantes não identificados. Para usar um conector de dados de forma confiável em um workflow acionado por visitante:
Acione o workflow na visita à página.
Exiba uma mensagem com um botão.
Execute o conector de dados após o botão ser clicado — neste ponto, uma conversa existe e o contato pode ser identificado.
Ao verificar essas áreas e confirmar a configuração correta, você pode não apenas identificar a causa potencial para um Workflow não ser acionado, mas também garantir que ele esteja configurado corretamente para operações futuras. 👌
Se você ainda precisar de ajuda para depurar seu Workflow, entre em contato com nossa equipe de Support através do Messenger.
Nota: No Messenger móvel para iOS e Android, os cartões de artigo incorporados adicionados via etapas do Workflow não serão exibidos para os users. Para garantir que os users móveis possam acessar o conteúdo do Help Center, use texto com hiperlink ou adicione um botão de URL que vincule diretamente ao artigo.