客户端开发需求和视觉样板图(业务方、产品和研发都能看懂)

新手启动教程 2019-09-06  

设计需求的通常思路是按照客服流程和时间顺序来,即:服务入口埋点和布点—访客分流策略(含机器人)—访客端功能和需求—客服工作台功能和需求——数据报表类需求。

如果在客户端内采用h5或webview方式集成,请点击此处和参考“web端开发需求和视觉样板图 ”。以下为客户端常见需求,工作量仅供参考,以实际企业用户业务复杂度、系统复杂度及研发能力为准。如果有其他需求(例如销售场景或数据接口导出等)不单独在需求清单内罗列,您可在文章末尾处查看和找到。

需求点 IOS  AOS 前端 后端
分流逻辑 10人天 10人天 / 看分流逻辑的复杂程度,具体情况具体对待
会话列表
未读消息提醒
允许访客退出排队或会话
自动发送卡片
机器人查订单/办理流程 几乎可忽略 几乎可忽略 / 10-15人天
人工会话发送订单功能 5人天 5人天 / 5-10人天
CRM对接 几乎可忽略 几乎可忽略 几乎可忽略 5人天
iframe内嵌页 几乎可忽略 几乎可忽略 5人天 5-10人天


需求1. 服务入口设计

1.1. 需求注解

结合企业自身客服团队人力是否充足,再根据获客成本和客单价、访客身份信息、访客来访页面,综合考虑在哪些地方做服务入口埋点,入口埋得深或明显,就单个入口来说是否先经过机器人再到人工客服。

 1.2. 需求整理示例表

渠道 页面 是否免登 机器人 客服组
七鱼IOS APP 帮助中心 开启 综合客服组
七鱼AOS APP 帮助中心 开启 综合客服组
智慧企业IOS APP 产品详情页 关闭 售前客服
智慧企业AOS APP 产品详情页 关闭 售前客服

 

 

 

 

 

1.3. 服务入口样例图

 

需求2. 分流逻辑

 2.1. 需求注解

该需求并非必须,如果企业不做分流,则遵循七鱼后台配置项中默认的分配规则。如企业用户需要干预访客分流,为避免频繁改动客户端和发版(尤其是IOS需要过审),建议由中台来实现需求。原理是:中台根据数据(例如客户端访客的咨询入口来源、用户会员等级、用户订单状态等信息)自定义分流规则,并将七鱼实现分流所需的机器人开关,机器人热门问题,客服组(groupid)三个参数下发给客户端,客户端再给七鱼。

比如需求:1. 来自商品详情页面,都不过机器人、直接到售前客服组;2. 来自帮助中-物流页面,先过机器人,机器人热门问题模板展示“物流模板”,再到物流客服组;3. 来自帮助中心-发票页面,先过机器人,热门问题模板展示“发票模板”,再到综合客服组;

 2.2. 开发指南

 

需求3. 未读消息提醒

3.1. 需求注解

当访客不在会话窗时,需要在导航栏有消息推送或在入口有未读消息提醒。以下为APP内效果图。

3.2. 开发指南

 

需求4. 允许访客退出排队或会话

4.1. 需求注解

如果企业咨询量和排队量大,为了提升接待效率,可在聊天窗上方设置控件,允许访客退出排队或主动结束会话。根据企业用户实战案例,大约10%用户会选择主动退出会话,能有效提高翻台率(哦,翻台率)和坐席资源利用率。

4.2. 开发指南

 

需求5. 商品卡片消息

5.1. 需求注解

人工客服阶段的需求,机器人阶段无。当服务请求来自于商品详情页面时,有商品卡片功能,将访客正在浏览的商品信息以卡片消息形式发出,其他咨询来源(例如帮助中心页等)入口无该需求。根据实战经验中,通常推荐4个配置项:机器人阶段不发卡片(IOS属性autoSendInRobot选择关闭, AOS属性为isSendProductonRobot选择关闭),卡片对访客可见(都是参数show),系统自动发送卡片和每次更换商品页都发送(IOS参数为sendByUser选择关闭,AOS参数为alwaysSend选择是)

5.2. 开发指南

 

需求6. 机器人查订单/办理流程

6.1. 需求注解

