电商实时分销方案：售前准备正向交易

　　本文主要介绍了电商实时分销方案中的核心两大模块“售前准备”“正向交易”，其余模块将于下次分享。
　　电商流量获取成本越来越高，怎样获取流量，成为当前电商平台的一大核心问题。笔者曾经做过一个“实时分销”的项目，就属于自营电商寻找新流量，寻找出路的一个尝试。
　　那么：实时分销是什么？
　　“实时分销”是一种电商平台提出，一种和分销商的一种新的合作模式。一种由分销商提供流量，电商平台实时提供货物以及一整套服务的合作形式，以最终实现销售的新的解决方案。
　　为什么要做实时分销？做实时分销有什么优势；
　　电商平台需要新的销售出路，并且愿意用让利引流销售。另一方面，分销商有优质流量，且有购买意愿，但分销商自己并无一套完整的运营能力和供应链能力。但是又希望有着自己的购物交易体验，能够与对应平台场景无缝融合。
　　与传统分销相比，电商平台提出“实时分销”的合作方式，电商平台无需分货给分销商，与主流销售库存共享；另一方面，分销商无需建立仓库，不管理库存，不管理履约，0库存运营，风险小。
　　实时分销怎么做的呢？我们分为几个步骤来分析；
　　一、实时分销的例子
　　京东开普勒买断模式：http：k。jd。comproject。html？project2
　　唯品会多渠道项目：http：vop。vip。comapicenterindex？categoryNo9（页面推没找到，只有一些api接口）；
　　苏宁有新零售，没有找到页面介绍，对应的合作方，线下的店铺偏多。
　　借一张京东开普勒的示意图了解下双方的合作形式：
　　二、角色介绍
　　先来介绍一下业务合作的三个角色：
　　供货方
　　一般是自营电商平台，有着自主的完整的供应链，有着较强的业务与技术能力，能够提供完善的业务及技术解决方案，其对应的职能：
　　提供一整套的实时分销解决方案；
　　实时提供给分销商商品库存；
　　提供配送履约服务；
　　提供针对分销商售后服务；
　　分销商
　　拥有自己的线下店铺，或者有自主独立的APP、小程序引流；不愿依赖电商平台提供的交易流程，自主搭建销售体系，实现购物场景与其应用场景无缝融合。其对应的职能：
　　提供独立完整的交易购物流程；
　　有着自己的商品运营体系（选品、价格、促销等运营活动）；
　　能够提供针对用户的售后服务能力；
　　用户
　　使用分销商APP、或者小程序用户（当然也存在线下用户）；且在对应平台有购买意愿，例如电信用户使用电信APP购物；其对应的职能：
　　在分销商购物交易
　　收货以及收票
　　售后服务申请
　　三、业务流程
　　一整套的“实时分销”业务方案，我分为了五个模块：“售前准备”“正向交易”“售后服务”“财务结算”“入驻申请”；后续也按照这个顺序进行介绍，准备分为两次进行分享；
　　本次主要聊核心的两个模块“售前准备”“正向交易”。
　　售前准备
　　流程简单的示意图如下，将整体流程分为三个步骤；
　　第一步：电商平台确定可供货商品范围
　　第二步：形成实时分销商品池
　　第三步：分销商选品并完成售前准备
　　第一步：确定可供货商品范围
　　电商平台往往并不是厂商，所以他的货也有供应商；是不是电商平台自营的货都能做实时分销呢，答案显然是NO；电商平台和供应商合作模式很多：买断模式、经代销模式、代销模式；另外，很多品牌较为强势，有控价、控销售渠道的需求；所以可供货的货源分为两类：
　　注：POP模式商品不适合再做分销，因为POP模式本就是平台抽佣形式，并无货权转移；
　　针对非买断形式的商品，就涉及与供应商谈判，确定可做分销的商品范围；产品设计时，需提供工具，与供应商签订实时分销协议，确定商品范围（可按照“品牌三级品类”，或者“商品编码”颗粒度确定可供货范围）；另外，协议中需要明确，是否可由分销商再次定价，因为涉及分销商是否有权再次定价。
　　针对买断商品，因为电商平台已经拥有物权，可直接供货给分销商；
　　第二步：形成实时分销商品池
　　电商平台商品量往往很大，即使只看“买断模式”的商品，其对应的体量也可能万、十万级（甚至更多）；哪些商品适合做实时分销呢。这里可能就是需要运营人员挑选商品进入实时分销商品池了；产品设计上，考虑为内部运营人员提供一个选品工具即可。至于选品维度，就看平台商品体系重，商品属性、标签的丰富度了；至于是否做自动选品，这就看业务需求的重要性，以及对应的资源投入了。
　　第三步：分销商选品并完成售前准备
　　电商平台提供了实时分销商品池，分销商是一股脑全拿过去售卖吗，往往并不是的；因为各分销商运营重点不一样，例如电信公司运营的可能3C居多，有些公众号合作方主推化妆品；而且分销商往往只运营几款或者一款主打商品。所以分销商往往还会进行一次选品；
　　可是分销商在哪儿选品，选品后还需要做哪些工作才能销售呢？
　　分销商在哪儿选品？我建议是，由电商平台提供一个公共选品平台，因为这样减少分销商接入工作量，适用于平台的扩展，另外，分销商可以在电商平台选品完成，针对性的处理对应商品信息，这就就可以可以减少分销商与电商平台的交互次数。页面可以是这样的：
　　分销商选品完成后，还需要做哪些工作才能销售呢？
　　分销商选品完成，可是商品仍然还在电商平台内部，分销商并无商品信息；所以分销商需要获取商品信息；并且转换为分销商识别的数据，保存在本地。
　　这个过程，电商平台就需要提供一些列的商品查询服务，分销商需要逐一对接，完成商品本地化处理；并在本地化后，进行商品运营。
　　商品本地化过程中，双方交互处理的主要内容有：
　　商品清单获取；
　　按商品编码获取商品资料（包含品牌信息，品类树等信息，是一整套商品信息服务）；
　　商品价格获取；
　　商品状态获取（这里的状态主要是指商品上下架状态，这儿的上下架状态最好和对应主站的上下架分开，只用来控制实时分销销售渠道的是否可售）；
　　商品库存获取；
　　分销商完成商品本地化后，进行商品的基本运营（自主定价的商品重新定价，或者指定活动等）；最后在分销商销售平台进行上架，完成销售前的最后操作。
　　关于商品信息变更处理方案：
　　以上所说，是商品首次引入分销商平台，其实还需要考虑一个场景，分销商已经成功商品本地化后，商品信息发生变更。为保证电商平台和分销商的商品信息尽量保持一致。所以需要建立起一套商品信息变更通知机制；
　　建议方案：
　　1。针对商品资料、商品价格、商品上下架状态等信息变更：
　　电商平台在商品信息发生变更后，记录变更历史。
　　分销商定时获取段时间内的变更历史，然后使用价格获取，商品状态查询，商品资料获取，获取最新最新的商品信息；
　　2。针对库存状态变更：
　　因为库存变化比较频繁，以及仓库的覆盖逻辑复杂，且不适合暴露给分销商。所以这里需要经过加工处理，按照配送区域记录库存信息，例如：（商品001，广州市，库存紧缺）。
　　分销商定时获取，段时间内‘库存状态发生变更’的商品的最新库存状态。
　　以上信息变更同步方案中，都是基于一个前提，平台明确知悉分销商选品的内容；不然就会出现一个场景，分销商获取变更信息时，永远都需要将所有商品的变更信息获取一遍，结果大部分商品自己并不使用。
　　所以分销商选品，我建议是由电商平台搭建公共选品工具，这样平台就能很简单掌握分销商的选品情况，甚至更深一步的控制分销商选品范围、选品数量等。虽然选品api也可以实现上述所说内容，但是感觉实现起来反而更复杂些。
　　正向交易
　　用户在购物平台的基本操作如图，分为两个大模块：“购物”与“履约”；
　　对于购物流程：
　　分销商的业务场景往往更为灵活，无需逐步完成。但整体的模块可分为两个模块，导购与交易；这两个过程都需要较为准确的商品信息，用来保证最后交易的达成。而这个过程中就需要合作双方密切的配合；
　　导购模块中，商品列表的排序，筛选的功能所需要商品信息，分销商只能依托分销商本地的商品数据；所以需要尽量保持准确性，所以之前商品信息变更交互需要一定的实时性，需要较高的频率处理。
　　展示给用户的商品信息则需要精准，需要实时与电商平台交互，获取准确的商品信息；所以在购物流程中，电商平台需提供精准的商品、交易服务：
　　商品聚合服务：主要是服务于商品详情页、购物车、结算页实时查询商品库存、价格、核心资料。用来保证双方信息的一致性；
　　提交订单服务：指在分销商下单的同时，电商平台同步产生订单，并针对分销商订单进行一些列的校验，例如销售价、结算价校验；以及核心的库存保留处理。
　　订单支付服务：指在分销商支付完成后，通知电商平台完成支付，形成可执行订单的服务。
　　电商平台提供了以上服务后，分销商导购交易过程实时调度；这里分销商就需要权衡，当真的本地数据与电商平台不一致时，交易是否继续。还是一定可接收的范围的时候，交易可以继续；
　　例如：本地数据对于商品A的记录是，库存充足，电商定的结算价100。00，分销商定的售价120。00；交易过程中，发现电商平台定的结算价涨为了110。00，这个时候，交易是否继续？
　　对于履约流程：
　　产品实施比较简单，首先在识别分销商订单后，只需要考虑以下几点：
　　发货过程中，无需打印发票。因为货权是先转移到分销商，分销商销售给用户，所以电商平台开票对象应该分销商，由分销商开票给用户；
　　电商平台如果和分销商有包装定制合作，需要单独包装。
　　电商平台需要提供物流轨迹查询服务，分销商定时获取物流轨迹，以供用户查询物流轨迹。
　　用户确认收货后，分销商需要尽快通知电商平台，用来完成订单，作为后续结算的依据，并且应该设置确认收货倒计时。这里有一点需要注意，如京东、苏宁等企业都有着自己的物流，确认收货的状态，可以基于物流人员结单为准，无需等待用户确认收货。
　　以上，便是实时分销方案的“售前准备”“正向交易”两个模块的内容，关于“售后服务”“财务结算”“入驻申请”三个模块下次接着分享。
　　个人虽然参与主导这个项目，但终究不可能所有模块都熟悉，很多模块都只是介绍了下对应的业务流程以及大致产品方案，因为具体模块产品实施有专门的同事，其中内容可能有误，望指正。