邮件变成工单后如何保留邮件线程

电子邮件对话转为工单后，能否保持在同一对话中，取决于帮助台所使用的线程规则。常见信号包括 Message-ID、In-Reply-To 和 References 标头。有些平台还会在邮件正文或接收地址中使用工单 ID 或其他标识符。

在依赖新的电子邮件渠道之前，请使用以下检查清单：

使用帮助台官方支持的方式连接支持地址。
发送一个测试工单，并通过客户将使用的相同路径进行回复。
比较原始邮件和回复的标头，然后确认回复显示在现有工单中。

如果测试创建了新工单，请先查看帮助台记录的线程规则，再更改邮件路由。每个平台对标头、工单标识符和发件人检查的组合方式都可能不同。

要点总结

电子邮件线程并不只基于主题行。帮助台通常会检查标准回复标头，也可能使用自己的工单标识符作为额外的匹配信号。

要点	详情
标头用于关联回复	`In-Reply-To` 和 `References` 指向现有对话中的邮件 ID。
不同平台的规则各不相同	帮助台还可能检查工单 ID、隐藏标识符、接收地址或发件人。
使用受支持的连接方式	按照帮助台和电子邮件提供商记录的邮箱设置进行操作。
测试实际路径	以客户身份回复，并确认邮件已加入原始工单。
Deskhero 邮箱选项	Deskhero 支持双向连接 Google 和 Microsoft 邮箱，也支持通过经过身份验证的发送进行域转发。

哪些标头真正能够保留电子邮件线程

电子邮件通常都有一个 Message-ID。回复可以携带一个 In-Reply-To 值，指向被回复的邮件；还可以携带一个 References 值，列出之前邮件的 ID。帮助台可以利用这些关系，将邮件关联到某个对话。Amazon Connect 的文档介绍了按时间顺序排列的线程，以及当用户回复较早邮件时形成的树状模式。

各个平台还可以加入自己的匹配方式。Zendesk 记录了三项检查：标头元素、邮件正文中的编码 ID，以及 Zendesk 接收地址中的编码 ID。这些是 Zendesk 特有的规则，并不是可以复制到所有帮助台中的通用模板。

线程之所以重要，是因为将回复与之前的邮件分开，会让支持历史更难追踪：

用户可能需要在另一个工单中搜索之前的附件或决策。
收件人和之前的回复可能会与最新问题分离。
两个用户可能分别回复相关邮件，却没有意识到它们属于同一个对话。

Freshdesk 的电子邮件文档展示了另一种特定于平台的处理方式。它会检查工单 ID、邮件 ID 或唯一标识符，之后再检查发件人。实际经验是，了解自己的帮助台使用哪些信号，并通过实际邮件路径保留这些信号。

设置邮件服务器以保持线程完整

可靠的设置应从帮助台支持的连接方式开始。不要假设 SMTP 中继、转发规则或邮箱同步在不同产品中的行为都相同。

选择文档中说明的邮箱连接方式。 如果帮助台提供直接连接 Google 或 Microsoft 的方式，请按照其授权流程操作。如果它要求进行转发，请使用产品提供的确切目标地址和 DNS 记录。
为预期地址配置转发。 Deskhero 的 Google Workspace 转发指南说明了如何创建一个群组，并将 Deskhero 目标地址添加为成员。Microsoft 365 和其他提供商的设置路径有所不同。
保留平台标识符。 如果帮助台在外发通知中添加了工单标记，除非产品文档说明它是可选的，否则不要从模板中删除。Freshdesk 建议包含其工单 ID 格式，而 Zendesk 默认会在外发通知中添加编码 ID。
检查会转换邮件的系统。 路由规则、邮件列表和网关可能会在帮助台收到邮件之前更改邮件。请在每个可用阶段比较原始邮件源，而不是猜测某个值在哪里发生了变化。
执行可重复的验证测试。 创建工单、发送回复并检查原始邮件源。确认 In-Reply-To 是否指向较早的 Message-ID，References 是否包含预期的链，以及回复是否加入了现有工单。

专业提示： 请通过客户将使用的相同地址、转发路径和电子邮件客户端进行测试。直接向内部测试地址发送邮件，并不能验证完整的生产路径。

线程为何会中断，以及如何解决每种原因

回复可能因多种原因变成新工单。具体原因取决于平台的匹配规则。

缺少回复标头。 作为新邮件撰写的邮件可能不包含回复所应有的 In-Reply-To 或 References 值。请让发件人使用“回复”，然后比较原始邮件源。
路由或收件人发生变化。 发送到不同支持地址的邮件可能会创建另一个工单。例如，Freshdesk 记录了包含多个已配置帮助台地址时的特殊行为。
平台标识符被删除。 编辑通知模板可能会删除帮助台用作备用匹配依据的工单 ID 或隐藏标识符。
邮件匹配已过期。 Freshdesk 表示，其邮件 ID 通常会在最后一次回复后的七天过期。此后，它会查找工单 ID 或工单标识符。这一时间规则仅适用于 Freshdesk，不应假定其他产品也如此。