该需求重后端、轻客户端。在机器人阶段,实现访客自助化查订单和查物流等需求,客户端需要上报用户信息给七鱼,后端要开发好接口供七鱼调用,接口通常通常选取近2-3个月内订单,接口性能要求在900ms内响应(访客端demo地址:这里

6.2. 开发任务拆解

客户端上报用户信息给七鱼——七鱼调用企业后端开发好的接口——企业后端接口返回参数给七鱼——在七鱼系统内完成配置(含导航条上方按钮)——客户端要自行处理点击事件,举例说明,访客点击订单卡片以后,客户端实现跳转到H5或native应用中心。一个流程的后端工作量预计在15人天左右,客户端工作量不大,但如果涉及到点击事件就需要发版本(举例,访客点击订单卡片以后,客户端实现发生卡片到消息流,或跳转到H5或native应用中心)。

6.3. 开发指南

搜索关键词“一触即达对接”         https://qiyukf.com/docs/guide/server/8-%E6%9C%BA%E5%99%A8%E4%BA%BA.html#%E4%B8%80%E8%A7%A6%E5%8D%B3%E8%BE%BE

 

需求7. 人工会话发送订单功能

7.1. 需求注解

当访客咨询订单时,可允许访客手动选择和发送订单,方便客服进行下一步工作。后端提供接口和数据以后,这需求大部分依赖于客户端内实现。

7.2. 开发指南

 

需求8. 用户信息整合

8.1. 综述和注意事项

目前支持轻量CRM对接,API CRM对接和iframe三种形式。三者可以同时并存,也可以选取使用,以下为详细对比。

8.2. 轻量CRM对接

  • 8.2.1. 需求注解

客户端将包含用户信息的 JSON 传递给网易七鱼系统,放在坐席工作台右侧的用户信息TAB下面,优点是工作量在前端而且较轻。缺点是客服工作台空间有限,扩展性较弱。

 

8.3. API CRM对接

  • 8.3.1. 需求注解

客户端上报参数——七鱼调用接口——后端返回信息展示到客服工作台右侧“更多信息”。样式不多,不支持图片等样式,但空间扩展性较轻量crm方式更大。

  • 8.3.2. 任务拆解

客户端:调用setUserInfo接口上报uid和昵称,其中uid是用户唯一且固定身份标识、用于整合该用户所有聊记录,昵称需要展示到坐席工作台上面,否则整个会话记录和报表里面会显示匿名客户guestxxx,客服交互和检索不方便。

后端:接口根据uid返回相应用户和订单信息到客服工作台右侧“更多信息”。

  • 8.3.4. 在线和电话服务记录打通

API CRM需求的补充,轻量和iframe方式不支持。用户有可能既到在线又到电话中心咨询,客服需要同时看到服务记录。呼叫中心调用get_call_user_info接口。呼叫中心,七鱼只能拿到电话号码(也就是身份标识),企业需要返回该手机号码对应的uid, 搜索关键词“呼叫中心获取电话用户信息”,开发指南通上述API CRM对接。

 

8.4. Iframe内嵌页方式

  • 8.4.1. 需求注解

本质上是将一个自适应的H5页面嵌入到七鱼客服工作台内,企业用户提供h5链接和映射参数,七鱼完成配置类工作。

  • 8.4.2. 任务拆解

任务拆解:客户端上报参数——七鱼请求iframe——后端打开iframe

客户端:调用setuserinfo接口上报uid和昵称,uid是用户唯一且固定身份标识、用于整合该用户所有聊记录,昵称需要展示到坐席工作台上面,否则整个会话记录和报表里面会显示匿名客户guestxxx,客服交互和检索不方便

后端:拿到参数以后,打开iframe内嵌页面

 

8.5. 用户退出或切换账号

  • 8.5.1. 需求注解

就好像在同一只手机上面,登录微信账号A,再退出; 或者先登录A再退出切换到B账号。同理,需要调用接口通知七鱼账号退出。

 

需求9. 行为轨迹

9.1. 需求注解

旗舰版本能力。获取每个用户进入页面的时间,停留时长,页面名称,页面路径等信息,甚至能获取某些关键事件节点(例如,加购物车)以帮助客服代表更好地了解客户。

9.2.开发指南

  • IOS搜索关键词 “行为轨迹”:https://qiyukf.com/docs/guide/ios/9-%E8%A1%8C%E4%B8%BA%E8%BD%A8%E8%BF%B9.html
  • AOS搜索关键词“行为轨迹”:https://qiyukf.com/docs/guide/android/8-%E8%A1%8C%E4%B8%BA%E8%BD%A8%E8%BF%B9.html

 

需求10. 接口导出数据(纯后端需求)

10.1. 需求注解

其实跟客户端无关,纯后端需求。用接口获取数据,包括聊天内容、用户信息、咨询访问信息、咨询服务记录。但不包括:该访客的邮箱、身份标签、本次访问的着陆页、访问轨迹和行为轨迹、用户相关关联工单(这几项不支持导出,见图内备注)。

10.2. 两种实现方式

  • 10.2.1. 实现方式1

第一步,先批量下载聊天内容、访问信息和服务小记,缺点是访问时间限制在凌晨2-6点且不支持并发任务,优点是成功率高,开发指南搜索关键词“获取会话记录”:https://qiyukf.com/docs/guide/server/6-%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F.html#%E8%8E%B7%E5%8F%96%E4%BC%9A%E8%AF%9D%E8%AE%B0%E5%BD%95

搜索关键词“接口访问步骤”,入参是时间范围:https://qiyukf.com/docs/guide/server/6-%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F.html#%E6%8E%A5%E5%8F%A3%E8%AE%BF%E9%97%AE%E6%AD%A5%E9%AA%A4

第二步,从上述接口中拿到会话id(以上接口中称id)后再调用“获取会话关联的用户信息”接口,即可拿到会话对应的用户信息,入参为sessionid。即,“获取会话记录”接口中的id等于“获取会话关联的用户信息”接口中的sessionid,开发指南:https://qiyukf.com/docs/guide/server/6-%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F.html#%E4%BC%9A%E8%AF%9D%E7%BB%93%E6%9D%9F%E6%8E%A8%E9%80%81%E4%BC%9A%E8%AF%9D%E6%95%B0%E6%8D%AE

  • 10.2.2. 实现方式2

用sessionid单条获取聊天内容、访问信息和服务小记第一步是先通过“接收会话结束通知”获取sessionid:https://qiyukf.com/docs/guide/server/6-%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F.html#%E6%8E%A5%E6%94%B6%E4%BC%9A%E8%AF%9D%E7%BB%93%E6%9D%9F%E9%80%9A%E7%9F%A5

第二步,拿着以上获得的sessionid入参,获取服务小记(根据会话ID获取会话字段接口)、聊天记录(根据会话ID获取会话消息接口)、用户信息(获取会话关联的用户信息接口)https://qiyukf.com/docs/guide/server/6-%E5%9C%A8%E7%BA%BF%E7%B3%BB%E7%BB%9F.html#%E6%8E%A5%E5%8F%A3%E5%9C%B0%E5%9D%80

发表


表情