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.
Lista de Verificação para Solução de Problemas
Antes de começar, revise rapidamente estas áreas-chave onde os 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?
Configurações do Messenger
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 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 pode 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 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 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 interferir nos gatilhos de inatividade funcionando corretamente. Pode ser interrompido inadvertidamente de forma que bloqueie outros Workflows voltados ao 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.
Verifique as regras de gatilho e público do seu Workflow
Ferramenta de Solução de Problemas
Use a Ferramenta de Solução de Problemas do Workflow para identificar condições incompatíveis:
Navegue até a visão geral dos Workflows.
Clique em “Troubleshoot” e cole a URL da conversa.
Revise a avaliação da lógica do predicado para identificar condições incompatíveis.
Interação dos Tipos de Gatilho
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 eficazmente sem sobreposições inesperadas. O gatilho escolhido para seu workflow e como você configura 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 pode não incluir uma mensagem iniciada pelo cliente, o que pode impedir o acionamento do workflow.
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 e-mail específico, verifique se as condições de e-mail nas configurações do gatilho estão corretas. Para roteamento eficaz de e-mails de entrada, use o gatilho "Customer Sends First Message" e filtre por atributos de e-mail em vez de usar filtros de e-mail. 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 de 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.
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 direciona apenas Leads e Users, ele não será acionado para este Visitante. 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 e-mail para o qual os clientes estão enviando mensagens está 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 e-mails encaminhados devem sempre verificar se o endereço de encaminhamento foi configurado corretamente e se o encaminhamento automático está ativado.
Exemplo:
Você configura um workflow com o gatilho "When customer opens a new conversation in the Messenger" e adiciona uma etapa para marcar todas essas conversas.
Um cliente responde a uma publicação que você enviou de Outbound.
Esta conversa não seria marcada porque ele não iniciou a conversa no Messenger (ele respondeu 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á direcionando as pessoas certas (Users vs. Leads)?
Se um workflow (por exemplo, uma resposta fora do horário) não for acionado porque ele direciona "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 direcionamento 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 em modo anônimo ou 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 direcionado apenas a 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.
Tipo de workflow
Workflows voltados ao cliente vs Workflows em segundo plano
Workflows no Intercom são categorizados como voltados ao cliente ou em segundo plano. Workflows voltados ao 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 ao cliente, como marcar conversas ou fechar threads. Importante: para um único tipo de gatilho, apenas um workflow voltado ao 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 ao cliente é acionado por conversa. Quando múltiplos workflows correspondem ao mesmo gatilho, o Intercom prioriza e ativa o workflow de maior classificação nas configurações do workflow.
Você pode ter apenas um workflow voltado ao cliente rodando em uma conversa por vez. Ações que interromperiam um workflow voltado ao cliente e permitiriam que outro workflow voltado ao cliente fosse acionado são ações de colegas e incluem:
Abrir
Abrir e reatribuir
Enviar um comentário
Soneca
Workflows em segundo plano são projetados para executar automações independentemente das ações dos colegas e não param quando colegas respondem ou colocam conversas em soneca.
Após um workflow voltado ao cliente ser interrompido, outro workflow voltado ao cliente pode entrar em ação.
Respostas a mensagens enviadas só ativarão workflows configurados para 'cliente envia a primeira mensagem', não aqueles configurados para 'cliente inicia uma nova conversa'. Essa distinção ajuda a garantir que os workflows sejam configurados corretamente para diferentes tipos de conversa. Por exemplo, um gatilho de "Primeira mensagem" não será acionado para respostas a e-mails enviados, pois são tratados como continuações de conversas existentes.
Segmentação de público
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 ativar um workflow ao cumprir qualquer uma das condições atender às suas necessidades. Para casos que exigem todas as condições cumpridas, 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 a regra se aplicar. 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 "OR" 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 OR são acionadas se qualquer condição for atendida.
Regras OR negativas podem levar a correspondências indesejadas porque, uma vez que uma condição é verdadeira, as outras são ignoradas.
Use regras AND 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 direcionadas pelo workflow desde o início.
Então, se você quiser excluir usuários em Dublin e Londres, precisa mudar da lógica "OR" para a lógica "AND":
"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 estiver em qualquer uma das cidades, a regra de público não corresponde e o workflow não será acionado.
Principais conclusões
Regras OR são acionadas se qualquer condição for atendida.
Regras OR negativas podem levar a correspondências indesejadas porque, uma vez que uma condição é verdadeira, as outras são ignoradas.
Use regras AND 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:
"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 é direcionada pela lógica do workflow, o sistema usará a empresa mais recentemente atualizada associada ao usuário se nenhuma empresa específica estiver definida, e que condições de ramificação usando regras OR negativas podem resultar em direcionamento 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 direcionamento correto.
Revise o tempo, agendamento e ações dos colegas
Usando agendamento, você pode controlar quando e por quanto tempo um Workflow está ativo. Muitas vezes, um Workflow não é acionado porque os critérios para quando o Workflow está agendado não são atendidos. Fatores externos podem impedir a execução de um workflow, mesmo que todas as regras estejam corretas.
Um colega respondeu ou tomou uma 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, um colega 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 colega.
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 desses horários não acionará o Workflow — independentemente de qual gatilho esteja selecionado. Por exemplo, se um workflow estiver configurado para rodar aos sábados entre 00:00–08:00 GMT, 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 ramificações 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 as ramificações são avaliadas 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ó são acionados 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 de conversas existentes.
Canais
Se seu Workflow estiver configurado para canais específicos como Email, SMS ou redes sociais, certifique-se de que o canal esteja corretamente conectado e ativo. Um canal desconectado pode ser a razão pela qual um Workflow não está sendo acionado. Além disso, garanta que as configurações do canal do seu workflow estejam alinhadas com a forma como os users interagem - se um workflow estiver configurado para acionar 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 esteja habilitado na configuração. Sem esse canal ativo, conversas por email não acionarão os workflows respectivos. Por exemplo, um workflow direcionado aos canais Web, iOS e Android não será acionado 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 a 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 seja acionado novamente. Se o intervalo for menor que 2 minutos, o workflow não será ativado.
Prevenção de gatilhos repetidos de workflow
Ao configurar workflows que respondem a mensagens de clientes, você pode querer evitar que o mesmo workflow seja acionado várias vezes dentro de uma conversa, especialmente quando os users enviam detalhes adicionais em seguimento.
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 os workflows para verificar a ausência dessa tag antes de disparar.
Essa abordagem garante que cada workflow seja acionado apenas uma vez por conversa, evitando respostas automáticas duplicadas.
Esse sistema de tags é especialmente útil para workflows acionados por condições como "Customer sends their first message" ou "Customer sends any message", onde mensagens de acompanhamento podem potencialmente reativar sua automação.
Melhores práticas para configuração de Workflow
Aqui estão algumas melhores práticas para garantir que seus Workflows funcionem sem problemas:
Sempre realize testes após modificar as configurações do Workflow, garantindo que os gatilhos funcionem conforme esperado.
Use convenções de nomenclatura descritivas e consistentes para Workflows e regras para simplificar a solução de problemas.
Configurações de URL da página
Certifique-se de que o Workflow está configurado corretamente para disparar nas Page URLs corretas ou dentro dos aplicativos certos em dispositivos iOS & Android. Configurações incorretas podem impedir o disparo do Workflow.
Melhores práticas para segmentação de 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 audiência dentro das configurações de Trigger rule. No entanto, sua funcionalidade difere conforme a seção em que estão inseridas:
Audience Targeting: As configurações de URL aqui segmentam os 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 real em que o user está atualmente. Isso geralmente corresponde ao resultado desejado.
Usar segmentação de URL na seção Where to send desativará o bot de entrada em iOS & Android, pois os 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 & Android sem regras 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 não captura URLs para conversas originadas em plataformas externas como Facebook, pois essas interações ocorrem fora do seu site.
Use 'Page URL' em vez disso
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 no local onde a conversa começou.
Procure conflitos de prioridade no Workflow
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 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, mesmo que o cliente seja VIP.
Para corrigir isso, reordene seus workflows em Settings > Workflows. Arraste seus workflows mais específicos e importantes para o topo da lista e coloque os gerais, abrangentes, na parte inferior.
Problemas de Automação Fin
O agente Fin AI pode às vezes interagir com Workflows de maneiras que levam a comportamentos inesperados. Veja como resolver problemas comuns relacionados a Fin e Workflow:
Prioridade entre Fin e Workflow com Simple Deploy
Quando o Simple deployment do Fin e os workflows estão ativados para a mesma audiência, o Simple deployment tem prioridade e somente o Fin responderá. Para permitir que workflows sejam acionados, ajuste a segmentação da audiência para que não se sobreponham ou desative o Simple deployment.
Ativando CSAT para Fechamentos de Workflow Fin
Workflows CSAT não disparam automaticamente quando o Fin fecha 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 Fin CSAT.
Users sendo questionados repetidamente
Workflows configurados para "Get context about issue upfront" podem fazer com que users 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 users e leads.
Interferência do Simple Deploy para Fin
Se o Simple Deploy para Fin estiver ativo, ele 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 disparando como esperado e você estiver usando Fin, tente desativar o "Simple Deploy for Fin" para garantir que seus workflows possam ser acionados para users.
Workflow 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 dentro dos 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 acionarem workflows, verifique se o endereço de email correto foi definido no workflow ou via segmentação de audiência. 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 devido à conformidade DMARC que reescreve 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 disparar 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.
Evite a má classificação pelo Fin
Para refinar a correspondência de atributos e evitar má classificação:
Escreva descrições claras e contextuais para cada atributo.
Adicione palavras-chave específicas do domain comumente associadas a frases de clientes.
Teste descrições com conversas de exemplo.
Solução de problemas de auto-closure workflow
Workflows de auto-closure fecham automaticamente conversas com base em gatilhos e condições específicas — como inatividade do cliente ou ações predefinidas do workflow. Eles ajudam a manter seu inbox organizado e garantem a resolução oportuna da conversa. Use esta seção se seu auto-closure workflow não estiver disparando, estiver fechando conversas cedo demais ou sendo interrompido inesperadamente.
Por que meu auto-closure workflow não disparou?
Razões comuns para um auto-closure workflow não disparar:
Verifique se houve interrupções durante o período relevante — um incidente ativo pode ter impedido o workflow de ser executado.
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 disparará para 'Leads'. Expanda suas regras de público para incluir todos os tipos de perfil relevantes.
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 tem prioridade e pode impedir que workflows de auto-closure disparem. Para resolver, desative o Simple deployment ou ajuste o direcionamento do público para que os dois não se sobreponham.
Ação de teammate interrompeu o workflow: Ações de teammates — como abrir, reatribuir ou comentar em uma conversa — podem interromper um auto-closure workflow ativo e impedir que ele feche a conversa. Workflows que dependem de gatilhos de inatividade também podem falhar se a ação de um teammate 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-closure se uma conversa foi reaberta dentro desse intervalo. Para garantir auto-closure 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 auto-closure workflow disparou inesperadamente?
Revise as regras de público — especialmente condições OR, que exigem apenas que uma condição seja atendida. 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 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 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-closure para workflows de email
Para workflows baseados em email, certifique-se de que as configurações de auto-closure 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.
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 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.