Com o encadeamento de email, todas as respostas relacionadas são agrupadas em uma única conversa. Isso permite que os colegas vejam o contexto do thread de email juntos, em um só lugar, sem precisar dividir a atenção entre várias conversas. O encadeamento também evita que threads de email passem por workflows várias vezes ou sejam atribuídos a diferentes colegas 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 o email 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 também 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 em emails fará com que eles sejam mesclados em uma única conversa.
Remetentes externos
Em algumas situações, 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 endereços de encaminhamento nos campos To ou Cc, adicionamos a resposta dela na mesma conversa. Isso permite manter o contexto do mesmo thread de email junto na mesma conversa.
A resposta dessa pessoa conterá um banner de aviso para informar ao colega que essa pessoa não estava previamente na conversa e não foi CC’d por outro participante.
O remetente não será adicionado como participante da conversa. O colega pode optar por adicioná-lo como participante 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 headers de encadeamento, dificultando a continuidade da conversa. Além disso, políticas DMARC do Google Groups frequentemente reescrevem 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 Google Routing Setup ou 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, 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 thread de 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 a quais headers precisam estar presentes para que os emails sejam encadeados, ou podem dividir conversas com base em mudanças no assunto ou nos 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.
Nota: Quando usuários iOS respondem a um email a partir de uma notificação em vez de abrir o email diretamente, o Apple Mail envia um email novo sem histórico de encadeamento. O Intercom não consegue vincular ao histórico original e abre uma nova conversa.
A solução é responder diretamente do email na inbox, e não da notificação.
| Comportamento antigo | Comportamento novo |
Quando os destinatários mudam | Quando um usuário responde a uma conversa por email e remove um ou mais 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 colega 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 colega 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 pelo usuário 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 semelhantes, por exemplo, quando um colega usa múltiplos endereços de email no cliente, 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 colega que a pessoa não estava previamente na conversa e não foi CC’d por outro participante.
O remetente será adicionado como participante na conversa. O colega 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 colega do Messenger envia uma resposta pelo Messenger, todos os participantes a recebem.
Para clientes que respondem, eles responderão 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 colega do Messenger. O email também conterá um aviso no topo para informar que responder ao email enviará a mensagem para o usuário no Messenger. |
Histórico da conversa | Clientes têm uma configuração em suas Configurações de Email para determinar se o histórico completo da conversa deve ser anexado ao final de cada email enviado em uma 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. |