本文主要介绍了电商动态经销计划中的核心三大组件——“产品服务预备”“萨德基交易”，余下组件将于到时候撷取。

电商流量获取成本愈来愈高，什么样获取流量，正式成为现阶段电商平台的三大核心问题。本栏曾做过两个“动态经销”的工程项目，就归属于直营电商找寻新流量，找寻解决之道的两个试著。

所以：动态经销是什么？

“动态经销”是一类电商平台明确提出，一类和经销商的一类捷伊合作模式。一类由经销商提供流量，电商平台动态提订货物运输和整套服务的合作方式，以最后同时实现销售的捷伊解决计划。

为什么要做动态经销？做动态经销有什么竞争优势；

电商平台需要捷伊销售解决之道，因此愿意用折扣导流销售。再者，经销商有优质流量，且有买回意向，但经销商自己并无两套完备的运营能力和物流物流配送能力。但又希望有著自己的网购交易体验，能与相关联平台情景点对点结合。 与现代经销较之，电商平台明确提出“动态经销”的合作方式，电商平台无须Seiches给经销商，与非主流销售库存共享资源；再者，经销商无须建立库房，不管理库存，不管理按期，0库存运营，信用风险小。

动态经销怎么做的呢？我们分成两个关键步骤来分析；

一、动态经销的范例

京东第谷-购回模式：http://k.jd.com/project.html?project=2 唯品会-多渠道工程项目：http://vop.vip.com/apicenter/index?categoryNo=9（网页推没找出，多于许多apiUSB）； 国美有新零售，没有找出网页介绍，相关联的合作方，实体店的店铺偏多。

借两张京东第谷的左图介绍下两方的合作方式：

二、配角介绍

先来介绍呵呵业务合作的四个配角：

订货方

一般是直营电商平台，有著独立自主的完备的物流物流配送，有著很强的业务与技术能力，能提供健全的业务及技术解决计划，其相关联的职责：

提供整套的动态经销解决计划； 动态提供给经销商货品库存； 提供物流配送按期服务； 提供特别针对经销商售后服务；

经销商

拥有自己的实体店店铺，或者有独立自主独立的APP、小程序导流；不愿依赖电商平台提供的交易流程，独立自主搭建销售体系，同时实现网购情景与其应用情景点对点结合。其相关联的职责：

提供独立完备的交易网购流程； 有著自己的货品运营体系（选品、价格、促销等运营活动）； 能提供特别针对用户的售后服务能力；

用户

使用经销商APP、或者小程序用户（当然也存在实体店用户）；且在相关联平台有买回意向，例如电信用户使用电信APP网购；其相关联的职责：

在经销商网购交易 收货和收票 售后服务申请

三、业务流程

整套的“动态经销”业务计划，我分成了五个组件：“产品服务预备”“萨德基交易”“售后服务”“财务结算”“入驻申请”；后续也按照这个顺序进行介绍，预备分成两次进行撷取；

本次主要聊核心的两个组件“产品服务预备”“萨德基交易”。

产品服务预备

流程简单的左图如下，将整体流程分成四个关键步骤；

第一步：电商平台确定可订货货品范围 第二步：形成动态经销货品池 第三步：经销商选品并完成产品服务预备

第一步：确定可订货货品范围

电商平台往往并不是厂商，所以他的货也有供应商；是不是电商平台直营的货都能做动态经销呢，答案显然是NO；电商平台和供应商合作模式很多：购回模式、经代销模式、代销模式；另外，很多品牌较为强势，有控价、控销售渠道的需求；所以可订货的货源分成两类：

注：POP模式货品不适合再做经销，因为POP模式本就是平台抽佣方式，并无货权转移；

①特别针对非购回方式的货品，就涉及与供应商谈判，确定可做经销的货品范围；产品设计时，需提供工具，与供应商签订动态经销协议，确定货品范围（可按照“品牌+三级品类”，或者“货品编码”颗粒度确定可订货范围）；另外，协议中需要明确，是否可由经销商再次定价，因为涉及经销商是否有权再次定价。

②特别针对购回货品，因为电商平台已经拥有物权，可直接订货给经销商；

第二步：形成动态经销货品池

电商平台货品量往往很大，即使只看“购回模式”的货品，其相关联的体量也可能万、十万级（甚至更多）；什么样货品适合做动态经销呢。这里可能就是需要运营人员挑选货品进入动态经销货品池了；产品设计上，考虑为内部运营人员提供两个选品工具即可。至于选品维度，就看平台货品体系重，货品属性、标签的丰富度了；至于是否做自动选品，这就看业务需求的重要性，和相关联的资源投入了。

第三步：经销商选品并完成产品服务预备

电商平台提供了动态经销货品池，经销商是一股脑全拿过去售卖吗，往往并不是的；因为各经销商运营重点不一样，例如电信公司运营的可能3C居多，有些公众号合作方主推化妆品；而且经销商往往只运营几款或者一款主打货品。所以经销商往往还会进行一次选品；

可是经销商在哪儿选品，选品后还需要做什么样工作才能销售呢？

