电商售后问题汇总表格式（电商实时分销方案）
电商售后问题汇总表格式（电商实时分销方案）以正常的货已收退货退款流程为例：退货退款流业务流程中，电商平台虽然是作为幕后，不直面顾客。但产品方案中：电商平台却是产品中轴、平台方；而分销商是作为配合方，完成整体流程的流转。业务分析：退货退款的业务与一般电商的业务流程并未太大区别，如下图：需要注意两点：
在《电商实时分销方案：售前准备&正向交易》中，笔者已经介绍了“实时分销”业务比较核心的两块业务：“售前准备”“正向交易”。紧接之前的介绍，接下来分析该产品的剩余三块业务“售后服务”“财务结算”“入驻申请”。
01 售后服务
一个平台给用户提供的售后服务很多，例如“仅退款”“退款退货”“换货”“维修”等业务；
但部分业务较为特殊，适用场景小，部分企业往往不提供对应的服务能力；例如唯品会所售货物大多是穿戴类商品，就不会提供维修服务。对于公司的自营业务而言，往往又很少支持“仅退款”业务。
另外，平台搭建初期，为了业务以及技术的简单，往往只会提供核心的售后服务；逐步完善售后体系。所以建议实施优先级是：退货退款>换货>仅退款>其他；本次主要分享一下“退货退款”的一些业务方案。
退货退款业务
业务分析：
退货退款的业务与一般电商的业务流程并未太大区别，如下图：
需要注意两点：
- 销售过程中，分销商是自营的形式销售商品，所以顾客直面分销商的售后客服；不面向供货的电商平台的售后客服团队；
- 电商平台和分销商的合作存在货权转移，所以正向流程中，如果存在票据，是分销商开具发票给用户。所以，退货业务中，票据也应由顾客邮寄给分销商（当然分销商会考虑电子发票，或者不开票，这样会省去较多的逆向票据流程）。
- 分销商客服团队虽然直面顾客，但能否退货退款的决定是由电商平台做出的，分销商的客服团队也只是做一些协调作用。
退货退款流业务流程中，电商平台虽然是作为幕后，不直面顾客。但产品方案中：电商平台却是产品中轴、平台方；而分销商是作为配合方，完成整体流程的流转。
以正常的货已收退货退款流程为例：
产品流程中，电商平台作为平台方，提供对应的通用服务，分销商根据当前请求的状态，配合平台与用户操作，推进整体业务流程的运转，图中所示的三个核心服务已基本可完成正常的退货流程。
- ①退货请求创建服务：分销商用来申请指定订单退货退款；
- ②请求状态获取服务：分销商用来获取段时间内发生变更的退货退款请求的变更信息；
- ③更新客退请求服务：分销商用来更新指定请求的状态；
当然，实际的退货退款流程复杂繁复，一、销售订单货物状态不同延伸出不同的流程，二、各个节点不同的操作也会延伸不同的分支；例如：
- ①如果是货未发申请退货退款，无需先同意退货，等待货物流转的流程，而是直接同意退款即可。
- ②又如用户申请后退货退款后，平台不同意退货，退货退款请求可能会直接关闭，等待下次重新发起申请。
产品方案设计起来其实比较简单；实际业务过程中，需要着重关注的是：异常场景。
举一个例子：
用户退还货物后，电商平台没有收到货物，或者收到的货物与自己销售发货的货物不一致。拒绝退款，这个过程中，两者纠纷应该如何处理。当然这里处理方案很多；例如：
- ①电商平台拒绝退货，分销商承担损失，全额退款给顾客；
- ②电商平台同意部分退款给顾客；
这些异常场景发生频率虽然不高，但场景积少成多，极易引起用户体验，或者合作双方的一些矛盾；长期来看更需要注意。而处理这些异常，应该从两方面出发：
02 财务结算
- 合作双方需要在项目初期，以及合作过程中，不断完成对应的处理机制，制定处理标准；
- 对于各环节的异常场景，建立起一套监控机制，无论是分销商针对恶意用户的监控，还是电商平台对分销商的监控。基于监控机制下，制定对应的防范机制，减少对应的异常产生。
业务规则
行业中，POP模式的商家入驻电商平台货款结算，往往使用“实时分账”方式实现。而分销模式、自营模式的销售的结算往往是“周期结算”。
虽然是周期结算，但与实时分账一致，都需要明确单据结算节点，实时分销模式的款项转移的节点可参考下表：
因为是“周期结算”，需要考虑一些单据业务流程往往是跨周期的，这里需要把握一点，触发节点发生在哪一个周期就在对应周期结算；举例如下
另外，还需要注意一点，自营合作中，往往有两种结算模式：扣点，结算价模式；
- 结算价模式无需多言，分销商按照结算价一次性结算给电商平台，一次货款转移；
- 对于扣点模式其实是存在两笔款项转移的（虽然实际付款只有一次）：①分销商>电商平台：全额货款；②电商平台>分销商：扣点；
产品流程
更多的是线下一些票据管理，货款管理；业务流程大部分是线下完成；产品的大致流程如下：
整个结算流程中，线上完成的主要是结算单对账处理；
结算单主要由分销商发起，将结算周期内，所有的销售订单、退货订单、仅退款等一些列单据明细与汇总数据交由电商平台，由电商平台进行核实后；进行线下开票以及打款处理；
03 入驻申请一次合作，往往最开始的操作，就是入驻申请，而为什么将入驻申请分享放在最后，主要有两个原因：
1. 入驻申请操作的核心是：双方达成合作协议，确定双方合作规则，而这些规则，就是之前个模块的业务规则；
所以入驻申请的产品流程：协商确认合作双方的业务规则，然后在电商平台内部设计一套审核流程，完成各项规则的落实（无论是线下的一些货款规则，还是线上产品计算对接的方案）；而涉及的业务规则就是之前各模块的业务内容，主要包含：
- 分销商基本信息，资质管理；
- 协商确定分销商的经营货品范围；
- 协商确定电商平台与分销商的结算周期；
- 协商确定销售订单、退货退款申请单等单据的结算节点；
- 协商确定票据、账款交互方式；
- 协商确定分销商事前是否缴纳的保证金；
- 其他产品方案的一些规则，例如：①销售过程中，电商平台为分销商保留多长时间库存，②提供库存查询的服务中，当库存小于多少时，电商平台会提供准确的库存数；而不是提供一个库存状态；等（当然这些规则，不一定在入驻时写入合同内，往往是技术对接时确认）
2. 入驻申请，只在双方合作开始一次性操作，操作频率低，往往在项目初期是使用线下的方式实现，等到业务不断发展，对接的分销商越来越多时，才逐步的开通线上流程。
结尾当然，一个产品的运营的成功；除了业务规则的确认，业务流程的实现。还涉及一块内容，就是“数据化运营”；因为自己不是数据产品，所以不够专业；所以简单的说几句；
纵观实时分销业务，从电商平台角度出发，不能直达购买用户层，能运营的内容就是：给分销商提供：
①好的商品
②合适的商品
③对电商平台更有利的商品；所以数据化运营，更多的落在选品上；建立健全的商品数据体系，并应用在选品、向分销商推荐商品上。是该产品后续运营的主要方向。
本文由 @JOJO_004 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
