阅读 54

中后台产品经理难点:客服系统订单、商品、服务单详解

a

原创 Kevin改变世界的点滴 Kevin改变世界的点滴

昨天


大家好,我是Kevin。这是2020年第28篇原创


这段时间工作的主要是带团队聚焦在客服系统,今天将开始以订单、商品、服务工单来讲解客服系统的第二难点。


客服系统搭建(上)


客服系统(第一部分)



服务单号是什么?



大部分企业建立客服系统时都会有自己或第三方的呼叫中心。呼叫中心和运营同学组合成了电话客服与在线客服。


呼叫中心就是在一个相对集中的场所,由一批服务人员组成的服务机构.通常利用计算机通信技术,处理来自企业、顾客的电话垂询,尤其具备同时处理大量来话的能力,还具备主叫号码显示,可将来电自动分配给具备相应技能的人员处理,并能记录


每一次会话,我们在客服系统业务中称呼为服务单号。服务单号的命名规则中后台产品要和业务进行协商,能够做到查找、取重、便于团队理解。


下图是我带团队搭建的智慧门店客服系统里的服务单号管理。在服务单号里面,通过角色和权限识别客服一线和管理者,判别用户基本信息。比如手机号可以做隐私处理,而管理者或特定客服部门可以查看用户手机号。


同时接待时长、平均响应时间,也是客服人员工作成绩的典型指标。但仅靠这两点指标来判断不够,中后台产品经理要严格依照客服部门管理方式,搭建自家的客服系统管理体系。



服务单号管理



服务单号起步于用户的咨询呼入,但可流转到工单、订单。客服系统要确保服务单号可以流转到公司全业务。


服务单号流转到公司



同时一个服务单号还可以作为客服服务、历史记录、客服部门成绩好坏的评定标准。

服务单号信息查询



服务单号详情



在前面提过,服务单号需要关联工单、订单。所以服务单号详情如上图,包含用户信息、关联订单、关联工单、订单详情。

用户信息

客服系统最终目的是链接电商系统、会员系统、积分体系、CRM系统打通、财务系统、ERP,并且将用户的数据标识汇总。可以看到我们这套案例里,有用户的会员标识、身份信息、认证状态。但具体要展现什么数据,还是要和自家的客服业务探讨,这里不做展开。

服务单号信息

在本次服务会话中,用户通过自己订单咨询入口开展客服咨询的订单、和关联子订单、和服务单号创建的工单。

同时针对用户问题订单的购买时间、支付金额、优惠信息、购买产品是否参加活动等,进行展示。让客服人员定位用户的问题在哪里,出在什么地方。这类信息中后台产品要和客服部门甚至是财务、市场拉通沟通,确保客服系统的需求优先级明确。

订单详情

展示用户下的订单列表,这里要说明主订单、子订单是因为公司有不同平台的购物车以及某个SKU是拆分为多个子商品卖。若自己的公司业务不涉及复杂的SKU商品组合模式,子订单和主订单不必要区分。

订单详情要添加用户在会员、积分、活动、订单状态4点标记。但若公司还没有会员体系、积分系统,这里可忽略。


订单详情,定位商品与公司关系





商品详情程


前面我们提到服务单号在客服系统里是商品的最底层标识,同时一个商品会包含自身的属性信息,如上包含了外包装、编号、尺寸、上架时间、下架时间等信息。


退货记录

但在客服系统中还要满足客服查看商品的供应商关系、以及该商品下的退货情况。包括退货人、退货通过管理人员,了解到该商品下的以往信息有助于客服判断和定位客户反馈的问题。


供应商信息

供应商信息根据商品类别,别入在电商中是由实际采销经理的。但换在金融行业、医疗行业,则没有这类职位。


订单信息
针对订单查询下,订单的发货、订单状态、订单的支付金额、以及和活动、会员系统有搭上关系与否。订单信息也要依靠企业内部的体系,和商品直接关系。


服务单、工单、订单,配合业务做增删改查



最后要说的,客服系统和其他中后台产品一样。牵扯较多的报表和权限管理,所以有经验的中后台产品经理可以很快定位到业务的核心字段,没有经验的中后台产品经理会在需求设计中难以控制需求颗粒度和优先级。

将客服系统搭建完成后,相信一个中后台产品经理会更加胜任其他端的后台产品设计。




我的产品经理圈子



在PMTalk发起的一个互联网人高层资源圈子今天开启了。包括苏杰(人人都是产品经理作者)、南极圈创始人、运营研究社CEO、腾讯阿里头条产品总监等累计超过20名互联网大咖、投资人也都在这里。付费圈子提供给围绕着产品热点案例拆解、企业微信最新产品运营增长技能课程、每周精选1份应用体验报告、同时免费参加1年会做线下10场闭门会、还有若干周边、峰会的折扣福利。

如果你在产品经理或互联网的路上,加入一个终生学习的高精尖圈子势必是一件不会错的事情。

平均1天1块钱,扫码购买即可加入。








点个“在看”,也是鼓励