← Back to articles

自动翻译工单:支持团队设置指南

自动翻译工单:支持团队设置指南

是的,您可以自动翻译工单,让客服人员无需切换工具或招聘双语员工,就能使用自己偏好的语言阅读和回复。翻译发生在工单层级:系统会自动检测收到的消息并进行转换,客服人员也可以在发送前翻译自己的回复。

在修改任何设置之前,请先检查以下三件事:

  • 确认您的管理员角色。翻译设置位于管理面板中,而不是客服视图中。客服人员可以触发单个工单的翻译,但只有管理员能够在整个组织范围内启用此功能。
  • 确认您的翻译引擎。大多数帮助台会连接外部 API(Azure、Google Translate 或浏览器托管模型),或者内置原生机器翻译引擎。在进行配置之前,请先了解您的平台使用的是哪一种。
  • 检查支持的语言列表和配额。并非所有语言对都可用,而且大多数引擎都会执行单次请求或每月输入配额限制。超出配额可能会导致翻译被静默丢弃。

核心要点

当管理员进行有计划的配置、按语言对监控准确率,并让客服人员能够控制每次对话的覆盖设置时,自动工单翻译的效果最佳。

要点 详情
先完成管理员设置 在客服人员看到任何已翻译工单之前,先在管理面板中启用翻译、验证 API 访问权限并设置日志记录。
从按需翻译开始 在整个组织切换到完全自动翻译之前,先针对 2–3 个语言对进行按需试点。
监控配额和准确率 将输入量与您的配额等级进行对比,并每月抽样检查 20–30 个已翻译工单,以便尽早发现质量下降。
术语表可减少后期编辑工作 一份包含 20–30 个产品名称和法律术语的简短列表,可以避免客服回复中最常见的翻译错误。
Deskhero 支持 14 种语言 Deskhero 的多语言支持将翻译整合到工单工作流中,并将 AI 回复草稿限制在已批准的知识范围内。

目录

自动工单翻译能为您的客服团队做什么

帮助台中的自动翻译涵盖四项不同功能:检测收到的语言、将工单正文转换为客服人员使用的语言、将客服回复翻译回客户使用的语言,以及记录翻译事件以用于审计和质量保证。

展示自动翻译工作流步骤的示意图

它带来的运营收益是切实的。客服人员不再需要等待双语同事审核工单后才能回复。由于客服人员能够真正读懂客户的问题,首次联系解决率会得到提升。您也可以避免将每一张非英语工单都转交给专门队列所产生的成本。Phrase 关于多语言客户支持的研究建议将实时机器翻译与质量保证层和翻译管理系统结合起来,以便在大规模运行时保持质量一致。

这些权衡也值得提前说明。机器翻译在处理简短消息、习语、品牌专用术语和混合语言文本时容易出错。某些语言对的准确率低于其他语言对。而且,如果您的业务量突然增加,可能会触及配额限制,导致翻译延迟或完全跳过。Google Translate展示了大多数实现所遵循的标准源语言到目标语言流程,可为您了解任何 MT 引擎的预期表现提供有用基准。

客服工作流如下:工单到达后,系统检测语言,将正文翻译并与原文并排显示,客服人员起草回复,系统在发送前翻译该回复。每个步骤都可以记录。

如何启用自动翻译——管理员设置与配置检查清单

在打开开关之前,请逐项完成以下检查:

  1. 确认 API 访问权限或引擎可用性。如果您的平台使用外部 API(例如 Azure Cognitive Services),您需要有效的 API 密钥和有效订阅。Azure 语言服务文档介绍了如何在进行检测和翻译调用之前验证 API 是否可用。对于基于浏览器的翻译,Translator and Language Detector APIs要求先进行可用性检查,之后才能使用模型。
  2. 设置默认客服语言。这是客服人员查看翻译内容时所使用的语言。如果设置错误,客服人员收到的翻译就会使用错误的语言。
  3. 选择自动翻译还是按需翻译。自动翻译会立即翻译每一张收到的工单。按需翻译则要求客服人员点击翻译按钮。在试点期间,建议从按需翻译开始,以便客服人员比较原文和译文。
  4. 启用外发翻译。在大多数平台中,这是一个独立的开关。它决定客服回复是否会在发送前进行翻译。如果客服人员已经使用客户的语言撰写回复,请将其关闭。
  5. 启用按渠道翻译。电子邮件、聊天和网页表单渠道通常拥有独立的翻译开关。只启用您正在试点的渠道。
  6. 配置日志记录和事件捕获。确保翻译事件会写入工单时间线或审计日志。质量保证和故障排查都需要这些记录。
  7. 设置保留规则。译文会与原文一同存储。请确认您的数据保留政策涵盖翻译文本,尤其是在工单包含个人身份信息(PII)的情况下。

