Com o encadeamento de email, todas as respostas relacionadas são agrupadas em uma única conversa. Isso permite que os teammates vejam o contexto do thread de email juntos, em um só lugar, sem precisar dividir a atenção entre várias conversas. O encadeamento de email também evita que threads passem por workflows múltiplas vezes ou sejam atribuídos a diferentes teammates que podem não ter o contexto correto.
Existem informações específicas em um email que usamos para determinar se ele deve ser encadeado em uma conversa existente. Todos os emails contêm metadados chamados headers, e usamos headers específicos para decidir quando e como encadear um email:
Message-ID: Todo email enviado tem um identificador único que é colocado no header Message-ID. Geralmente se parece com um endereço de email, por exemplo <1234567890@example.com>. O provedor de email que envia gera isso.
In-Reply-To: Quando você responde a um email, o provedor geralmente coloca o Message-ID do email respondido no header In-Reply-To.
References: Semelhante ao header In-Reply-To, normalmente contém o Message-ID do email respondido, mas pode conter alguns ou todos os Message-IDs de emails anteriores no thread.
Para emails recebidos no Intercom, você pode ver esses headers passando o mouse sobre o ícone de email no canto inferior esquerdo da mensagem e clicando em ‘View raw email’.
Quando um email é recebido no seu workspace, pegamos os headers References e In-Reply-To. Usamos esses para procurar uma conversa no seu workspace que contenha um email com um Message-ID referenciado por esses headers. Se encontrarmos, encadeamos o novo email nessa conversa.
Importante: O Intercom depende das informações dos headers, como o Message-ID, para determinar o encadeamento das conversas.
Para garantir conversas separadas para cada email, todo email enviado deve ter um Message-ID único. Reutilizar Message-IDs fará com que eles sejam mesclados em uma única conversa.
Remetentes externos
Em algumas circunstâncias, um email será encadeado em uma conversa a partir de um ‘external sender’. Isso acontece quando alguém que não foi incluído em nenhum dos emails anteriores envia um email que referencia um email da conversa nos headers In-Reply-To ou References.
Isso pode acontecer quando um participante da conversa envia um Bcc para alguém ou encaminha um email da conversa para outra pessoa. Se essa pessoa responder e incluir um dos endereços do seu workspace ou de encaminhamento nos campos To ou Cc, adicionamos a resposta na mesma conversa. Isso permite manter o contexto do mesmo thread de email junto na mesma conversa.
A resposta deles conterá um banner de aviso para informar ao teammate que a pessoa não foi vista anteriormente na conversa e não foi CC’d por outro participante.
O remetente não será adicionado como participante na conversa. O teammate pode optar por adicioná-lo para que ele possa ser incluído em respostas futuras.
Por que a resposta do email não está sendo encadeada em uma conversa existente?
Alguns clientes de email removem parte ou todos os headers que o Intercom usa para encadear respostas em uma conversa. Quando isso acontece, não temos uma forma confiável de encontrar a conversa para encadear o email. Clientes e servidores de email têm uma variedade de recursos e comportamentos que podem causar isso.
Por exemplo, o Zendesk pode modificar os headers de encadeamento, dificultando a continuidade da conversa. Além disso, as políticas DMARC do Google Groups frequentemente reescrevem os headers, complicando ainda mais o encadeamento.
Serviços de encaminhamento como Google Groups podem causar problemas adicionais de encadeamento devido às políticas DMARC que afetam as informações do remetente. Para mitigar esses desafios, considere usar o Routing Setup do Google ou o Advanced Email Routing para encaminhamento de emails.
Outra situação em que um email se divide em uma nova conversa ocorre em conversas iniciadas no Messenger, e que depois tiveram um ou mais participantes adicionados por email. O usuário no Messenger recebe um endereço de email alias quando suas respostas são enviadas aos outros participantes da conversa. Esse endereço alias é assim: alice.jones.onchat@examply.intercom-mail.com. Se um dos participantes remover esse endereço dos campos To ou Cc ao responder, a resposta será dividida em uma nova conversa.
Por que um email foi encadeado em uma conversa quando eu não esperava?
Users podem encaminhar emails enviados em uma conversa para outras pessoas, ou Bcc outras em suas respostas. Se essas pessoas responderem e incluírem um dos endereços do seu workspace ou de encaminhamento como destinatário, é provável que os headers References ou In-Reply-To relevantes estejam presentes, e encadearemos a resposta na conversa. Você pode ler mais sobre esse comportamento em Gerenciar conversas em grupo na Inbox.
Quando múltiplos emails chegam com o mesmo Message-ID, por exemplo, o Intercom os interpreta como parte do mesmo thread e reabre a conversa existente — mesmo que venham de endereços diferentes ou sejam destinados a inboxes diferentes.
Quando isso acontece, você precisará atualizar a configuração dos seus servidores de envio para garantir que conversas diferentes tenham Message-IDs únicos.
Então, o Intercom criará conversas separadas como esperado e seus workflows as direcionarão corretamente.
Além disso, alguns clientes de email dividem emails em novos threads quando o assunto muda de forma significativa. Isso não acontece no Intercom.
Para maior confiabilidade no encadeamento, considere usar o Intercom Messenger em vez de emails, pois elimina a dependência dos headers de email.
Por que os emails não estão sendo encadeados no meu cliente de email?
Clientes e servidores de email têm uma variedade de recursos e comportamentos que podem causar isso. Alguns têm configurações explícitas para ativar ou desativar o encadeamento, então vale a pena verificar essas configurações se existirem no seu cliente. Clientes de email também variam quanto aos headers necessários para encadear emails, ou podem dividir conversas com base em mudanças no assunto ou destinatários.
Comportamento antigo (conversas anteriores a 12 de julho de 2023)
Anteriormente, em conversas por email, definíamos o endereço ReplyTo para cada email como um endereço único para cada conversa que se parecia com isto: n+u_xxxx@examply.intercom-mail.com
Agora você pode enviar e receber emails dos endereços reais dos participantes da conversa, e responder diretamente a cada participante. Isso permite ver claramente com quem você está falando e controlar quem receberá sua mensagem, removendo pessoas que não quer enviar ou adicionando mais pessoas em CC.
| Comportamento antigo | Comportamento novo |
Quando os destinatários mudam | Quando um usuário responde a uma conversa por email e remove um ou mais dos outros users que receberam o email original, a resposta será dividida em uma nova conversa.
Exemplo: Alice envia um email para support@example.com (Intercom) e coloca Bob e Carol em CC. Bob responde para Alice e support@example.com, mas remove Carol do CC. O email dele cria uma segunda conversa no Intercom. | Respostas por email para uma conversa enviadas apenas para um subconjunto de participantes serão adicionadas a essa conversa em vez de iniciar uma nova.
Exemplo: Alice envia um email para support@example.com (Intercom) e coloca Bob e Carol em CC. Bob responde para Alice e support@example.com, mas remove Carol do CC. O email de Bob é encadeado na conversa de Alice no Intercom. Embora Carol seja participante da conversa, ela não recebe o email de Bob. |
Headers de email e respostas | Emails enviados em uma conversa em grupo têm um endereço ‘n+u’ no header ReplyTo. Quando o usuário responde, ele responde para esse endereço e a resposta é adicionada à conversa na Inbox para o teammate ver. Depois, a mensagem é enviada individualmente para todos os participantes da conversa. | Endereços N+u não são mais usados no header ReplyTo. Agora, quando um teammate responde em uma conversa em grupo, a mensagem é enviada em um único email para todos os participantes, com os endereços deles nos headers To e Cc. Quando users respondem a esses emails, eles respondem diretamente para cada participante, além do endereço Intercom usado para enviar a mensagem (ex: bob.oneill@examply.intercom-mail.com). Isso significa que não enviamos mais as respostas dos users para todos os participantes. Apenas os destinatários especificados no email receberão. |
Participantes Bcc’d ou ‘desconhecidos’ na conversa | Quando um participante responde a um email e Bcc’s alguém que não é participante da conversa, quando essa pessoa responder, a resposta será dividida em uma nova conversa.
Existem outros cenários similares, por exemplo, quando um teammate usa múltiplos endereços de email no cliente, ele pode iniciar uma conversa de um endereço e depois mudar para outro. Quando isso acontece, também dividimos a resposta em uma nova conversa. | Encadearemos respostas de pessoas Bcc’d (ou outros remetentes ‘desconhecidos’) na mesma conversa. A resposta deles conterá um banner de aviso para informar ao teammate que a pessoa não foi vista anteriormente na conversa e não foi CC’d por outro participante.
O remetente será adicionado como participante na conversa. O teammate pode optar por removê-lo da conversa se não quiser que essa pessoa veja as respostas. |
Conversas em grupo com um participante no Messenger | Conversas no Messenger também podem se tornar conversas em grupo. Apenas um dos participantes pode acessar a conversa no Messenger; todos os outros recebem respostas apenas por email.
Quando o teammate do Messenger envia uma resposta pelo Messenger, todos os participantes a recebem.
Para clientes que respondem, eles respondem para o endereço n+u, o que significa que a resposta será adicionada ao Messenger para o usuário do Messenger ver, e encaminhada para os outros participantes por email. | Ainda é verdade que conversas no Messenger podem se tornar conversas em grupo, e que apenas um dos participantes pode acessar a conversa no Messenger; todos os outros recebem respostas apenas por email.
Também é verdade que quando o usuário do Messenger responde, todos os participantes recebem a mensagem, mas o email parecerá assim: sam.murray.onchat@examply.intercom-mail.com para representar melhor o teammate do Messenger. O email também conterá um aviso no topo para informar que responder ao email enviará a mensagem para o usuário que está no Messenger. |
Histórico da conversa | Clientes têm uma configuração em Email settings para determinar se o histórico completo da conversa deve ser anexado ao final de cada email enviado na conversa. | Enviar histórico da conversa em emails pode ser ativado ou desativado. |
Respostas de users via API | A API pode ser usada para adicionar respostas de email a uma conversa em nome dos users. Isso faz com que a resposta seja enviada para todos os participantes da conversa. | O comportamento permanece inalterado. |