远程协助

远程协助是 Servify 当前产品叙事里最应该被明确强调的差异点之一。

很多客服系统可以做到：

• 在线聊天
• FAQ 或机器人问答
• 工单流转

但在真实服务过程中，很多问题并不是“回复一段话”就能解决，而是需要：

• 一步步指导客户完成操作
• 和客户一起定位问题
• 在同一个上下文里持续协作

Servify 把这类能力理解成产品层面的 远程协助，而不是只把它视为底层实时通信能力。

一句话定义

在 Servify 里，远程协助指的是：

• 客服在同一条会话里，把服务从“文字解释”升级到“实时指导、联合排查和继续接管”
• 协助结束后，上下文还能继续留在人工协作、转接和工单闭环里

它强调的是连续服务链路，而不是单独强调某个协议名词。

远程协助解决什么问题

典型场景包括：

• 客户不会操作某个功能，需要被引导完成
• 客户描述不清楚问题，需要边看边确认
• 售后支持或技术支持需要协助排查
• 内部服务台场景中，需要协助同事完成配置或定位故障

如果系统只能聊天，客服流程就会停留在“发消息解释”；如果有远程协助，客服就能进入更接近真实服务过程的状态。

在 Servify 里的位置

Servify 当前产品主链路可以这样理解：

Web 接入 -> AI 首答 -> 远程协助 -> 人工接管 -> 转接协作 -> 工单闭环

这并不意味着每一次会话都必须进入远程协助，而是表示：

• 当文字沟通足够时，可以停留在 AI 或人工回复
• 当问题需要演示、指引或联合排查时，可以升级到远程协助
• 当问题无法即时解决时，再进入工单继续跟进

也就是说，远程协助位于“实时接待”和“异步处理”之间，是客服流程中非常关键的一层。

当前产品表达

在产品层面，远程协助应该被表达为：

• 帮助客户更快完成操作
• 让客服从“解释问题”变成“带着解决问题”
• 让复杂问题仍然留在同一条服务链路里，而不是跳到别的工具中断上下文

在技术实现层面，Servify 当前已经具备与远程协助相关的实时能力基础，包括 WebSocket / WebRTC 相关链路，但文档和产品表述不应把重点只放在协议名词上。

当前仓库里已经有什么

当前可以明确对外表达的基础包括：

• Web 会话、消息和实时接待链路已经存在
• AI 首答、人工接管、转接协作和工单流转都已纳入同一产品主链路
• WebSocket / WebRTC 相关 runtime、统计和连接视图已经在代码与验收中出现
• 文档与 README 已明确把远程协助放在 AI 首答 -> 人工接管 -> 工单闭环 之间，而不是孤立的底层模块

当前不应超前承诺的内容包括：

• 已交付完整的 co-browsing / 屏幕共享产品界面
• 已完成客服管理端的专门远程协助工作台
• 已完成端到端的标准化演示剧本和产品验收口径

这些属于后续 Gap C 继续收口的范围，而不是当前仓库已经兑现的事实。

当前入口与缺口盘点见：

• 远程协助现状盘点
• 远程协助最小可交付链路

与 AI、人工、工单的关系

远程协助不是独立孤岛，而是和其他核心能力一起工作的：

• AI 可以先做首答和澄清，减少人工介入成本
• 人工在需要时接管，并发起远程协助
• 协助后仍可继续转接给更合适的处理人
• 无法即时收口的问题可以沉淀为工单继续推进

这样，客服系统才不只是“聊天工具 + 工单工具”，而是一套连续的服务产品。

当前阶段的判断

Servify 在这件事上已经有方向和基础，但后续还有两个重点要继续加强：

• 把远程协助继续做成更明确的产品能力，而不是只藏在底层实时模块里
• 在文档、官网和产品叙事中持续把它讲清楚，形成真正的差异化认知

下一步更具体地说，需要继续补三件事：

• 管理端和服务端当前到底有哪些可直接使用的远程协助入口
• 最小可交付链路应该如何从 Web 会话升级到人工协助再进入工单
• 一条可以复用的演示和验收口径，而不是只验证底层 WebRTC / WebSocket 可用