专业提示:在整个组织范围内上线之前,使用专用的客服测试账号测试 3–5 个语言对。使用每种语言发送看起来真实的工单,并确认译文易于阅读,同时确认回复翻译能够正确到达测试客户地址。

语言检测的工作原理,以及如何纠正错误检测的语言

工单到达时,系统会自动运行检测。引擎会分析文本,分配语言代码(通常是 BCP-47 标签,例如西班牙语使用 es,简体中文使用 zh-Hans),并附加置信度分数。如果分数超过阈值,系统就会继续翻译。如果未超过阈值,工单可能会被标记为需要人工审核,或保持未翻译状态。

常见故障模式包括:

  • 消息过短。一张只有两个词的工单(“订单缺失”)几乎没有足够信息供检测器分析。置信度分数会降低,并可能被分配错误的语言。
  • 混合语言文本。客户使用英语书写,却粘贴了一条法语错误消息,这会让大多数检测器感到困惑。
  • 品牌名称和俚语。产品名称、缩写和非正式拼写可能会使检测结果偏向错误的语言。

当检测结果错误时,客服人员有三种选择:手动覆盖检测出的语言;在补充上下文后强制重新检测(例如请求客户提供更多细节);或者使用独立工具手动翻译工单。大多数平台都会在工单上提供“语言”字段,客服人员可以直接编辑。

对于开发者级别的实现,MDN 的 Translator and Language Detector APIs 指南介绍了 detect() 方法、配额检查以及如何处理不可用的模型。在不同系统之间映射语言时,ISO 15924 脚本代码有助于避免多系统设置中的区域设置不匹配。

专业提示:在触发自动检测之前设置最低字符数阈值(通常为 20–30 个字符)。低于该阈值时,要求客服人员先确认检测出的语言,再运行翻译。这一项改动就能消除大多数错误检测。

按工单或对话管理翻译

客服人员需要细粒度控制,而不只是一个组织级开关。您应该提供的标准工单级控制包括:

  1. 按需翻译。客服人员点击按钮即可翻译特定消息。当自动翻译关闭,或消息使用了系统未检测出的语言时,这项功能非常有用。
  2. 按对话设置自动翻译开关。客服人员可以关闭特定工单的自动翻译,而不会改变全局设置。在法律、合规或升级处理场景中,这项功能至关重要,因为这些场景要求完整保留原文。
  3. 查看原始消息。客服人员应始终能够查看未经翻译的源文本。绝不要隐藏原文。人们会对准确性产生疑问,而客服人员需要通过原文进行核实。
  4. 回复翻译开关。控制客服人员发出的回复是否会在发送前进行翻译。如果客服人员本来就在使用客户的语言撰写,应关闭此开关。

以下情况应关闭某个对话的自动翻译:法律争议(准确措辞很重要)、包含合同或受监管语言的工单,以及由母语客服专家接手的升级工单。

管理员级控制决定客服人员是否可以覆盖这些设置。在某些配置中,管理员会锁定特定队列中所有工单的翻译功能。其他配置则允许客服人员完全控制每个对话。合适的平衡取决于团队的语言覆盖能力以及工单类型的风险状况。

控制项 设置者 使用时机
组织级自动翻译 管理员 所有收到工单的默认设置
按对话设置开关 客服人员(如果管理员允许) 法律、合规或母语客服升级处理
查看原文 客服人员 准确性核验、质量保证抽样
回复翻译开关 客服人员 客服人员已经在使用客户的语言撰写回复

在发送前翻译客服回复

先审核再发送的工作流是更安全的默认方式:客服人员用英语起草回复,点击“翻译”,审核译文,必要时进行编辑,然后发送。自动发送(即回复经过翻译后无需客服人员审核便直接发送)只有在经过数周生产流量验证、确认某个特定语言对的准确率后才适合使用。

准备在平板电脑上审核译文回复的双手

预览译文只需几秒钟,却能发现最常见的问题:产品名称翻译错误、正式或非正式语体不匹配,或者某个短语在目标语言中读起来显得无礼。客服人员不需要会说目标语言,也能发现这些问题。他们只需要了解回复本来要表达的内容,再使用 Google Translate 等参考工具对照译文进行快速合理性检查。

术语表在这里能带来可衡量的差异。一份包含产品名称、功能标签和法律短语的简短列表,可以规定哪些内容绝不应翻译,或始终以特定方式翻译,从而显著减少后期编辑工作。Phrase 正是出于这一原因,建议将 MT 与翻译管理系统和术语表结合使用。如果您的平台支持 TMS 集成,请将其连接起来。如果不支持,一份包含 20–30 个高频术语的共享团队文档也能带来大部分收益。

