首先，本系统只是一份个人学习作品。
以下是客服系统的思维导图，很多是我在思路不清晰的时候用 5W1H 的方法来帮助分析的，比如对于一条退款，What（哪个订单、哪些商品）Who（谁要退、谁处理）Where（哪个门店、在哪取货）Why（退货理由）When（什么时间申请、审批、取货、退款完成）How（什么渠道退款）这样就能理清大部分的主线思路，当然我还没有仔细学习订单系统，所以我想肯定还有待修正和补漏。
和上一个运营支撑系统一样，使用 Adobe XD 绘制，交互参考 Office Fluent UI。全部页面查看链接 https://xd.adobe.com/view/34683fb8-c0d4-48a0-74d3-4106a28c2639-4259/
零、操作台
朴朴既有在线客服，也有电话客服，但是电话客服没有暴露给普通消费者，只有在订单遇到问题、评价回访时才会由客服主动拨打过来，顾客想要主动发起沟通只能通过在线客服。因此我认为可以把电话客服看作是只有处理工单时才会使用的工具，而在线客服是承接服务单的工具。
网络上关于工单、服务单的学习资料比较少，在这里我把所有会变更、修改系统中的实体（主要是订单）的相关信息和属性的相关操作归为工单，而所有顾客发起的在线沟通归为服务单。
0.1 在线客服操作台
在线客服分为会话列表、今日数据、对话框、服务单相关信息和会话工具几个板块，尽可能把在线客服进行服务时所需要的信息都列出来，而鉴于为顾客提供服务时，客服需要尽可能方便的查找所有顾客可能问及的信息，并且客服在处理工单或其他事项时也可能被接入的会话打断，所以页面的打开做成了标签页的形式，方便即时打开多个页面查找信息。
对话框添加了链接按钮，方便输入 SPU、订单号等即时发送给顾客可视化的内容，将创建工单放在对话框的左下角，方便客服一键创建工单，快速的为顾客完成例如修改订单信息等操作。
右上方是服务单相关信息，包括顾客信息，此顾客的订单查询，此顾客的过往服务单和此次沟通的节点等信息。右下方是知识库和常用语的工具区。
0.2 电话客服服务台
电话客服和在线客服展示的信息其实差不太多，我设想的功能是接入系统的电话，不知道具体是怎么实现的。一方面由于不需要对话框，所以可展示的信息非常多，另一方面朴朴的电话客服据我体验主要是处理工单，如骑手提交无法配送订单由客服联系顾客取消，或者顾客评价了订单由客服来致电回访。所以电话客服绝大部门工作的基础是工单信息。电话客服大多时候在这里是工单流转的一部分，而在线客服服务单是顾客提交工单的起点，并且绝对不在工单的流转流程中。因此在线客服没有直接展示顾客相关的工单信息，需要的话可以手动查询，电话客服则把工单信息放在首位。
这里以回访退货工单为例，客服可填写的字段就是回访描述，其他具体字段就不讲了，我想我很可能还有很多疏漏。在这里也是给了客服快捷创建工单的按钮，方便即时为顾客处理需求。
右上角的待呼叫我认为可以看作是，在线客服是被动接受顾客的服务单，电话客服则是接收到工单流转以后去自行根据紧急度、待处理时间来拨打电话，那么也应该可以有手动转接的按钮。
订单信息这里也是大致学习了一下列出这些信息，朴朴作为 30 分钟到家的 O2O，相对来说订单系统可能没那么复杂，其中之一就是不需要拆单。
我在某篇文章看到一个前辈讲，拆单就是为了更好的履单，对那些由于种种原因可能无法同时同地发货、不同品类商品需要不同包装等原因，拆单来更好的服务客户。
而根据我的体验，朴朴不论是生鲜产品、蔬菜、海鲜、还是生活日百，包装配送一致，前置仓的模式保证所有货品从同一仓库发货，而朴朴虽然有预售商品，但是预售其实是预订，预订后平台再去进货，有实际的到货时间可期，朴朴将包含预售商品的这一单的可配送时间定为到货时间以后，也就是如果顾客希望一单中某些商品今日送达，而不用等待预售一起，那么实际上顾客需要自己拆单。因此相对于淘宝等电商来讲，朴朴这种模式应该是大大简化了订单系统的。
为了了解到顾客曾经通过各种渠道与客服沟通的历史来作出回应，此处也同样提供查询过往服务单信息的功能。
为方便查询购买当时的商品信息和商品对应的营销信息，提供了商品快照的查询功能。
一、服务单管理
当做完了操作台的页面以后，其实服务单、工单的信息基本上就已经都包括在里面了，服务单和工单的管理就是将上述信息列表展示，并做一些数据统计。
分析的数据维度仅仅是我能想到的这些，根据业务指导和收集到的数据还可以有更多维度的统计分析。当前也想到可以在提交服务单信息的时候给服务单打标签，如商品咨询，到货咨询等，根据具体咨询的内容类别来分析当前 app 是否有哪些需要优化的细节来让购物流程更顺利。
二、工单管理
工单可编辑的内容由当前进度和账号权限决定。
工单的类型在朴朴这里我想是比较固定的，顾客的角度无法提起任何工单，app 并没有投诉或退款申请，也就是说所有相关工单都由客服创建。比如场景：顾客下了预约单，但是到预约时间备货时，发现顾客需要的商品已缺货，此时门店客服联系顾客，如果顾客同意退款，那么客服创建仅退款工单，并在订单系统进行操作，如果顾客不同意，那么客服可能会创建修改订单配送时间的工单，并在订单系统进行操作。
由于脑补出的工单类型比较单一，比如退货退款、仅退款、换货、补货、理赔，所以我想工单的字段和类型可能是写死的，基本上涉及到的字段就是：原订单信息，商品及数量信息，换、补货地址和时间，会员信息，处理截止时间等，自定义配置的成本可能还要更高一点。
另外就是由于是 30 分钟到家类的线上超市，几乎所有工单应该都是围绕着订单的，涉及到的实时性要求很高，并且业务流程并不复杂，售前工单几乎可以由客服全权处理，售后工单基本上也就是客服 - 门店 - 配送员这样简单的业务流程，应该不太存在着需要手动领取工单的情况。
因此工单系统这里做的比较简单，流转到其他系统时附带工单信息，并由下一级经手人员来操作记录即可，如果有审核流程的话，会设计“我的工单”操作页面，查看待审核的内容并进行操作。
至于比较复杂的内容，如总部客服和门店客服的业务权限范围，总部客服和门店客服及门店经理之间的反复流转，没有实际业务的指导确实很难设计。
三、客服管理
客服管理分为三个部分，所有客服的查看、数据统计和当前客席状态。
列表项比较多，按照 fluent UI 是可以拖动列表项以查看完全的，如有需要也可以增加自定义列表项的功能。
四、内容管理
内容管理仅包含知识库和常用语及客服设置三部分，前两者管理方式基本一致。
我想客服设置应该包含一些客服转接的规则之类的，或有更多内容作为一个一级菜单，这里暂时想不到，能了解到的也不多，所以这里仅列出了分配权重的一个设置。
关于分配规则，通过学习了解到可以有除了根据客服当前饱和度以外一些优化的规则，熟客优先、经验优先、好评优先，优先分配更熟悉此顾客的客服、通过判断服务单入口或者顾客关键词来判断可能的工单类型，来分配给对此类型工单更熟悉的客服，在可用的客服中优先分配好评度高的客服。
五、信息查询
这里只给了个查询的入口，由于涉及到营销信息等还没学习的部分，没有画出搜索结果的展示。客服应当有权限查询顾客可能问及的如商品、优惠、过往订单等信息。客服可以选择类型并输入名称或编号来在对应的数据库中进行查询。
六、结语
由于日常生活中非常高频次的使用朴朴 app，所以继上一篇模拟了运营支撑系统以后，又模拟练习了他们的客服系统，客服系统能找到的资料很少，几乎就是看着参考的那一篇文章来做的，有一些根据（猜想的）业务自己的调整。其实很多商家应该都会接入 zendesk 之类的客服系统，做这一份只是为了兴趣和练习。
开始做没多久我就发现其实我应该先学着做订单系统的，因为客服系统实在是牵涉到了订单系统的太多内容，虽然页面看起来简单，但是由于对工单、订单系统的一知半解（完全不懂），做起来还是花了很多时间，如果有做过客服系统或了解更多的前辈希望可以给点建议。接下来应该会学习和绘制订单系统，到时应该会对这个系统也有所更正。