去哪儿网网络电话的探索与落地

　　一、前言
　　作为一家技术先进的在线旅行平台，我们一直追求为用户提供更好的服务。售前和售后咨询是其中重要的环节。目前，公司业务对外提供的咨询服务渠道主要是公司热线电话95117和 Chat。虽然这两个渠道几乎承担了全部用户反馈，但存在以下几个问题：  电话进人工链路过长，影响用户体验。  进线锁单率低，客服处理时间长，成本高。  电话只能语音沟通，效率不高，花费用户电话费。  Chat 沟通需要频繁打字，有些用户更喜欢直接电话沟通。  受运营商限制，境外游用户只能通过办理境外卡或者开通国际漫游方式拨打客服电话，不方便。
　　这些问题直接或间接增加了公司的服务成本和用户使用成本，影响了用户体验和处理问题的效率。
　　基于以上问题，我们尝试为用户提供一个新的咨询服务通道——网络电话。网络电话是一种通过将模拟信号数字封装，以数据封包的形式在互联传递，端对端实现语音传输的通话方式。只要有网络，用户就可以拨打电话，而没有任何运营商和区域限制。
　　当然，基础网络电话仅仅是通过网络通话，并不能解决客服压力大和沟通效率低的问题。因此，我们考虑赋予它更多的功能：  加强订单指引，提高锁单率，缩短进入人工客服链路，提高用户体验。  转人工前支持机器人引导用户自助解决问题，提高自助率，分担人工客服压力。  转人工后支持同屏操作，提高沟通效率。
　　为了能为更多的用户提供服务，我们希望网络电话功能可以同时支持 APP 客户端和 web 端多个场景。  二、App端方案调研
　　经过分析上面的设计图中的 UI 交互和功能类型，我们将项目分为两个部分：  基础能力部分，包括语音播报、语音通话服务、拨号、耳机及蓝牙等相关操作。  业务交互部分，包括订单管理、机器人自助等功能。
　　在考虑基础能力部分时，我们发现语音服务的开发和投入成本相对较高，而目前市面上已有许多成熟稳定的语音服务供应商，因此我们选择了第三方语音服务供应商。在选择供应商时，我们主要考虑接入成本、扩展成本以及资费成本等因素，以满足各团队的不同需求。
　　由于需要接入第三方网络电话服务商的 SDK，并且客户端需要使用本地 API，如麦克风、音频控制和蓝牙等，因此使用 Native 实现更为方便。然而，全部采用 Native 实现可能会导致应用程序体积过大且功能迭代更新需要发布新版本，灵活性较差。
　　由于这是一个需要快速迭代的项目，我们的目标是尽快找到适合去哪儿用户习惯的、方便用户操作的交互方式。因此，使用纯 Native 开发的迭代周期无法满足我们的需求。相反，业务交互部分需要具备跨平台能力和热更新能力，以便我们能够快速且持续地迭代升级。
　　经过综合评估和优缺点比较，我们决定采用 Native + React Native 的开发方式。其中，Native 负责基础能力部分，React Native 负责业务交互部分。
　　客户端Native和RN模块功能划分如下：
　　Native 主要承载音频管理、语音播报、后台服务、通话连接拨号、短流程支持以及悬浮窗管理等功能；
　　RN 主要负责业务相关逻辑，包括订单管理、机器人自助以及人工同屏功能。  三、APP端整体方案设计网络电话的整体交互结构如下：
　　整个网络电话的流程首先是由用户主动发起拨号操作，通过 complain 会话服务在中间协调在公有云上创建通话房间，由 sip 服务和呼叫中心进行交互，实现网络语音和电话通话之间的转换，最终将呼叫中心的外呼电话分配给对应的人工客服坐席，实现用户和客服之间点对点的语音通话。  机器人自助以及短流程
　　我们的重要目标之一是提高用户自助率，从而减轻人工客服的压力。为了实现这个目标，我们提供了机器人自助功能。
　　用户可以选择想要咨询的订单，如果是从订单 D 页进来，订单信息将会自动带入。根据订单信息和状态，智能机器人会动态地向用户推荐相关性强且常见的问题，以便用户快速选择。
　　当然，用户也可以自行输入想要咨询的问题。我们拥有强大且全面的资料库，可以根据用户的问题提供最佳的答案。
　　除了使用智能机器人来自动解答用户的问题外，我们还提供了一些常见流程的自助操作，例如索要行程单、开发票和支付等。完整流程如下图所示：
　　用户可以在界面上看到自助操作的步骤和相关提示，按照提示操作即可完成流程，无需等待客服人员的回复和操作。这不仅提高了用户的满意度和体验，也减轻了客服人员的工作压力，实现了双赢的效果。同时，我们也不断优化自助操作的流程和指导信息，让用户更加方便快捷地完成相关操作。  人工同屏
　　上述自助操作的过程能够解决用户大部分简单的问题，如果仍然无法解决问题，可以选择转人工进行人工客服咨询。但是在旅游旺季时，用户需求激增，咨询客服的场景变得更加普遍，会导致客服资源非常紧张。
　　本着降低用户操作的难度，提高用户满意度和忠诚度的目标，优化咨询服务流程，提高客服的服务效率，变得尤为迫切。为此，我们开发了人工同屏功能，主要解决以下痛点：
　　1. 在电话语音沟通过程中，客服需要与用户确认关键信息，在语言描述和核对文字的过程中经常会有理解上的差错。
　　2. 在网络电话中需要提交图片证明材料的，用户需要在电话挂断后上传，无法在通话中确认上传的内容是否有问题，造成多次进线沟通。
　　3. 从客服下发上传文件的方式到用户上传信息，整体的平均时长为20分钟左右，时间成本过大；
　　＂人工同屏＂是指在网络电话通话的过程中，用户和客服之间可以进行一些非语音信息的交互，用户侧发送的一些文本和图片可以实时地在客服侧同步。
　　当用户使用网络电话进入人工客服对话后，会与客服坐席之间建立长连接通道，该通信方式基于 websocket 实现，用户所有发送的内容均可在客服侧同步展示。
　　客服坐席工单页面用户发送消息展示：
　　前后端整体通信结构图：
　　＂人工同屏＂提供了基础图文交互能力，可以理解为是一个微型 IM 应用的内嵌，对于核对信息及图片证明等材料是否适用等场景，在一通＂会话＂中完成所有服务与材料提交成为了可能，客服人员可以根据用户的操作情况，提供更加精准的指导和解答，避免了因为双方理解不一致而导致的沟通障碍以及错误操作，也解决了通话结束后材料上传提交流程繁琐的问题。
　　同时，人工同屏功能还可以帮助客服人员更好地了解用户的需求和痛点，以便在后续的服务中更加针对性地进行推荐和解答。这样可以提高客服的服务质量和用户的满意度。沟通记录也会同步至工单日志对应模块，便于后续过程追溯和梳理。
　　总之，我们通过智能机器人和自助操作、人工客服和人工同屏等多种方式，为用户提供了全方位、多层次的服务支持，以满足不同用户的需求和习惯，提高用户体验和服务效率。  易用性提升
　　为了方便用户在拨打语音电话的过程中不影响其他操作，我们支持网络电话悬浮窗收起功能。
　　用户可以在拨打网络电话时，点击悬浮窗的收起按钮，将网络电话悬浮窗收起，此时可以继续进行其他操作，如浏览产品信息、查看订单信息等。当需要恢复网络电话时，用户可以通过通知栏或者悬浮窗入口进入网络电话界面，继续进行通话或者查看通话记录等操作。总之，网络电话悬浮窗收起功能是为了方便用户在通话过程中进行其他操作，同时保证通话的顺利进行。我们会不断优化相关功能，为用户提供更加便捷的网络电话服务。
　　与传统电话依赖基站信号相比，网络电话比较依赖网络的稳定性，那么当前的网络上下行的质量决定了用户当前通话是否流畅，因此我们在界面上给用户提供了直观的网络异常状态提醒，以便用户发现自己网络状态不佳时及时调整，不影响与客服的通话。
　　同时，我们也将用户侧的网络状态实时同步至服务器，同时在客服侧展示用户的当前通话质量，以便客服根据用户当前的通话状态做出正确的判断，给予用户最佳的服务。
　　网络电话-web端
　　我们的网络电话功能在去哪儿客户端 APP 上线后，收到了良好的用户反馈。为了让 PC/H5/小程序三端功能保持一致，我们在 Web 端实现了网络电话服务，并采用了一套代码三端复用的方法，保持了 UI 展示与 native 端一致，所有功能均由 Web API 开发实现。
　　我们将网络电话的主要功能分为三个交互场景：  自助服务– http(s)  IM 图文- WebSocket  语音通话- WebRTC
　　并针对不同的业务场景采取不同形式的通信和数据传输方案，将分散的服务能力聚合到一起，提高了整个系统的协同性和利用率。
　　在开发过程中，我们也遇到了一些问题需要解决。例如，内置的语音提示音频资源可能会因网络或设备限制而出现延迟或卡顿。为了解决这个问题，我们使用 Web Audio API 提供的缓冲机制，预加载音频并在播放前进行解码，以提高语音提示的流畅性和及时性。
　　另一个问题是 autoplay 属性失效，导致音频无法自动播放。为了解决这个问题，我们提出了两种解决方案。一种是通过UI层面的弹窗、浮层等诱导用户点击页面发生主动交互，进而触发音频播放逻辑。另一种是给页面 document 绑定 touchstart / mousedown 事件，事件回调中执行音频播放逻辑，并移除解绑事件。
　　我们选择了方案1，在进入 Web 端时引导用户点击确认后再进行语音播放提示，以避免用户错过对应阶段的语音提示及介绍。此外，在人工服务通话时，我们也采用了方案1，避免了 autoplay 属性失效的限制。
　　最后，我们还需要处理浏览器授权问题，以访问麦克风/摄像头等音视频采集设备。在代码中，我们引导用户授权允许访问设备，以保证网络电话服务的顺利运行。
　　如前文所述，网络电话不仅提供自助服务，还能与在线人工客服进行语音通话以快速解决用户问题。但在 web 端实现高效稳定清晰的语音通话能力是一个困难的问题。为此， WebRTC 技术应运而生，它是一种无插件实现 web 端实时音视频通信能力的技术。实现完整的 WebRTC 技术需要考虑多个方面的细节，包括网络协议、媒体协商、NAT 穿透、安全性、实时性以及信令、媒体等服务器架构。我们在 WebRTC SDK 的基础上，建立了用户与客服坐席会话房间（服务），并实现了音频流采集、订阅、推送等功能。
　　语音通话交互流程图：
　　四、落地迭代过程
　　该项目的设计比较庞大，因此我们将其功能进行拆分，分批逐步上线，并搜集用户的体验信息，以便及时进行迭代优化。
　　1、第一版实现了基本的网络电话功能和基础的自助服务能力。该版本首先在酒店业务上进行应用，提高了锁单率和用户自助能力，缓解了线上客服压力。
　　2、第二版优化提升了自助能力。它可以支持短流程自助流程操作能力，同时接入了机票业务，大大提高了用户的自助能力。
　　3、第三版接入了 chat 机器人自助服务。它支持用户自定义交互，并且支持实时图文交互，提高了用户自助能力和人工客服的沟通效率。
　　4、后来我们还支持了 www/touch 端接入，承接 web 端流量。
　　五、项目收益
　　目前，机酒业务已经全部接入了网络电话功能。经过三个大版本的迭代和中间数十次的小版本升级，我们实现了预期目标：
　　1、新增网络电话渠道，分担传统电话渠道压力，目前网络电话渠道占有率18%、用户自助率26.22%。
　　2、网络电话转入人工建单平均缩短了50%，大大减少了转人工前的交互时长，节约了用户的时间。
　　3、提高了锁单率40%，减少了客服确认用户订单环节的时间，节约了客服成本。
　　4、人工同屏交互极大提高了用户和客服的沟通效率，用户平均人工服务时长降低10%。
　　六、后续规划
　　当然网络电话也存在一些现实的问题，比如比较依赖用户当时的网络状态问题以及音频被占用等情况，我们将持续优化网络电话的技术，改善网络波动对通话的影响，提高音频质量和稳定性，减少通话中断的概率；人工同屏功虽然能在特殊场景降低部分回拨，但仍然会有用户回拨现象，需要针对性地去解决；同时，面对全球化，如何能让境外用户也能有一个更好的体验也是我们努力追求的目标。
　　总之，我们将不断努力，让网络电话成为一种更加便捷、高效、稳定的沟通方式，为用户提供更优质的客户服务体验。  作者介绍
　　胡泊 ：大前端开发工程师，主要负责维护IM、网络电话、推送等组件，熟悉Android、RN、Flutter等框架平台开发。
　　李康 ：前端开发工程师，主要负责大前端中心服务平台的前端开发工作。
　　来源:微信公众号:Qunar技术沙龙
　　出处:https://mp.weixin.qq.com/s/EOX8y3tAvxjLAAm2bXyR6g