专业提示:让客服术语表保持简短且具体。与其使用一份包含 200 个条目、客服人员会忽略的术语表,不如使用一份包含 20–30 个不得更改的产品名称、法律术语和品牌短语的列表。每季度审核一次,并在某个翻译错误反复出现时添加相关术语。

已知限制、美国数据隐私注意事项与翻译质量控制

准确性限制。简短消息、习语和特定领域术语是 MT 持续表现不佳的地方。除非先运行 OCR,否则大多数引擎不会翻译附件(截图、PDF)。在软件环境中,“小组件一直在转圈”这张工单所表达的含义,与字面翻译所暗示的含义可能大不相同。

配额和性能限制。Chrome Translator API 文档所描述的浏览器托管翻译模型会将模型下载转移到客户端设备,从而降低服务器端计费,但也会引入下载延迟以及设备级可用性限制。服务器端 API 设有单次请求和每月输入配额。MDN 的 Using 指南明确介绍了如何在翻译前测量输入用量,以及如何处理 QuotaExceeded 错误。对于高业务量团队,应先测量平均工单字符数,再乘以每月工单量,然后决定配额等级。

美国数据隐私。翻译后的工单内容由第三方引擎(Azure、Google 或其他提供商)处理。这意味着客户 PII 会传输到外部系统。在启用翻译之前,请确认您与翻译提供商签订的数据处理协议涵盖适用美国框架下的使用场景。检查译文存储在哪里、保留多长时间,以及是否会被用于训练提供商的模型。某些企业协议包含禁止训练条款。

风险领域 检查内容 缓解措施
译文中的 PII 与翻译提供商签订的 DPA 使用包含禁止训练条款的提供商
译文保留 平台保留设置 与现有工单保留政策保持一致
超出配额 每月输入量与配额等级的对比 在上线前预先测量并升级配额等级
低准确率语言对 按语言查看试点结果 将低准确率语言对转交人工审核

专业提示:每月进行一次质量抽样:从主要语言对中抽取 20–30 个已翻译工单,让母语人士或双语客服人员使用简单的 1–3 分制评估准确率。持续跟踪分数。平均分下降,是翻译引擎发生变化的最早信号。

上线检查清单、监控指标与常见故障排查步骤

分阶段上线可以显著降低风险;对于希望了解翻译模型如何优先处理措辞和引用的团队,使用 BabyLoveGrowth AI Search Visibility Test 可以提供有价值的洞察。请按以下顺序执行:

  1. 选择试点小组。挑选 3–5 名处理非英语工单量最高的客服人员。他们会比大范围上线更快发现问题。
  2. 仅为 2–3 个语言对启用翻译。从业务量最高的非英语语言开始。试点稳定后再添加更多语言。
  3. 开启日志记录。每个翻译事件都应写入工单时间线。没有日志,故障排查只能靠猜测。
  4. 培训客服人员使用工单级控制。客服人员需要知道如何查看原文、覆盖检测结果,以及关闭某个对话的翻译功能。一次 15 分钟的讲解胜过一份书面文档。
  5. 制定回滚计划。明确需要恢复哪些设置,以及谁拥有执行操作所需的管理员权限。在正式上线前记录下来。
  6. 在试点数据稳定运行两周后扩展。如果翻译命中率、置信度分布和客服反馈表现良好,就添加更多语言对和客服人员。

需要监控的指标:翻译命中率(成功翻译的非英语工单占比)、置信度分数分布(标记所有低于阈值的结果)、已翻译工单与未翻译工单的首次回复时间,以及客服人员提交的翻译错误报告。

常见故障排查:

  • 缺少翻译:检查渠道(电子邮件、聊天、表单)是否已启用翻译。检查 API 密钥是否有效。检查配额。
  • 检测出的语言错误:检查工单字符数。如果低于您设置的阈值,说明检测行为符合设计。提高阈值,或要求客服人员进行确认。
  • 超出配额:MDN 的 Using 指南介绍了 QuotaExceeded 的处理方式。升级配额等级,或实施带延迟的批处理。
  • 翻译延迟:基于浏览器的模型可能需要在首次使用前下载。Chrome Translator API 介绍了这种下载行为。对于服务器端 API,请在提供商的控制面板中检查延迟。

Deskhero 如何处理自动工单翻译

Deskhero 的多语言支持覆盖 14 种语言,并将翻译直接整合到工单工作流中。通过电子邮件、网页表单或 AI 聊天机器人收到的工单都会在共享收件箱中处理,客服人员无需离开平台即可查看和回复译文内容。

Deskhero 与独立 MT 集成不同之处在于其知识限制。AI 仅使用您批准的内容来起草回复:已解决的工单、知识库文章,以及经过客服人员确认的网站页面。这意味着翻译后的回复草稿不会产生幻觉。如果 AI 没有经过批准的答案,它会将问题转交人工,而不是自行编造答案。对于多语言支持而言,这一点很重要,因为客服人员无法阅读的语言中的幻觉答案,只有在客户投诉后才可能被发现。

