工单管理系统功能列表：申诉-审核工单流
工单管理系统功能列表：申诉-审核工单流在明确具体的申诉方和审核方之前，首先要知道你需要解决的业务场景参与方到底有哪些。根据这些参与方在业务流程中所起到的作用，以及相互的利益关系，来决定在审核流中所应该担负的角色。申诉方是指需要在此工单流中按照要求提供凭证进行申诉的一方；审核方是指根据申诉方所提供的凭证以及判断标准进行审核并给出审核结果的一方。申诉方处在工单流的流程上游，审核方处在流程下游。只有在申诉方提供了凭证之后，审核方才能进行审核操作。在明确了哪些场景需要“申诉-审核工单流”来串联各个角色之后，下面的重点是如果要搭建完整的“申诉-审核工单流”，你的PRD中到底需要给开发或者其他产品解释清楚哪些东西。为了搭建完整的“申诉-审核工单流”，需要妥善制定策略解决以下几个问题：“申诉-审核工单流”中，主要的角色有两个，分别是申诉方、审核方。
编辑导语：在售后业务、快递业务和社区团购等业务场景，利益纠纷问题极易出现。产品经理遇到利益纠纷问题时应该怎么解决？这篇文章提供了一套完整的“申诉-审核工单流”，以及具体介绍了设计搭建工单流需要解决的五个问题。一起来看看吧！
作为一名B端产品经理，当你负责的业务涉及多个角色参与方之间利益的时候，是否会陷到入很多实物或者虚拟交接环节“公说公有理，婆说婆有理”的尴尬境地。由于这个“谁也说不清”的灰色地带存在，业务场景反馈出来的信息以及数据会极度失真，导致产品负责人对该场景业务的利益错付，甚至产品长期存在经济或者业务指标上的严重损失。
“利益纠纷”问题存在比较典型的业务场景主要有售后业务、快递业务以及现在风头正盛的社区团购。为了大家更好地了解现在电商风口，下面会使用社区团购中的真实case来给大家辅助解释产品设计方法。社区团购现在的利益方以及交接过程如下，先不做过多介绍，大家一眼便可看明白：
言归正传，当产品遇到“利益纠纷”问题，且所在业务的多个利益角色之间满足以下关系的时候，就需要涉及一套完整的“申诉-审核工单流”，来可靠地解决这个“谁也说不清”的灰色地带：
- 多角色之间有业务环节承接关系：只有两个角色之间同时参与某一个环节的运作，其中一方的利益才会对另外一方产生影响。
- 多角色之间存在利益冲突：只有存在利益冲突，才会促使各角色为了保全自己的利益，站在自己的立场上可以曲解事情发生的经过。
- 多角色之间有参与方和决策方：对应业务的运作，大部分角色都是业务的参与方，但是也一定需要一个对纠纷场景能起到最终决策作用的角色，这个角色一般是业务平台运营，甚至是业务产品本身。
在明确了哪些场景需要“申诉-审核工单流”来串联各个角色之后，下面的重点是如果要搭建完整的“申诉-审核工单流”，你的PRD中到底需要给开发或者其他产品解释清楚哪些东西。
为了搭建完整的“申诉-审核工单流”，需要妥善制定策略解决以下几个问题：
一、“申诉-审核工单流”的参与方以及参与作用
- “申诉-审核工单流”的参与方以及参与作用
- 申诉方、审核方的申诉和审核标准
- “申诉-审核工单流”的流向制定
- “申诉-审核工单流”的时效限定
- “申诉-审核工单流”的状态流转
“申诉-审核工单流”中，主要的角色有两个，分别是申诉方、审核方。
申诉方是指需要在此工单流中按照要求提供凭证进行申诉的一方；审核方是指根据申诉方所提供的凭证以及判断标准进行审核并给出审核结果的一方。申诉方处在工单流的流程上游，审核方处在流程下游。只有在申诉方提供了凭证之后，审核方才能进行审核操作。
在明确具体的申诉方和审核方之前，首先要知道你需要解决的业务场景参与方到底有哪些。根据这些参与方在业务流程中所起到的作用，以及相互的利益关系，来决定在审核流中所应该担负的角色。
审核方需要一个中立的角色，需要站在天平中央来对凭证判断并对结果负责，所以一般是平台的管理者或者运营者。申诉方一般是利益受损方，需要从自身角度，结合审核方要求，提供一些客观凭证。
在社区团购中，主要环节包括供应商与仓库的交付，仓库与与服务站的交付，服务站与团点的交付。在这些交接流程中，每个环节都存在谁也说不清的灰色地带，所以各个环节的货物损失也是相当大。
就社区团购最后一环“服务站与团点”交付过程而言，可能存在一件商品，团点没有收到的时候，团长和服务站站长都会站在自身的立场维护自己的利益，甚至不惜曲解事实。此时团长和服务站都是利益受损方，都应该作为申诉者，而只有平台相关运营能作为决策者把握这个天平的平衡。
二、申诉方、审核方的申诉和审核标准在线上进行的 “申诉-审核工单流”中，为了节省各环节操作成本，以及提升各环节操作有效性，需要制定标准的SOP来规定好申诉方举证、备注的规范性，以及审核方根据凭证判断的客观性和公正性。
申诉凭证需要满足一些基本特征，如：易采集、易辨别、高可信。
- “易采集”保证了申诉方的低操作成本，不需要花费大量的时间和精力在凭证采集上。
- “易辨别”可以保证凭证的有效性，即提升审核方的审核效率以及审核准确性。
- “高可信”意味着提供的凭证必须剔除申诉方个人情感，避免出现为个人利益处罚，提供的一些失真的凭证。
在社区团购“服务站与团点”的交接中，团长通过售后动作表达了有商品缺货之后，需要服务站从申诉者的角度来提供一些货物是否送达团点的证据。证据可以是送达团长时团长签字的交接单、事后跟团长电话确认的录音、司机送货到团点的图片证据等等。但不是以上所有证据都很合适，都能满足以上三个特征。
对于“送达团长时团长签字的交接单”而言，具备易采集、易辨别的特征，但是不具备高可信。司机可能为了自身利益，随便仿造团长签字。
对于“事后跟团长电话确认的录音”也一样，具备易采集、易辨别的特征，但是不具备高可信。因为通过音色，我们只能大概率辨别是几个人的声音，但是不能判断是否是团长和司机双方各自的声音。
对于“司机送货到团点的图片证据”，完美的具备以上三个特征，作为这个场景下的申诉材料再合适不过。
但是“易采集、易辨别、高可信”只是挑选凭证的方式，决定了凭证之后，需要规定好其中必备的元素。比如对于服务站的举证，随便拿一张货物图片肯定是不行的，需要这张照片上有一些基本元素：时间、地点、交付商品（且能看到有几件）。服务站需要按照这个标准来准备凭证并上传，才能最大限度地说明问题。
三、“申诉-审核工单流”的流向制定“申诉-审核工单流”说到底是个流程，流程是个持续的过程，因此需要明确在每个节点，每个环节，数据的流向。“申诉-审核工单流”至少需要两方参与，一个充当申诉方，一个充当审核方，当然也可能存在多个申诉方或者多个审核方。
对于多个申诉方，如果利益关系一致，共同对损失负责，则需要互相感知数据和对方的操作，此时审核方也只需要感知多个申诉方最终确认的结果；如果多个申诉方的利益关系相反，各自维护各自的损失，且互相对立，则不能感知对方的数据和操作，以免导致申诉带有对抗性。
这个情况下，审核方需要综合两个对立申诉方的凭证来作出判断。
比如社区团购“服务站-团点”交接过程中，对于缺货问题的举证。本质上站长不直接跟团长交接，而站长雇佣的负责送货的司机才是跟团长交接的实际角色。司机和站长完全是一根绳上的蚂蚱，所以各自的申诉材料、申诉结果以及其他操作都应该互相可见。而这些细节并不需要全部都同步给审核方，只要把他们最终达成一致的凭证提交即可。但是对于团长和站长的举证则不同，他们的凭证必须互相不可见，而且两方的凭证必须都同步给审核方。
四、“申诉-审核工单流”的时效限定“申诉-审核工单流”是为了制定一个线上流程，提供给各个角色以满足申诉和审核的需求。只有明确制定好各个环节的操作时效，才能有效收集证据，让各个角色在合适的时间参与到流程中，完成角色在申诉-审核流中的义务。
为了细分各个角色的操作时效，首先应该根据这个工单流整体从开始到输出结果所能占有的时间资源。时间资源需要根据业务所在的场景来做判断。对于一些需要紧急得出结果，并有下游使用方来紧急消费这个结果的，整体时效应该限制在某个时间范围内。
但是整体时效也不是越短越好，还需要充分考虑各个角色操作所需要的最少时间。比如某个角色搜集凭证需要至少两天，那么整体审核时效就应该高于这个阈值。
对于社区团购中“服务站-团点”的交接流程而言，判断是否缺货的结果会影响是否给用户退款（如果最终判断缺货，则给用户退款；如果最终判断非缺货，则驳回用户的退款要求）。而对于售后而言，售后时间是个重要考核指标，希望缩短用户售后时长，提升用户体验，所以整体申诉审核流的时长上限可以定位为1天、2天等。
但这个过程中，有司机和站长同时参与申诉流程，平台运营参与审核流程。考虑到司机、站长和运营的工作和作息时间，双方共同平分这整体的时间。此外，还需要对夜间的工单进行特殊操作，避免这段时间内，大家都在休息，无人申诉和审核的情况。
五、“申诉-审核工单流”的状态流转状态流转是工单流中的灵魂，在以上几个环节的设计结束之后，就应该根据以上规则，指定一套贴合的状态流转。只有制定了一套完美的状态流转，才能让流程参与者明确所在环节、所需操作和所面临的问题。
状态的定义需要充分体现三个方面：
- 明确现阶段的操作角色：能一眼得出现在的环节停留在谁
- 明确现在所处审核流的环节：能一眼看出现在的环节需要怎么操作
- 明确标记各异常场景：能一眼看出哪个环节出现了问题
对于社区团购中“服务站-团点”的交接流程而言，状态可能会有：待服务站申诉、待运营审核、服务站申诉超时等。
六、结语“申诉-审核工单流”是解决“谁也说不清”的灰色地带的必背方案。为了更好地设计一套“申诉-审核工单流”，需要充分设计以上各个环节。在此基础之上，需要再补充一些细节内容，比如说展示的方式、字段等等，才能更好地实现目标和解决问题。
本文由 @膜法狮 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 pexels，基于 CC0 协议
