Diagnostique por que um Workflow não está funcionando como esperado — incluindo conversas indo para o time errado, roteamento para a inbox errada, atribuição não funcionando como esperado ou um workflow sendo completamente ignorado. 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 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
Se seu workflow não está disparando, as conversas estão indo para o time ou inbox errados, ou as atribuições não funcionam como esperado, estas são as principais áreas para verificar primeiro:
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 planejado?
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?
Conversas indo para o time ou inbox errados?
Se as conversas estão sendo atribuídas ao time errado, caindo na inbox errada ou o roteamento não está funcionando como esperado, a causa quase sempre é uma destas:
Um workflow de prioridade mais alta está rodando em vez disso — veja "Outro workflow pode estar tendo prioridade sobre o meu?" abaixo.
O público-alvo é muito restrito — um workflow que mira apenas Users vai ignorar Leads, deixando-os sem atribuição ou roteados para um fallback. Veja "Por que minha regra de público não está correspondendo aos clientes certos?"
Passo de atribuição está faltando — se o workflow não inclui um passo explícito de Assign to team ou Assign to teammate, as conversas voltam para Unassigned. Veja o artigo de workflow de atribuição linkado abaixo.
O workflow não está disparando de jeito nenhum — se nenhum workflow dispara, nenhuma atribuição acontece. Continue lendo este artigo para diagnosticar o motivo.
Para um guia completo sobre problemas específicos de atribuição (conversas não atribuídas, Round Robin, disponibilidade do time), veja Gerenciar e solucionar problemas de Workflows de atribuição.
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, configuração do público ou atributo de dados no seu workflow para corresponder ao estado esperado, então teste novamente com a 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 disparo 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á disparando o workflow?
Antes de verificar o workflow em si, certifique-se de que suas configurações do Messenger e automação estão corretamente configuradas para permitir que as conversas comecem.
Configurações de Conversa de Entrada
Controlar 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 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 desabilitado
Mostrar o Launcher do Messenger é uma configuração do Messenger que pode ser ajustada para esconder o Messenger dos clientes. Se o Messenger estiver escondido dos clientes, qualquer Workflow que envolva 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ê tem 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 que bloqueia 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á disparando?
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. Esse entendimento é essencial para estruturar workflows eficazmente sem sobreposições inesperadas. Qual gatilho 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 disparo do workflow.
Filtros de conteúdo da mensagem
Se seu workflow não está disparando para ações específicas, verifique incompatibilidades nos seus critérios de 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 efetivamente, 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 de saída 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 da mensagem, verifique se eles não são muito restritivos. Usar "Message content is" requer 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 mirar 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 disparar 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 mira apenas Leads e Users, 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 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 encaminhamento foi configurado corretamente e se o encaminhamento automático está habilitado.
Exemplo:
Você configurou um workflow com o gatilho "When customer opens a new conversation in the Messenger" e adicionou um passo 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 "Quando o cliente envia qualquer mensagem" em vez disso.
Você está direcionando as pessoas certas (Users vs. Leads)?
Se um workflow (por exemplo, uma resposta fora do horário) não disparar porque ele tem como alvo "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.
As 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 completos, atualize as configurações do público do seu workflow para incluir todos os tipos relevantes de participantes (visitantes, leads e users). Por exemplo, um workflow direcionado apenas a 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 workflows voltados para o cliente ou workflows em segundo plano. Workflows voltados para o cliente envolvem interações visíveis, como o 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 vários 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 colegas de equipe e incluem:
Abrir
Abrir e reatribuir
Enviar um comentário
Sonecar
Nota: Um workflow voltado para o cliente mantém sua vaga mesmo enquanto espera uma 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 acionarã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 colega de equipe (abrir, reatribuir, comentar ou sonecar) para interrompê-lo.
Nota: Workflows em segundo plano são projetados para executar automações independentemente das ações dos colegas de equipe e não param quando colegas respondem ou sonecam conversas.
Após um workflow voltado para o cliente ser interrompido, outro workflow voltado para o cliente pode entrar em ação.
Respostas a mensagens enviadas só acionam 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?
As 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.
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 não intencionais 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 users 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 pontos
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 não intencionais 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 é 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 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 falso e o workflow não dispara para o remetente.
Nota: A prévia do tamanho do público (por exemplo, "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 de contato: remova completamente a regra "Last heard from" e direcione Leads e Users no canal relevante.
Para direcionar apenas contatos totalmente novos: use "Signed up is unknown." Esse atributo não é redefinido por mensagens recebidas, então não há condição de corrida.
Para reengajar contatos inativos: use "Last contacted is more than X days ago." O atributo "Last contacted" registra quando você enviou a última mensagem de saída — ele não é atualizado quando um cliente escreve para você, mantendo-se preciso no momento da correspondência.
Será que o tempo, agendamento ou ação de um colega está 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 o agendamento do Workflow não são atendidos. Fatores externos podem impedir a execução do workflow, mesmo que todas as regras estejam corretas.
Um colega respondeu ou tomou alguma ação primeiro?
Se um colega 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, uma resposta do colega 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 colega.
Conversas adiadas e gatilhos não responsivos
Para workflows que usam uma conversa adiadas como condição de gatilho, a conversa deve permanecer continuamente adiada até que o cliente fique não responsivo. Se a conversa for desadiada antes desse ponto — por exemplo, por um colega ou um temporizador automático — o gatilho de inatividade não disparará, mesmo que o cliente fique não responsivo depois.
Nota: Se uma conversa for desadiada e o cliente ficar não responsivo depois, o gatilho de não responsividade não disparará novamente. Para que o gatilho funcione novamente, o cliente precisaria responder primeiro para reabrir a conversa e então ficar não responsivo novamente enquanto a conversa permanece adiada.
Agendamento de data personalizado
O Workflow pode ter um agendamento 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 o acionará — independentemente do gatilho selecionado. Por exemplo, se um workflow estiver configurado para rodar aos sábados entre 00:00–08:00 GMT, ele não disparará para eventos ocorridos à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 ter sido criado e ativado. Se uma conversa começou antes da existência do workflow, ele 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.
Será que a configuração do canal está 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 disparará. 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 ele 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, dispare 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 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 o disparo do Workflow.
Melhores práticas para direcionamento de URL
O direcionamento por URL da página atual pode ser adicionado na seção "Para onde enviar" ou na seção principal de direcionamento de público dentro das configurações da regra de gatilho. No entanto, sua funcionalidade difere conforme a seção em que estão inseridos:
Direcionamento de público: Configurações de URL aqui direcionam 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 atual em que o user está. Isso geralmente corresponde ao resultado desejado.
Nota: Usar direcionamento de 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 o direcionamento de 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 aplicativos 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: 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 API JS do Intercom Messenger para enviar a URL atual como um atributo de dado personalizado sempre que a rota mudar em seu SPA. Você pode então usar esse atributo de dado personalizado como condição de URL no workflow em vez de depender do URL da página atual.
Problemas de tempo 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 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". 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 acionando em páginas de artigos
Se um workflow não for acionado em páginas de artigos, verifique as regras de exclusão de público que podem estar bloqueando URLs de artigos:
Vá para Settings → Messenger → Messenger Widget → Show the Messenger Launcher e verifique se há regras condicionais de exibição baseadas em URL ativas.
Se uma regra oculta o Messenger em URLs que correspondem ao seu domínio do help center (por exemplo,
intercom.com/help/*), o Messenger não será carregado nas páginas de artigos — e sem o Messenger, qualquer Workflow que dependa de uma interação com o Messenger não será acionado.Para corrigir isso, adicione uma exceção para o padrão de URL do seu help center ou remova a regra de exclusão se ela não for necessária.
Nota: Isso afeta apenas Workflows que envolvem uma interação com o Messenger (por exemplo, "Quando um cliente visita uma página", "Quando um cliente abre o Messenger"). Workflows em segundo plano e workflows de email não são afetados pelas configurações de visibilidade do Messenger.
Será que outro workflow está 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 ser acionado 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 cliente seja VIP.
Por que atribuir a uma equipe limpa uma atribuição individual existente?
Atribuir uma conversa a uma equipe imediatamente após ela ter sido atribuída a um colega individual limpa essa atribuição individual. Se a lógica do seu workflow atribui a um colega e depois a uma equipe na mesma etapa ou em uma etapa subsequente, a atribuição à equipe substituirá a individual. Para evitar isso, certifique-se de que seu workflow não faça ambas as atribuições consecutivamente, a menos que a atribuição em nível de equipe seja intencional.
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:
Fin e priorização de Workflow com implantação Simple
Quando a implantação Simple do Fin e workflows estão ativados para o mesmo público, a implantação Simple tem prioridade e apenas o Fin responderá. Para permitir que workflows sejam acionados, ajuste o direcionamento do público para que não se sobreponham ou desative a implantação Simple.
Ativando CSAT para encerramentos de Workflow do Fin
Workflows de Customer Satisfaction Score (CSAT) não são acionados automaticamente quando o Fin encerra uma conversa. Para garantir que 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 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 restritivo. 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 lidar com 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 do 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, ele pode suprimir etapas de captura de email no Fin para workflows de Sales. Fin para Sales faz qualificação de leads independentemente, e os dois podem entrar em conflito — o prompt de email pode ser pulado porque o Fin para Sales assume que coletará os dados de contato por meio do seu próprio fluxo de qualificação. Para corrigir, desative Get context about issue upfront para Leads em Simple Automation e confie em uma etapa dedicada de captura de email no seu workflow.
Conflito de prioridade de workflow: Um workflow voltado para o cliente com prioridade maior pode estar rodando em vez do seu workflow de captura de email. Verifique a ordem de prioridade dos workflows e garanta que seu workflow Fin para Sales esteja acima de quaisquer workflows gerais de captura ou boas-vindas que possam estar interceptando o mesmo público.
Lead já possui um endereço de email: Se o Intercom já tem um email para o 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 de fallback 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.
Implantação Simple para interferência do 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 destinatário pretendido dentro dos filtros do workflow. Além disso, certifique-se de 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 acionarem workflows, verifique se o endereço de email correto foi definido no workflow ou por meio 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 listas de distribuição, condições de domínio 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 por engano se uma reatribuição for processada após a avaliação.
Minimize esses erros ao:
Revisar a ordem das condições para garantir que exclusões sejam aplicadas primeiro.
Testar workflows extensivamente durante cenários de reatribuição.
Evitando a má classificação pelo Fin
Se o Fin estiver classificando conversas incorretamente 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 domínio comumente associadas às frases dos clientes.
Teste as descrições com conversas de exemplo.
Por que meu workflow de auto-encerramento não está funcionando como esperado?
Workflows de auto-encerramento 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 a resolução oportuna das conversas. Use esta seção se seu workflow de auto-encerramento não estiver acionando, estiver fechando conversas cedo demais ou sendo interrompido inesperadamente.
Nota: O recurso de Auto-close aplica-se apenas a conversas de workflows abandonados. Chats regulares ou mensagens enviadas aguardando resposta do usuário não são considerados ativos e não serão auto-encerrados.
Configurando um Workflow de Auto-Encerramento
Para criar um workflow de auto-encerramento, navegue até Fin AI Agent Workflows no seu app Intercom. Selecione + New workflow e escolha o modelo: Follow up with inactive customers. Defina o temporizador de inatividade para determinar quanto tempo esperar pela resposta do cliente antes de acionar o workflow. A duração deve estar entre 3 segundos e 14 dias. Especifique os canais (ex.: Web, iOS, Android, email, SMS) onde este workflow será aplicado.
Por que meu workflow de auto-encerramento não acionou?
Razões comuns para um workflow de auto-encerramento não acionar:
Verifique se houve interrupções no período relevante — um incidente ativo pode ter impedido a execução do workflow.
Garanta que as condições do gatilho correspondam ao estado da conversa. Por exemplo, se seu público inclui apenas 'Users', o workflow não acionará 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 a implantação Simple 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-encerramento sejam acionados. Para resolver, desative a implantação Simple 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 em uma conversa — podem interromper um workflow de auto-encerramento ativo e impedir o fechamento da conversa. 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-encerramento se uma conversa foi reaberta dentro desse período. 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 acionou inesperadamente?
Se seu workflow de auto-encerramento 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?
Usando Tags para Fechamento Temporizado de Chats
Para fechar chats após um período específico, use uma abordagem baseada em tags:
Adicione uma tag na conversa (ex.: "Agent?") ao solicitar algo ao cliente.
Remova a tag se o cliente responder.
Configure um workflow para fechar conversas com essa tag após o tempo especificado.
Garanta que as tags sejam removidas quando uma conversa for atribuída a um agente para evitar fechamento prematuro.
Cada bloco Let Fin answer em um workflow tem seu próprio temporizador de auto-encerramento. 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-encerramento e aumente a duração do temporizador.
Além disso, verifique uma configuração chamada "close abandoned Fin conversations after 3 mins" dentro do bloco "Let Fin Answer". Desative essa configuração para permitir que as conversas permaneçam abertas até serem fechadas manualmente por um membro da equipe.
Se as conversas nunca fecham 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 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-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.
Certifique-se de que a opção "If Fin has answered the question" esteja marcada nas configurações do workflow. Isso garante o auto-encerramento para novas conversas.
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 do 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 dependa apenas de 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 rodar 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 — nesse ponto, existe uma conversa 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 disparar, 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 Suporte pelo Messenger.
Nota: No Messenger móvel para iOS e Android, os cartões de artigo incorporados adicionados via passos de Workflow não serão exibidos para os 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 direcione diretamente para o artigo.