Deskhero 试点的建议设置:

  • 在管理面板中启用多语言支持,并选择目标语言。
  • 连接您的 Gmail、Google Workspace 或 Microsoft 365 邮箱。双向同步意味着回复仍会从您自己的域名发出。
  • 开启 AI 回复草稿,在启用自动发送选项之前,先手动审核前 50 份翻译草稿。
  • 使用工单洞察地图,确定哪些语言对产生的工单最多,并将术语表工作重点放在这些语言对上。

如果您的团队有超出默认配置的特定路由或日志记录要求,可以使用 REST API 构建自定义翻译工作流。对于运行 AI 客户服务的团队,Deskhero 的日志记录和事件捕获功能能够提供质量保证所需的审计轨迹。

专业提示:在为某种目标语言启用 AI 回复草稿之前,先在 Deskhero 中批准该语言的一小组已解决工单。AI 会从已批准的内容中获取信息,因此使用西班牙语、法语或德语中真实且准确的已解决工单进行初始化,可以立即为 AI 提供工作基础。

大多数指南都会跳过的自动翻译上线环节

大多数实施指南都将自动翻译视为二元选择:开启或关闭、正常或故障。更棘手的问题是中间状态:翻译在技术上正常运行,却以无人察觉的方式悄悄降低质量,直到客户升级投诉时才被发现。

能够从多语言支持自动化中获得最大收益的团队,会把翻译准确率视为自己负责的指标,而不是供应商的责任。这意味着要定期抽样检查已翻译工单,而不仅仅是在出现故障时才检查。这意味着要让客服人员能够直接在工单中轻松标记糟糕的翻译,而不是依赖一个无人填写的独立反馈表。还意味着要诚实判断哪些语言对的质量足以支持自动发送,哪些语言对在内容发出前仍需要客服人员审核。

另外还需要强调:对于复杂或敏感工单,自动翻译不能取代母语人士的判断。在混合模式下,由 MT 处理常规咨询,由双语客服人员或专家处理升级问题,其客户满意度始终优于完全自动化。目标是利用翻译消除常规业务量带来的瓶颈,而不是彻底消除人工判断。

Deskhero 让多语言支持从第一天起就变得简单直接

大多数团队需要花费数周时间集成翻译 API、配置语言对并调试配额错误,之后才会有第一张已翻译工单到达客服人员手中。Deskhero 完全跳过了这些设置。连接现有的 Gmail 或 Microsoft 365 邮箱,在 14 种语言中启用多语言支持,您的团队当天就能开始阅读和回复已翻译工单。

Deskhero

AI 仅根据已批准的知识起草回复,因此翻译后的响应能够保持准确并符合品牌风格,无需客服人员反复猜测。每个翻译事件都会被记录,每个自动化操作都会被标记;除非您主动选择启用,否则不会自动发送任何内容。无需信用卡即可开始30 天免费试用,本周就运行您的第一个多语言试点。

来源

常见问题

如何为支持工单开启自动翻译?

进入帮助台管理面板,找到翻译或语言设置部分,确认翻译引擎已连接,然后为目标渠道启用自动翻译。在整个组织范围内启用之前,先使用小规模试点小组进行测试。

帮助台最好用的自动翻译工具是什么?

合适的选择取决于您的语言对和业务量。Azure Cognitive Services 和 Google Translate 等服务器端 API 覆盖最广泛的语言范围。浏览器托管模型(Chrome 的 Translator API)可以降低服务器成本,但依赖设备可用性。Deskhero 将覆盖 14 种语言的多语言支持直接整合到工单工作流中。

AI 翻译工具对客服团队来说要多少钱?

价格因引擎和业务量而异。服务器端 API 通常按字符数或请求次数收费,因此成本会随工单量增加。浏览器托管模型将处理过程转移到客户端设备,从而减少直接的 API 费用。Deskhero 将多语言支持包含在订阅中,因此无需单独管理翻译 API 费用。

客服人员可以纠正错误的语言检测结果吗?

可以。大多数平台都会在工单上提供语言字段,客服人员可以直接编辑。纠正语言后,客服人员可以手动触发重新翻译。在自动检测运行前设置最低字符数阈值(20–30 个字符),可以在错误检测到达客服人员之前阻止大多数错误结果。

超出翻译配额后会发生什么?

翻译请求会静默失败或返回错误,工单可能会显示为未翻译状态。MDN 的 Using 指南介绍了 QuotaExceeded 错误的处理方法。请预先测量每月工单的字符总量,并在上线前升级配额等级,以避免此类问题。