帮助台 & 工单
录制会作为内部备注添加到客服已经打开的工单上，而非新建无人发起的请求。
1. 此功能首先必须回答的问题
哪张工单？
每个已识别会话都创建工单会造成垃圾信息：支持团队会看到无人发起的请求。给此人曾提交的每张工单都添加备注，同样是垃圾信息，只是更慢。
因此： 在发送者最新的未解决工单上添加一条内部备注。 如果没有未解决工单，就完全不执行操作。这样绝不会创建客户未发起的请求，客服也能在已经查看的位置找到录制。
仅供内部使用，绝不公开。 链接通向 MousePlayer。客户不应看到它，本来也无法访问。
2. Zendesk Support 与 Freshdesk
两者均受支持，以不同方式完成同一任务。无需关心差异，但这解释了表单为何询问略有不同的信息。
| Zendesk Support | Freshdesk | |
|---|---|---|
| 子域名 | acme 取自 acme.zendesk.com | acme 取自 acme.freshdesk.com |
| 客服电子邮箱 | 必填，Zendesk 以此身份登录： email/token | 不需要，留空 |
| API 令牌 | 管理中心 → 应用和集成 → API | 个人资料设置 |
| 备注形式 | 工单上的内部评论 | 工单上的私人备注 |
如果更方便，可在子域名字段粘贴完整 URL，我们会提取所需部分，因此 https://acme.zendesk.com/agent/tickets/1 会变为 acme。
3. 何时触发
会话被识别的那一刻：网站调用 MousePlayer.setUserId()、分析桥接读回 distinct ID，或服务器调用 identify 端点时。
仅限电子邮箱地址
工单属于发送者，帮助台通过电子邮箱识别发送者。合同编号无法匹配，因此不会发送任何内容。
仅限未解决工单
跳过已解决和已关闭的工单。在无人再查看的请求上加备注无益于任何人，而且会无缘无故地让已关闭工单重新进入客服视野。
发送者没有未解决工单时，计为已完成，而非失败；这是正常情况，重试不会改变任何结果。
4. 客服看到什么
一条内部备注： MousePlayer：来自 <email> 的会话录制 随后是链接。只需点击一次，就能在此人的文字描述旁观看其实际操作。
价值体现在哪里
- “无法使用”的工单。 录制通常只需二十秒，就能展现三轮邮件也解释不清的情况。
- 无人能够复现的重现步骤。 不再需要这些步骤，因为已有会话。
- 愤怒点击与无响应点击 客户从未提及，因为以为产品本来如此。
令牌始终保留在我们的服务器内
以 AES-256-GCM 加密存储，保存后不再显示，并刻意不放入承载任务的内部队列。
5. Help Scout、Front 与 Gorgias
又增加了三种帮助台。三者都在未解决对话上添加内部备注，但实现路径各不相同。
| 需要提供 | 子域名 | |
|---|---|---|
| Help Scout | 内部应用的客户端 ID 与客户端密钥 | 不需要 |
| Front | API 令牌与团队成员 ID | 不需要 |
| Gorgias | 客服电子邮箱与 API 密钥 | 需要 |
Help Scout 先交换，再通信
它不直接接受客户端密钥。桥接先将其交换为短期访问令牌，即客户端凭据流程，适用于集成为自身而非代表用户操作。令牌在有效期内保留于内存；密钥留在数据库。
Front 评论需要作者
Front 中的评论以某个团队成员名义显示，API 必须提供该成员。这里标记为客服的字段保存的就是此 ID，不是登录名，而是备注署名者的 ID。
Gorgias 需要查询两次，而非一次
其工单列表只能按 customer_id 筛选，不能按电子邮箱筛选。因此桥接先查找客户，再查询其工单。它也无法按状态筛选，所以未解决工单由我们这边选择，与 Freshdesk 已有的处理方式完全相同。
此处提及的所有商标均属于各自所有者。MousePlayer 与这些提供商不存在商业关系。