经销商在哪儿选品？我建议是，由电商平台提供两个公共选品平台，因为这样减少经销商接入工作量，适用于平台的扩展，另外，经销商可以在电商平台选品完成，特别针对性的处理相关联货品信息，这就就可以可以减少经销商与电商平台的交互次数。网页可以是这样的：

经销商选品完成后，还需要做什么样工作才能销售呢？

经销商选品完成，可是货品仍然还在电商平台内部，经销商并无货品信息；所以经销商需要获取货品信息；因此转换为经销商识别的数据，保存在本地。

这个过程，电商平台就需要提供许多列的货品查询服务，经销商需要逐一对接，完成货品本地化处理；并在本地化后，进行货品运营。

货品本地化过程中，两方交互处理的主要内容有：

货品清单获取； 按货品编码获取货品资料（包含品牌信息，品类树等信息，是整套货品信息服务）； 货品价格获取； 货品状态获取（这里的状态主要是指货品上下架状态，这儿的上下架状态最好和相关联主站的上下架分开，只用来控制动态经销销售渠道的是否可售）； 货品库存获取；

经销商完成货品本地化后，进行货品的基本运营（独立自主定价的货品重新定价，或者指定活动等）；最后在经销商销售平台进行上架，完成销产品服务的最后操作。

关于货品信息变更处理计划：

以上所说，是货品首次引入经销商平台，其实还需要考虑两个情景，经销商已经成功货品本地化后，货品信息发生变更。为保证电商平台和经销商的货品信息尽量保持一致。所以需要建立起两套货品信息变更通知机制；

建议计划：

1. 特别针对货品资料、货品价格、货品上下架状态等信息变更：

电商平台在货品信息发生变更后，记录变更历史。 经销商定时获取段时间内的变更历史，然后使用价格获取，货品状态查询，货品资料获取，获取最新最捷伊货品信息；

2. 特别针对库存状态变更：

因为库存变化比较频繁，和库房的覆盖逻辑复杂，且不适合暴露给经销商。所以这里需要经过加工处理，按照物流配送区域记录库存信息，例如：（货品001，广州市，库存紧缺）。 经销商定时获取，段时间内‘库存状态发生变更’的货品的最新库存状态。

以上信息变更同步计划中，都是基于两个前提，平台明确知悉经销商选品的内容；不然就会出现两个情景，经销商获取变更信息时，永远都需要将所有货品的变更信息获取一遍，结果大部分货品自己并不使用。

所以经销商选品，我建议是由电商平台搭建公共选品工具，这样平台就能很简单掌握经销商的选品情况，甚至更深一步的控制经销商选品范围、选品数量等。虽然选品api也可以同时实现上述所说内容，但感觉同时实现起来反而更复杂些。

萨德基交易

用户在网购平台的基本操作如图，分成两个大组件：“网购”与“按期”；

对于网购流程：

经销商的业务情景往往更为灵活，无须逐步完成。但整体的组件可分成两个组件，导购与交易；这两个过程都需要较为准确的货品信息，用来保证最后交易的达成。而这个过程中就需要合作两方密切的配合；

导购组件中，货品列表的排序，筛选的功能所需要货品信息，经销商只能依托经销商本地的货品数据；所以需要尽量保持准确性，所以之前货品信息变更交互需要一定的动态性，需要较高的频率处理。

展示给用户的货品信息则需要精准，需要动态与电商平台交互，获取准确的货品信息；所以在网购流程中，电商平台需提供精准的货品、交易服务：

货品聚合服务：主要是服务于货品详情页、网购车、结算页实时查询货品库存、价格、核心资料。用来保证两方信息的一致性；提交订单服务：指在经销商下单的同时，电商平台同步产生订单，并特别针对经销商订单进行许多列的校验，例如销售价、结算价校验；和核心的库存保留处理。 订单支付服务：指在经销商支付完成后，通知电商平台完成支付，形成可执行订单的服务。

电商平台提供了以上服务后，经销商导购交易过程动态调度；这里经销商就需要权衡，当真的本地数据与电商平台不一致时，交易是否继续。还是一定可接收的范围的时候，交易可以继续；

例如：本地数据对于货品A的记录是，库存充足，电商定的结算价￥100.00，经销商定的售价￥120.00；交易过程中，发现电商平台定的结算价涨为了￥110.00,这个时候，交易是否继续？

对于按期流程：

产品实施比较简单，首先在识别经销商订单后，只需要考虑以下几点：

发货过程中，无须打印发票。因为货权是先转移到经销商，经销商销售给用户，所以电商平台开票对象应该分销商，由经销商开票给用户； 电商平台如果和经销商有包装定制合作，需要单独包装。 电商平台需要提供物流轨迹查询服务，经销商定时获取物流轨迹，以供用户查询物流轨迹。 用户确认收货后，经销商需要尽快通知电商平台，用来完成订单，作为后续结算的依据，因此应该设置确认收货倒计时。这里有一点需要注意，如京东、国美等企业都有著自己的物流，确认收货的状态，可以基于物流人员结单为准，无须等待用户确认收货。