|
俞军总结的关于产品经理的12条军规（方法论）里面有一条：“如果不确定怎么做，就先学别人是怎么做的”。对于从事产品工作的同学而言，这一条应该很熟悉了，我早期做过C端产品，C端产品比较好的一点就是竞品多，在产品思维还不成熟的时候，每接到一个需求，首先想到的是看竞品。比如公司打算做拼团，首先会想到去看看拼多多是怎么做的，淘宝是怎么做的，玩一圈后，依葫芦画瓢可能也不会差到哪里去，问题也不大。
后面转做B端产品后，会沿袭以前做C端的习惯，做需求前也会看看市面上的竞品，参照仿做一个。但是做完上线给业务使用时，就开始不断有问题出来了，业务会反馈这不好用，那不好用，甚至可能业务现实情况下是怎么使用你的产品的会跟你的想象完全不一样，这种时候特别能让产品觉悟到为什么产品设计一定要基于场景，基于业务。
下面开始讲案例，今天主要分享的是售后工单的处理。
先讲下什么是工单，工单是记录问题/任务，以及问题/任务完成全流程的载体，问题/任务可能由公司外的客户主动发起（比如淘宝开放平台的开发者在浏览接口文档的时候，如果有疑问就可以向淘宝官方提一个工单，由淘宝工作人员回答），也有可能由公司内部发起（比如售前接到用户关于商品使用的问题，售后又不在线时，可以向售后提一个工单，售后上班时可继续服务客户）。
我做的就是第二种的，我们公司在天猫、京东、苏宁、小红书等平台都有开多家店铺，现实情况有两种使用场景：一、售前接到售后问题，售后不在线或不接在线（因为平台多，店铺也多，售后资源有限，同时接很多店铺太混乱，所以有些小店铺会不接在线），会直接提交工单至售后，这种情况售后接到工单会再联系用户，协商处理方案；二、售前接到售后问题，直接在线转给售后，售后在线与用户协商处理方案，达成一致后售后会创建工单，这种情况下工单仅作为售后记录的载体存在，并不用承担任务流转职责。
这个项目是很早之前做的了，做的时候是打算做一个全新的工单系统，原因就不细说了，做的时候我看了相关的竞品是怎么做工单的，就工单的创建而言，市面上的工单产品大多会在工单列表放一个入口【添加工单】，点击即可添加新的工单，工单添加后会流转至对应客服，客服处理时需到工单详情处理，如下图所示。
 udesk-工单列表
 udesk-创建工单
 udesk-工单详情
于是我也采用了类似的做法，不过我给创建工单单独搞了一个页面，这样可以方便售前，提交完刷新当前页可以继续提交下一个工单。并且也参照别人的做法，将工单提交与工单处理分开了（需要先提交一个工单，再进到这个工单详情去处理工单）。
上线后运行一段时间后，售前跟售后都跟我提想要一个快捷创建工单的功能，我观察了下售后的操作，像上文讲的，售后用工单纯粹是为了记录，而Y为了做这个记录他们用我的工单系统，需要走这样一套流程：
 这样一套流程下来，一个售后可能会经过四个页面：订单列表（查找订单）、订单详情（查看订单详情）、工单创建页（创建工单）、工单详情（勾选处理方案），整套流程下来对于客服这种机械式的工作而言还是会很影响效率。
那售前呢，售前接到售后问题其实描述下直接仍给售后就行了，确认订单信息的工作交给售后，但是他们用我的工单系统需要填订单号、选问题类型、选优先级、写问题描述，本身可以交给售后完成的工作（选问题类型、优先级）现在需要售前完成，也影响了他们的工作效率。
这么看下来，影响客服工作效率的原因在于：一、部分事项需要重复操作，如复制订单号；二、 对于售后而言，大多数时候工单创建的时候已经知道处理方案了，把勾选处理方案与创建工单分开影响效率；三、对于售前而言，创建工单时选择的内容太多。
这些问题的产生可以说都是因为纯粹的拿来主义，出解决方案时并未考虑实际的业务场景。
这道问题所在后，深入思考了下给出了下面的解决方案：
我们这种业务场景下，售后工单是不会凭空产生的，一定是先有订单，然后再有工单，而售后与用户协商处理方案必然要先去确认用户的订单信息的。所以对于售后而言，直接在订单详情给个创建工单的按钮，在弹框中填写订单对应的工单信息，并能同时勾选处理方案是最好的；而对于售前，在他们工作的工作台直接给个创建工单的入口，在弹框中描述下问题内容就行了。
这种坑要时刻警惕，项目小还好，项目大的话，整个运转不起来就比较惨了。分析需求时，一定要基于需求背后的场景分析，如果担心你的现有的认知会导致你分析的场景不全，那就切身去体验一把用户工作的场景，这样会比较有感觉。
Udesk产品价格优惠，提供专业的技术服务，咨询热线：400-1565-661
|
