将现有邮箱变成帮助台：中小企业指南
是的，您可以将 Gmail、Google Workspace 或 Microsoft 365 邮箱转变为正常运行的邮件工单系统，无需迁移现有邮件记录，也无需创建新的公开地址。Deskhero通过 OAuth 连接 Google 和 Microsoft 邮箱，将收到的邮件转换为可跟踪的工单，并通过双向邮件同步，从您的公司地址发送回复。
继续使用现有邮箱具有充分的实际理由。您的团队已经熟悉这个地址，客户也已经在使用它，而无需迁移的设置方式可以避免更改联系方式带来的干扰。Deskhero 可围绕您现有的邮箱，添加新工单自动化、SLA 政策、分配和报告功能。
第一步：确认您拥有该邮箱的管理访问权限。对于 Google 或 Microsoft，请通过 OAuth 连接。对于您拥有的其他域名，请配置 Deskhero 的 DNS 记录，并将收到的邮件转发到唯一的 Deskhero 地址。然后执行一次完整的发送和回复测试。
专业提示： 创建一个类似 support-test@yourdomain.com 的测试别名，并在那里完成首次设置。这样，在更改正式支持地址之前，您可以安全地检查邮件路由和回复效果。
要点总结
现有的 Gmail 或 Microsoft 365 邮箱无需迁移历史记录，就可以变成帮助台。关键工作在于选择正确的连接方式、测试收发邮件，并制定简单的责任归属流程。
| 要点 | 详情 |
|---|---|
| 无需迁移历史记录 | 连接该地址，让新对话变成工单，同时保留旧邮件在原位置。 |
| 连接方式很重要 | Deskhero 对 Google 和 Microsoft 使用 OAuth。其他自有域名则使用 DNS 记录加邮件转发。 |
| 责任归属可避免重复工作 | 将每个工单分配给一名 User，并在交接时使用私密备注。 |
| AI 需要安全护栏 | 发送前请审核建议回复。面向客户的 AI 仅根据获批准的公开 FAQ 作答。 |
| Deskhero 适合此路径 | Deskhero 提供 Google 和 Microsoft 双向同步、SLA 政策、自动化功能以及 30 天免费试用。 |
目录
- 如何将现有邮箱设置为帮助台
- 让邮件帮助台实现规模化运行所需启用的核心功能
- 如何确保回复来自您的公司地址
- 分流工作流和实用回复模板
- 时间安排、成本因素和实际价值
- 共享邮箱的安全与访问控制
- 如何安全地使用 AI 起草回复
- 需要跟踪的 KPI 和 SLA 框架示例
- 常见问题及解决方法
- 小型支持团队真正有效的做法
- Deskhero 让无需迁移的路径成为最快的路径
- 来源
- 常见问题
如何将现有邮箱设置为帮助台
请按以下顺序操作。每一步都建立在上一步的基础上。
- 验证邮箱和管理访问权限。确认支持邮箱处于启用状态，并确保管理员可以批准连接。
- 选择连接方式。Deskhero 通过 OAuth 连接 Google 和 Microsoft 邮箱。对于您拥有的域名上的其他地址，请添加所需的 DNS 记录，并将收到的邮件转发给 Deskhero。
- 保持个人访问权限。邀请每位支持同事成为 User，而不是共享邮箱密码。
- 将邮箱连接到正确的群组。每个 Deskhero 邮箱都会将工单路由到一个群组。邮件转工单指南介绍了常规工作流程。
- 确认发件地址。检查回复是否从客户已经熟悉的公司地址发出。
- 执行完整的发送和回复流程。从外部地址发送邮件，确认 Deskhero 创建工单，从 Deskhero 回复，并确保客户在原始线程中收到回复。
上线前测试清单：
- 分别从内部和外部地址发送测试邮件
- 附加一个 PDF 文件和一张图片，然后确认两者都显示在工单中
- 从帮助台回复，并验证发件地址
- 再次发送客户回复，确认它加入现有对话
专业提示： Google Workspace 和 Microsoft 365 管理员可能需要批准 OAuth 连接。如果授权失败，请先检查租户的应用访问策略，再更改邮箱设置。
让邮件帮助台实现规模化运行所需启用的核心功能
将邮件导入工单只是第一步。一组精简且有效的规则可以让收件箱在邮件量增加时仍然易于使用。
- 可靠的线程归组。测试真实的回复、转发和抄送收件人，以了解平台如何将对话归组。
- 清晰的分配。为每个活跃工单指定一名负责人，让所有人都知道下一次回复由谁负责。
- SLA 政策。根据人员工作时间和工单优先级，定义首次回复和解决目标。
- 新工单自动化。工单到达时，可使用发件人、主题、消息、语言或 AI 评估条件来设置群组、负责人、状态、优先级、标签或受支持的自定义字段。
- 回复手册。记录 User 在常见回复中应涵盖的事实和语气。支持邮件模板文章提供了可供调整的示例。
- 私密备注。当另一名 User 需要接手时，在工单中留下内部背景信息。
- 实用报告。在 Statistics 中查看工单量、响应时间、SLA 结果、渠道和团队活动。
如何确保回复来自您的公司地址
正确的设置取决于邮箱类型。Google 和 Microsoft 连接使用 OAuth，并提供双向同步。其他自有域名上的地址则使用邮件转发来接收邮件，并使用三条 CNAME 记录，让 Deskhero 能够从该地址发送经过身份验证的回复。
连接清单：
- Google：通过 Deskhero OAuth 流程连接 Gmail 或 Google Workspace 邮箱。
- Microsoft：通过 OAuth 连接 Microsoft 365 或 Outlook。Microsoft 共享邮箱在具备所需共享邮箱权限的情况下受支持。
- 其他自有域名：添加 Deskhero 显示的三条 CNAME 记录，然后将收到的邮件转发到唯一的 Deskhero 转发地址。
- 验证：使用邮箱验证测试，并在上线前完成一次外部发送和回复流程。
不要认为 IMAP 登录可以在 Deskhero 中提供持续同步。IMAP 可用于一次性导入，而不是作为实时邮箱连接。
专业提示： 保留设置过程中使用的确切 DNS 值和转发目标。如果之后邮件流发生变化，您可以将当前配置与已知可正常工作的值进行比较。
分流工作流和实用回复模板
一致的分流流程可以防止工单堆积而无人阅读。以下是一个实用流程：
新工单 → 应用新工单自动化 → 分配给一名 User → 发送首次回复 → 交接时添加私密备注 → 解决并关闭
可直接套用的起点：
- 首次回复：“感谢您联系我们。我们已收到您的请求，并会在[时间或日期]前向您更新进展。”
- 请求更多信息：“为了进行调查，请发送[具体信息]。请避免包含密码或完整的付款信息。”
- 交接：“我正在联系合适的同事。他们可以看到您已经提供的背景信息，因此您无需重复说明。”
- 确认解决：“我们已完成[操作]。如果问题仍在发生，请回复此邮件。”
请根据实际工单调整每一条回复。交接工作时，请添加私密备注，说明客户的问题、已经检查的内容以及下一步建议。
时间安排、成本因素和实际价值
| 阶段 | 退出检查 | 关键活动 |
|---|---|---|
| 邮箱连接 | 收发测试通过 | OAuth 或 DNS 设置、邮件转发、发件人验证 |
| 工作流设置 | 责任归属和路由清晰 | 群组、User、新工单自动化、优先级 |
| 服务目标 | SLA 政策与工作时间一致 | 首次回复目标、解决目标、工作时间安排 |
需要预留预算的成本因素：
- 活跃 User 和所选方案的订阅费用
- OAuth 审批、DNS 更改、邮件转发和测试所需的管理时间
- 分配、私密备注、升级处理和 SLA 管理所需的培训时间
需要衡量的价值：比较上线前后的首次回复时间、解决时间、重新打开的工单数量，以及每次解决所需的回复次数。请使用您自己的基线，而不要依赖通用的节省估算。
对于确实需要迁移历史记录的团队，Help Desk Migration提供无代码迁移服务。迁移项目与为新工单连接现有地址是两项不同的工作。
共享邮箱的安全与访问控制
- 个人账户：为每位 User 提供独立登录信息。不要共享邮箱密码。
- 特权账户启用 MFA：使用多因素身份验证保护邮箱和帮助台管理员账户。
- 最小权限访问：仅授予每个人所需的邮箱、群组和角色访问权限。
- 私密备注：将内部协作保留在工单中，而不是通过非正式渠道转发客户数据。
- 已验证的发件方式：使用受支持的 OAuth 或 DNS 流程，确保回复来自经过授权的地址。
- 附件处理：限制对包含敏感文件的工单的访问，并遵循组织的数据处理政策。
- 保留期限：根据合同、行业要求和法律建议设置保留规则。
专业提示： 每当有人更换职位或离开团队时，都要检查访问权限。停用该 Deskhero User，移除邮箱权限，并轮换任何在受支持连接流程之外共享的凭据。
如何安全地使用 AI 起草回复
Deskhero 将面向 User 的回复草稿建议与面向客户的自动回复区分开来。这一区别很重要，因为两项功能使用的知识范围不同。
- 建议回复：Deskhero 可以根据工作区知识起草回复，其中包括已回答的工单、内部知识、获批准的公开 FAQ 条目、抓取的网站页面、导入的问答内容以及已连接的 Shopify 产品。
- User 审核：User 可以接受、编辑或忽略建议。发送未经修改的建议需要额外确认。
- 面向客户的 AI：AI 自动回复和聊天机器人仅根据获批准的公开 FAQ 作答。
- 明确选择启用：自动回复按群组配置，聊天机器人按小组件启用。两者都要求至少有 100 条获批准的公开 FAQ 条目。
- 可见历史记录：自动回复会在工单时间线中标记并记录。
请从 User 审核的建议开始。在启用面向客户的 AI 之前，先构建并审核公开 FAQ，然后监控那些因 FAQ 未包含足够确定答案而重新转交人工处理的工单。
需要跟踪的 KPI 和 SLA 框架示例
邮件型帮助台的实用指标：
- 首次回复时间
- 解决时间
- 解决工单所需的回复次数
- 工单重新打开率
- 已创建与已解决的工单量
- 在 SLA 内完成首次回复的占比
以下目标仅供示例。请根据工作时间、人员配置和客户承诺设置您自己的数值。
| SLA 等级 | 首次响应目标 | 解决目标 |
|---|---|---|
| 紧急 | 1 小时 | 4 小时 |
| 标准 | 4 小时 | 24 小时 |
| 低优先级 | 8 小时 | 72 小时 |
在上线过程中应经常审核这些目标。Deskhero SLA 政策可以使用日历时间或每周工作时间安排；在等待客户回复时，解决计时器可以在选定状态下暂停。Deskhero Statistics 会将当前 SLA 风险与已完成的 SLA 达成情况分开显示，帮助团队避免将实时截止时间与历史结果混为一谈。
常见问题及解决方法
- OAuth 连接失败：请 Google Workspace 或 Microsoft 365 管理员检查应用访问和同意策略。
- DNS 邮箱无法发送：将三条 CNAME 记录与 Deskhero 提供的值逐一比较，并等待 DNS 传播后再重新验证。
- 两名 User 准备回复：处理工单前先完成分配，并检查对话中是否有最近的回复或私密备注。
- 连接需要处理：按照 Deskhero 中显示的邮箱状态操作。当 OAuth 邮箱提示需要身份验证时，请重新授权。
- 附件缺失：使用受支持的文件类型进行测试，并检查原始消息。如果问题仍然存在，请记录工单 ID 和文件详情，以便排查。
上线前调试清单：
- 邮箱状态处于启用状态
- 外部测试邮件创建一个工单
- 回复从预期的公司地址发送给客户
- 附件显示在工单中
- 新工单自动化应用预期的群组和优先级
- SLA 政策应用预期的截止时间
小型支持团队真正有效的做法
能够充分发挥邮件型帮助台价值的团队，通常会从一个小型且透明的工作流开始。连接邮箱、分配责任、定义升级路径，并在添加更多自动化之前测试完整的客户对话。
速度和控制可能会相互拉扯。只有在底层知识经过批准且保持最新时，快速的自动回复才有价值。User 审核的建议是更安全的起点，而审核公开 FAQ 则为之后面向客户的 AI 奠定基础。
在客户可以找到的地方公布支持时间和现实可行的响应目标。如果您并非持续提供支持，请在首次确认中明确说明，并且只根据实际覆盖的工作时间衡量表现。
前 30 天：User 培训重点：
- 交接时的分配和私密备注
- 回复标准以及何时进行个性化调整
- 升级路径和责任变更
- SLA 目标以及工作时间对其产生的影响
- 使用 Statistics 查看响应时间、SLA、渠道和团队活动
Deskhero 让无需迁移的路径成为最快的路径
大多数小型支持团队不需要新的邮箱地址，也不需要历史数据迁移项目。他们需要的是让现有地址收到的新邮件变成有组织、可分配的工单。
Deskhero通过双向 OAuth 同步连接 Gmail、Google Workspace 和 Microsoft 365。其他自有域名上的地址可以使用 DNS 记录加邮件转发。Deskhero 包含新工单自动化、私密备注、SLA 政策、Statistics、Google 和 Microsoft SSO、Shopify 客户面板以及 REST API 访问权限。建议回复会从工作区知识中提取内容，供 User 审核；而面向客户的 AI 仅根据获批准的公开 FAQ 作答。立即开始30 天免费试用，无需信用卡。
来源
常见问题
可以不迁移数据，直接将现有邮箱地址用作帮助台吗？
可以。Deskhero 通过 OAuth 连接 Gmail、Google Workspace 和 Microsoft 365，将新收到的邮件转换为工单，而无需移动邮箱现有的历史记录。自有域名上的其他地址则可以使用 DNS 记录加邮件转发。
要在其他自有域名上设置 Deskhero 邮箱，需要哪些 DNS 记录？
Deskhero 会提供三条用于身份验证发件的 CNAME 记录。添加这些记录后，将收到的邮件转发到唯一的 Deskhero 转发地址，并运行邮箱验证测试。
如何降低两名 User 回复同一工单的风险？
在开始处理前，将每个活跃工单分配给一名 User。检查对话和私密备注中的最新活动，并在责任发生变化时添加清晰的备注。
如何在邮件帮助台中安全地使用 AI？
从 User 审核的回复草稿建议开始。在启用 AI 自动回复或聊天机器人之前，请先批准并维护公开 FAQ，因为这些面向客户的功能仅根据获批准的公开 FAQ 内容作答。
设置邮件型帮助台需要多长时间？
所需时间取决于管理员审批、DNS 传播、工作流复杂程度和测试情况。在收发邮件、回复、线程归组、附件、分配、自动化和 SLA 行为均通过外部测试之前，不要正式上线。