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 dos colegas, configuração do canal, conflitos com o Fin AI Agent e falhas no fechamento automático do workflow.
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 dos Colegas: 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 do Workflow
Use a Ferramenta de Solução de Problemas do 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.
Nota: O solucionador avalia as condições em ordem e para assim que uma condição não corresponder como requerido. Isso significa que se uma condição anterior falhar, as condições restantes não serão avaliadas — apenas a primeira condição incompatível será mostrada.
Por que meu Messenger não está acionando o workflow?
Antes de verificar o workflow em si, certifique-se de que suas configurações do Messenger e automação estão configuradas corretamente 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 (por exemplo, “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 Iniciador 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 (por exemplo, “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ê tiver avaliações de conversa ativadas 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 gatilho 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ê escolher para seu workflow e como configurar as definiçõ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 publicação que você enviou pelo 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 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 do 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 exigir tags ou atributos específicos (por exemplo, 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 automatizadas, 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ê só pode ter 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 teammates 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 enquanto executa etapas ativamente. 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á acionado 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, reatribuir, comentar ou soneca) 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 colocam conversas em soneca.
Após um workflow voltado para o cliente ser interrompido, outro workflow voltado para o cliente pode assumir livremente.
Respostas a mensagens enviadas só dispararão workflows configurados para 'cliente envia a 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á acionado 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 especificados do público, o Workflow não será acionado.
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 acionar um workflow ao cumprir qualquer uma das condições atender às suas necessidades. Para casos que exigem que todas as condições sejam atendidas, garanta 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 que a regra se aplique. Isso significa que se qualquer uma das condições individuais corresponder, o workflow será acionado, 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 acionar 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 acionar 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 acionado.
Se ele estiver em qualquer uma das cidades, a regra de público não corresponderá e o workflow não será acionado.
Principais conclusões
Ao configurar regras de público para workflows no 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 acionar 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:
"O 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 que 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 de é desconhecido" ou "Última vez ouvido de é 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 de" do contato antes da correspondência do 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 falsas 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 ele 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 de" 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 é há mais de X dias." O atributo "Último contato" registra quando você enviou a última mensagem enviada — ele 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 que um workflow seja executado, 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 voltado para o cliente ativo. 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.
Conversas adiadas e gatilhos não responsivos
Para workflows que usam uma conversa adiada como condição de gatilho, a conversa deve permanecer adiada continuamente até que o cliente fique sem resposta. Se a conversa for desadiada antes desse ponto — por exemplo, por um colega ou um temporizador automático — o gatilho de inatividade não será acionado, mesmo que o cliente depois fique sem resposta.
Nota: Se uma conversa for desadiada e o cliente então ficar sem resposta, o gatilho de não resposta não será acionado novamente. Para que o gatilho funcione novamente, o cliente precisaria responder primeiro para reabrir a conversa e depois ficar sem resposta novamente enquanto a conversa permanece adiada.
Agenda de data personalizada
O Workflow pode ter uma agenda de data personalizada — por exemplo, para disparar apenas entre a noite de sexta-feira e a manhã de sábado. Nesse caso, testar o Workflow fora desses horários não acionará o Workflow — independentemente de qual gatilho 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 do mesmo dia.
Horário comercial
Você pode ter configurado Horário Comercial 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 o horário comercial personalizado definido 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 gatilho de um Workflow.
As configurações de gatilho 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 ser 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 gatilho. 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 gatilho. Também verifique se o Simple Deploy foi habilitado, pois pode substituir workflows de email.
Nota:
Ao usar um workflow "Quando o cliente 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 cliente para que o workflow dispare novamente. Se o intervalo for menor que 2 minutos, o workflow não será ativado. Essa restrição se aplica apenas a workflows voltados para o cliente — workflows em segundo plano, como marcação ou atribuição de conversas, não estão sujeitos a esse limite e ainda serão executados.
Para conversas de email recebidas especificamente, há um caso especial adicional: quando múltiplos emails do mesmo remetente chegam em poucos segundos, apenas o primeiro ou os dois primeiros emails são capturados pelo gatilho "Cliente envia sua primeira mensagem". Emails simultâneos subsequentes correspondem apenas ao gatilho "Cliente envia qualquer mensagem". Se conversas estiverem chegando sem atribuição e sem automação, esse comportamento em rajada pode ser a causa. Como solução alternativa, acione manualmente um workflow reutilizável 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 clientes, 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 gatilhos 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.
Garanta que a tag referenciada no workflow seja uma tag de Conversa, pois tags de User não podem ser usadas em filtros ou workflows a nível de conversa.
Esse sistema de marcação é particularmente útil para workflows acionados por condições como "Cliente envia sua primeira mensagem" ou "Cliente envia qualquer mensagem", 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 da página correta?
Certifique-se de que o Workflow está corretamente configurado para disparar nas URLs das páginas corretas ou dentro dos aplicativos corretos em dispositivos iOS e Android. Configurações incorretas podem impedir que o Workflow dispare.
Melhores práticas para segmentação por URL
O direcionamento por URL da página atual pode ser adicionado na seção "Para onde enviar" ou na seção principal de segmentação de público dentro das configurações de Regra de gatilho. No entanto, sua funcionalidade difere com base na seção em que estão posicionados:
Segmentação de público: 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.
Para onde enviar: Oferece um direcionamento mais confiável baseado na página real em que o user está atualmente. Isso geralmente corresponde ao resultado desejado.
Nota: Usar segmentação por URL na seção Para onde enviar desativará o bot de entrada 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.
URL da página atual em apps de página única (SPAs)
O atributo URL da página atual 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 cliente. Em aplicativos 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 cliente está visualizando no momento.
Nota: Esta é 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 API JS do Intercom Messenger para enviar a URL atual como um atributo de dados personalizado sempre que a rota mudar em seu SPA. Você pode então usar esse atributo de dados personalizado como condição de URL no workflow em vez de depender do URL da página atual.
Problemas de sincronização com conversas criadas via API
Workflows que dependem de condições de 'URL da página atual' 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 gatilhos 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 cliente 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 API JS do Messenger para rastreamento dinâmico de URL.
Por que 'URL da página atual' não funciona para conversas do Facebook/Instagram
O filtro "URL da página atual" aplica-se apenas a páginas onde o Intercom Messenger está instalado. Isso significa que 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 "URL da página" em vez disso. Esse filtro pode rastrear a página de referência ou fontes externas, permitindo segmentar e acionar 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 público 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 cliente 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 mais abaixo seja executado. Ajuste a prioridade para garantir que workflows importantes tenham precedência.
Por exemplo: Um workflow geral de "Welcome" no topo da sua lista substituirá um workflow especial de "VIP Clients" abaixo dele, mesmo que o cliente seja um 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:
Prioridade do Fin e Workflow com implantação Simple
Quando tanto a implantação Simple do Fin quanto os workflows estão ativados para o mesmo público, a implantação Simple 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 Simple.
Ativando CSAT para Fechamentos de Workflow do Fin
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 detalhadas, consulte a documentação do Fin CSAT.
CSAT enviado em conversas antigas
Pesquisas CSAT acionadas por workflows podem ser enviadas ao fechar a conversa, mesmo que a última mensagem tenha mais de 7 dias. Isso ocorre porque o limite de 7 dias sem resposta se aplica apenas ao CSAT automatizado geral do Intercom, não às pesquisas acionadas por workflows.
CSAT enviado apesar de tags de exclusão
Pesquisas CSAT ainda podem ser enviadas se as condições do workflow usarem lógica OR ou se as tags de exclusão (por exemplo, "no_csat") não fizerem parte do mesmo grupo de predicados. Para evitar isso:
Configure as condições em um único grupo de predicados usando lógica AND, garantindo que as tags de exclusão sejam avaliadas junto com as outras condições.
Problemas de direcionamento de Workflow CSAT
Workflows CSAT podem não ser acionados para certos usuários ou canais se o direcionamento for muito restrito. Por exemplo, workflows limitados a usuários logados excluirão leads. Para incluir todos os usuários:
Atualize o público do workflow para incluir tanto Users quanto Leads.
Correção passo a passo para CSAT não enviado em workflows Fin-first
Abra o workflow Fin-first no Workflow Builder.
Edite a etapa "Let Fin answer".
Ative "Ask for conversation rating (CSAT)" e especifique quando enviá-la (por exemplo, após resolução confirmada ou inatividade).
Salve e ative o workflow. Nota: CSAT de Simple Automation aplica-se apenas a conversas respondidas por humanos; workflows devem gerenciar CSAT para conversas resolvidas pelo Fin.
Usuários sendo questionados 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, email). Para corrigir, desative essa configuração em Fin AI Agent > Simple Automation > Get context about issue upfront para usuários e leads.
Prompt de captura de email não aparece no Fin para conversas de Sales
Se você configurou uma etapa de workflow para capturar o email de um lead, mas o prompt não aparece no Fin para conversas de Sales, verifique o seguinte:
Conflito "Get context about issue upfront": Se Get context about issue upfront estiver ativado em Fin AI Agent > Simple Automation para Leads, pode suprimir etapas de captura de email no Fin para workflows de Sales. Fin para Sales gerencia qualificação de leads independentemente, e os dois podem conflitar — o prompt de email pode ser pulado porque o Fin para Sales assume que coletará os dados de contato por seu próprio fluxo de qualificação. Para corrigir, desative Get context about issue upfront para Leads em Simple Automation e use uma etapa dedicada de captura de email no seu workflow.
Conflito de prioridade de workflow: Um workflow de atendimento ao cliente com prioridade maior pode estar rodando em vez do seu workflow de captura de email. Verifique a ordem de prioridade dos workflows e assegure que seu workflow Fin para Sales esteja acima de quaisquer workflows gerais de captura ou welcome que possam interceptar o mesmo público.
Lead já possui um endereço de email: Se o Intercom já tem o email do lead de uma sessão anterior, a etapa de captura de email pode ser pulada. Adicione uma regra de público para mostrar a etapa apenas quando o atributo de email for desconhecido.
Nota: Etapas de captura de email em workflows Fin para Sales devem sempre incluir um ramo alternativo para casos em que o email do lead já é conhecido — caso contrário, a etapa pode bloquear o restante do workflow para leads que retornam.
Interferência da implantação Simple para Fin
Se a implantação Simple para Fin estiver ativa, ela pode substituir seus workflows personalizados, fazendo com que visitantes vejam implantações do Fin em vez do workflow configurado no Intercom. Se seus workflows não estiverem acionando 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 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 nos filtros do workflow. Além disso, assegure que o status de encaminhamento automático esteja "ON" e que sua configuração de workflow de email acomode totalmente emails recebidos dos endereços de encaminhamento designados. Se emails não acionam workflows, verifique se o endereço de email correto foi definido no workflow ou pelo 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 listas de distribuição, 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 workflows
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 workflows extensivamente durante cenários de reatribuição.
Evitando classificação incorreta pelo Fin
Se o Fin estiver classificando incorretamente conversas no seu workflow 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 sua inbox organizada e garantem 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 pelas quais um workflow de auto-encerramento falha ao ser acionado:
Verifique se houve interrupções durante o período relevante — um incidente ativo pode ter impedido o workflow de ser executado.
Certifique-se de que as condições de acionamento correspondem ao estado da conversa. Por exemplo, se seu público inclui 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-encerramento estiver rodando quando não deveria, as causas mais comuns são:
Conflito simples de implantação: Se o Simple deployment do Fin (uma configuração Fin de etapa única sem lógica completa de workflow) estiver ativo para o mesmo público, ele terá prioridade e pode impedir que workflows de auto-encerramento sejam acionados. Para resolver isso, desative o Simple deployment ou ajuste o direcionamento do público para que os dois não se sobreponham.
Ação de colega interrompeu o workflow: Ações de colegas — como abrir, reatribuir ou comentar em uma conversa — podem interromper um workflow de auto-encerramento ativo e impedir que a conversa seja encerrada. 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 os gatilhos para o mesmo cliente. Isso evita loops com autoresponders, mas pode impedir o auto-encerramento se uma conversa foi reaberta dentro desse intervalo. Para garantir auto-encerramento 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-encerramento foi acionado inesperadamente?
Se seu workflow de auto-encerramento estiver rodando quando não deveria, as causas mais comuns são:
Revise as regras de público — especialmente as condições OR, que exigem apenas que uma condição seja atendida. Um cliente pode corresponder ao workflow inadvertidamente se qualquer uma das condições for verdadeira.
Verifique mudanças no estado da conversa, como tickets marcados como 'waiting_on_customer', que podem satisfazer as condições de acionamento inesperadamente.
Por que as conversas estão fechando muito cedo ou não fechando de forma alguma?
Cada bloco Let Fin answer em um workflow tem seu próprio temporizador de auto-encerramento. Se o temporizador estiver configurado para um tempo muito curto, as conversas podem ser fechadas antes que o cliente tenha tempo suficiente para responder. Para corrigir isso, clique no bloco Let Fin answer, abra as configurações de auto-encerramento 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 as 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 for auto-encerramento sem escalada, ajuste o workflow conforme necessário.
Combine as configurações de auto-encerramento 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-encerramento para workflows de email
Para workflows baseados em email, certifique-se de que as configurações de auto-encerramento estejam configuradas para acomodar emails encaminhados. Verifique se a ação de auto-encerramento está alinhada com as condições de acionamento 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 encerramento 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 clique no botão — 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 pelo Messenger.
Nota: No Messenger móvel para iOS e Android, cartões de artigos incorporados adicionados via etapas de Workflow não serão exibidos para usuários. Para garantir que usuários 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.