请从原始外发邮件和客户回复开始诊断。并排比较两者的原始标头，然后查看帮助台自身的文档和工单时间线。如果回复标头存在，请检查平台的其他要求，例如工单标记、接收地址或允许的发件人。如果标头缺失，请通过电子邮件提供商和任何转发服务追踪邮件路径，找出邮件在哪里发生了变化。

Deskhero 如何保持对话历史完整

Deskhero 可以将现有的 Gmail、Google Workspace 或 Microsoft 365 邮箱转变为帮助台。它还支持通过 DNS 身份验证和入站转发使用其他自有域名上的邮箱。

Google 和 Microsoft 连接提供双向同步，因此 Deskhero 可以读取收到的邮件，并以已连接地址发送回复。
DNS 邮箱使用 DKIM 记录进行经过身份验证的发送，并使用唯一的 Deskhero 地址进行入站转发。
同一电子邮件对话中的回复会加入现有的 Deskhero 工单。
AI 建议回复会使用工作区知识，并由用户掌控。自动回复是单独的功能，必须为每个群组启用，并且只会根据获批准的公开 FAQ 进行回答。

如需了解更多背景，请参阅 Deskhero 关于帮助台电子邮件双向同步、将现有邮箱用作帮助台以及将入站邮件转为工单的文章。

要求	Deskhero 选项
连接 Gmail 或 Google Workspace	通过 OAuth 连接并进行双向同步
连接 Microsoft 365 或 Outlook	通过 OAuth 连接并进行双向同步，包括共享邮箱
使用其他自有域名	使用 DNS 身份验证进行发送，并通过转发接收入站邮件
控制 AI 回复	用户审核建议回复；自动回复需要单独选择启用

大多数设置指南弄错了什么

人们很容易将线程归结为一条规则，例如保留 Message-ID。供应商文档说明了为什么这种理解并不完整。Zendesk 会结合标头检查和编码 ID 检查。Freshdesk 会将多个电子邮件标记与发件人检查结合起来。Amazon Connect 则使用相关联系人数据和传统电子邮件标头来关联联系人。

大多数设置指南弄错了什么，概览图

更好的做法是将线程视为端到端的行为。使用受支持的邮箱连接方式，保留产品生成的标识符，并使用真实的客户回复进行测试。当结果不正确时，比较原始邮件，并按照帮助台记录的匹配顺序逐步排查。

这也可以避免不必要的邮件服务器更改。新的中继或重写后的模板可能会引入另一个变量，却无法解决实际的匹配错误。

在不遗漏任何回复的情况下运行线程式帮助台

Deskhero 可以通过双向同步连接现有的 Gmail、Google Workspace 或 Microsoft 365 邮箱。对于其他自有域名，它支持通过 DNS 配置进行经过身份验证的发送，并将入站邮件转发到唯一的 Deskhero 地址。

Deskhero

您的用户可以在共享收件箱中工作，同时回复会从已连接的公司地址发出。如果您的支持业务使用 Shopify，Shopify 集成会在工单侧边栏中添加客户和订单上下文。

Deskhero 提供30 天免费试用，无需信用卡。您可以连接现有地址，而不必要求客户学习使用新的地址。

来源

常见问题

双向同步和转发有什么区别？

双向同步允许帮助台从已连接的邮箱读取邮件，并通过该邮箱发送邮件。转发会将收到的邮件发送到另一个目标地址，出站邮件可能需要单独的身份验证。可用的方法和线程规则取决于帮助台和电子邮件提供商。

为什么客户回复创建了新工单，而不是加入原有线程？

回复可能缺少预期标头、使用了不同的支持地址、来自平台无法与该工单关联的发件人，或者缺少特定于产品的工单标识符。请检查原始邮件源以及帮助台记录的规则。

如何检查线程是否正常工作？

确认回复显示在现有工单中。如果没有，请将回复中的 In-Reply-To 和 References 值与较早邮件中的 Message-ID 值进行比较，然后检查平台使用的任何工单标识符。

如果已经使用双向同步，还需要经过身份验证的 SMTP 中继吗？

通常不需要将其作为单独的线程修复措施。请按照帮助台要求的发送配置进行操作。直接的邮箱连接可能已经处理了出站邮件，而转发或基于 DNS 的设置可能会使用其他经过身份验证的发送方式。

Deskhero 同时支持 Gmail 和 Microsoft 365 吗？

支持。Deskhero 支持 Gmail、Google Workspace、Microsoft 365 和 Outlook 的双向连接，也支持 Microsoft 共享邮箱。