将会话转换为工单
当工作必须在实时会话之外继续进行，或者需要明确的类型、状态、负责人或解决路径时，请使用工单。工单是对会话时间线的补充，不应重复每一条客户消息，也不应替代必要的回复。 本指南说明何时创建工单、如何记录可执行的上下文、主工单如何显示在 Inbox 中，以及发送并关闭或状态操作如何同时影响工单和交接状态。 这如何融入 Humind Inbox 是客户会话的运营记录。它结合了消息历史、购物者和产品上下文、内部协作、人工交接状态、标签和工单...
当工作必须在实时会话之外继续进行，或者需要明确的类型、状态、负责人或解决路径时，请使用工单。工单是对会话时间线的补充，不应重复每一条客户消息，也不应替代必要的回复。
本指南说明何时创建工单、如何记录可执行的上下文、主工单如何显示在 Inbox 中，以及发送并关闭或状态操作如何同时影响工单和交接状态。
这如何融入 Humind
Inbox 是客户会话的运营记录。它结合了消息历史、购物者和产品上下文、内部协作、人工交接状态、标签和工单。客户回复和内部备注在可见性上有意区分。
一致的团队工作惯例比任何单独的筛选器都更重要。请就何时接管、何时留下内部备注、何时创建工单以及何时将会话交还给 AI 达成一致，以便每位操作人员都清楚责任归属。
开始之前
访问权限：要从会话中开展工作，需要拥有 Inbox 访问权限。工单读取或写入操作遵循公司的工单权限和配置，提供商设置由管理员控制。
- 确认工单功能已启用，且预期的工单类型和状态已存在。
- 阅读会话、内部备注、标签以及现有主工单。
- 了解团队使用的是 Humind 工单功能还是已经过测试的外部提供商。
分步工作流程
判断是否需要工单
对于需要可跟踪跟进、需要其他团队参与、需要结构化生命周期，或需要在购物者离开后再解决的工作，请创建工单。如果操作人员可以立即回答并完成一个简单问题，就将其保留在会话中处理。
首先检查是否已存在主客户工单。针对同一问题创建多个工单会导致状态和责任归属不清。
创建可执行的工单上下文
使用会话中的工单操作，并选择公司配置提供的相关类型或初始状态。总结请求、已核实的事实、已完成的工作、客户预期以及下一步操作。
请链接到会话上下文或依赖该上下文，而不是将不必要的个人数据复制到自由文本中。对于不适合写入工单字段的团队成员推理，请使用内部备注。
维护状态和责任归属
在会话详情中查看主工单。随着调查变化更新属性，并一致地使用公司的状态类别。Humind 会将已配置状态映射到诸如 resolved 之类的类别，以供发送工作流使用。
如果工单保持打开状态但没有负责人或下一步操作，就不是可靠的交接。需要其他人采取行动时，请使用提及或团队的分配流程。
有意识地回复并关闭
当存在主工单时，回复发送菜单中可能会显示发送并关闭操作。该操作会发送客户回复，将工单移动到已配置的 resolved 类别状态，并将会话交还给 AI。发送菜单中的其他操作也可以更新工单状态。
点击前请阅读当前菜单标签和状态。关闭工单并交还给 AI 是相关但不同的结果，在此路径中会同时发生。
验证客户和操作人员的结果
确认购物者收到了预期消息，工单显示正确状态，线程责任归属正确，并且内部备注保持私密。如果有新信息到达，请根据政策重新打开或更新工单。
对于外部提供商，请在初始上线期间在提供商处验证对应记录。不要假设凭据开关就能保证端到端的工单同步。
权限和重要注意事项
- 工单类型和状态名称属于公司配置，请使用工作区中显示的当前标签。
- 发送并关闭可以在一次操作中同时更改工单状态和会话状态。
- 外部 Gorgias 或 Zendesk 的行为必须单独配置和测试。
- 工单属于内部运营工作，本身不会通知购物者处理进度。
验证结果
在认为工作完成之前，请使用此检查清单：
- 该工单代表真实的跟进需求，并且不会重复现有主工单。
- 摘要、类型、状态、负责人和下一步操作对另一位团队成员来说是可理解的。
- 最终客户回复、工单状态以及 AI 或人工责任归属与预期结果一致。
- 当外部提供商是工作流的一部分时，已验证该提供商中的记录。
故障排除
工单操作不可用
确认工单功能已启用，公司已具备工单类型和状态，并且您的角色拥有所需访问权限。请管理员检查提供商和 Inbox 配置。
发送并关闭使用了错误的状态
检查哪个已配置状态映射到了 resolved 类别。更正工单状态，并请管理员在操作人员再次使用该组合操作前修复状态配置。
外部提供商未收到工单
检查所选提供商、管理员凭据、公司上下文以及提供商自身的记录。在完整测试成功之前，请将该集成视为未经验证。