本文主要介紹了電商實時分銷方案中的核心兩大模塊——“售前準備”“正向交易”，其余模塊將于下次分享。

電商流量獲取成本越來越高，怎樣獲取流量，成為當前電商平臺的一大核心問題。筆者曾經(jīng)做過一個“實時分銷”的項目，就屬于自營電商尋找新流量，尋找出路的一個嘗試。

那么：實時分銷是什么？

“實時分銷”是一種電商平臺提出，一種和分銷商的一種新的合作模式。一種由分銷商提供流量，電商平臺實時提供貨物以及一整套服務的合作形式，以最終實現(xiàn)銷售的新的解決方案。

為什么要做實時分銷？做實時分銷有什么優(yōu)勢；

1. 電商平臺需要新的銷售出路，并且愿意用讓利引流銷售。另一方面，分銷商有優(yōu)質(zhì)流量，且有購買意愿，但分銷商自己并無一套完整的運營能力和供應鏈能力。但是又希望有著自己的購物交易體驗，能夠與對應平臺場景無縫融合。
2. 與傳統(tǒng)分銷相比，電商平臺提出“實時分銷”的合作方式，電商平臺無需分貨給分銷商，與主流銷售庫存共享；另一方面，分銷商無需建立倉庫，不管理庫存，不管理履約，0庫存運營，風險小。

實時分銷怎么做的呢？我們分為幾個步驟來分析；

一、實時分銷的例子

1. 京東開普勒-買斷模式：http://k.jd.com/project.html?project=2?
2. 唯品會-多渠道項目：http://vop.vip.com/apicenter/index?categoryNo=9（頁面推沒找到，只有一些api接口）；
3. 蘇寧有新零售，沒有找到頁面介紹，對應的合作方，線下的店鋪偏多。

借一張京東開普勒的示意圖了解下雙方的合作形式：

二、角色介紹

先來介紹一下業(yè)務合作的三個角色：

供貨方

一般是自營電商平臺，有著自主的完整的供應鏈，有著較強的業(yè)務與技術能力，能夠提供完善的業(yè)務及技術解決方案，其對應的職能：

1. 提供一整套的實時分銷解決方案；
2. 實時提供給分銷商商品庫存；
3. 提供配送履約服務；
4. 提供針對分銷商售后服務；

分銷商

擁有自己的線下店鋪，或者有自主獨立的APP、小程序引流；不愿依賴電商平臺提供的交易流程，自主搭建銷售體系，實現(xiàn)購物場景與其應用場景無縫融合。其對應的職能：

1. 提供獨立完整的交易購物流程；
2. 有著自己的商品運營體系（選品、價格、促銷等運營活動）；
3. 能夠提供針對用戶的售后服務能力；

用戶

使用分銷商APP、或者小程序用戶（當然也存在線下用戶）；且在對應平臺有購買意愿，例如電信用戶使用電信APP購物；其對應的職能：

1. 在分銷商購物交易
2. 收貨以及收票
3. 售后服務申請

三、業(yè)務流程

一整套的“實時分銷”業(yè)務方案，我分為了五個模塊：“售前準備”“正向交易”“售后服務”“財務結算”“入駐申請”；后續(xù)也按照這個順序進行介紹，準備分為兩次進行分享；

本次主要聊核心的兩個模塊“售前準備”“正向交易”。

售前準備

流程簡單的示意圖如下，將整體流程分為三個步驟；

• 第一步：電商平臺確定可供貨商品范圍
• 第二步：形成實時分銷商品池
• 第三步：分銷商選品并完成售前準備

第一步：確定可供貨商品范圍

電商平臺往往并不是廠商，所以他的貨也有供應商；是不是電商平臺自營的貨都能做實時分銷呢，答案顯然是NO；電商平臺和供應商合作模式很多：買斷模式、經(jīng)代銷模式、代銷模式；另外，很多品牌較為強勢，有控價、控銷售渠道的需求；所以可供貨的貨源分為兩類：

注：POP模式商品不適合再做分銷，因為POP模式本就是平臺抽傭形式，并無貨權轉移；

①針對非買斷形式的商品，就涉及與供應商談判，確定可做分銷的商品范圍；產(chǎn)品設計時，需提供工具，與供應商簽訂實時分銷協(xié)議，確定商品范圍（可按照“品牌+三級品類”，或者“商品編碼”顆粒度確定可供貨范圍）；另外，協(xié)議中需要明確，是否可由分銷商再次定價，因為涉及分銷商是否有權再次定價。

②針對買斷商品，因為電商平臺已經(jīng)擁有物權，可直接供貨給分銷商；

第二步：形成實時分銷商品池

電商平臺商品量往往很大，即使只看“買斷模式”的商品，其對應的體量也可能萬、十萬級（甚至更多）；哪些商品適合做實時分銷呢。這里可能就是需要運營人員挑選商品進入實時分銷商品池了；產(chǎn)品設計上，考慮為內(nèi)部運營人員提供一個選品工具即可。至于選品維度，就看平臺商品體系重，商品屬性、標簽的豐富度了；至于是否做自動選品，這就看業(yè)務需求的重要性，以及對應的資源投入了。

第三步：分銷商選品并完成售前準備

電商平臺提供了實時分銷商品池，分銷商是一股腦全拿過去售賣嗎，往往并不是的；因為各分銷商運營重點不一樣，例如電信公司運營的可能3C居多，有些公眾號合作方主推化妝品；而且分銷商往往只運營幾款或者一款主打商品。所以分銷商往往還會進行一次選品；

可是分銷商在哪兒選品，選品后還需要做哪些工作才能銷售呢？

分銷商在哪兒選品？我建議是，由電商平臺提供一個公共選品平臺，因為這樣減少分銷商接入工作量，適用于平臺的擴展，另外，分銷商可以在電商平臺選品完成，針對性的處理對應商品信息，這就就可以可以減少分銷商與電商平臺的交互次數(shù)。頁面可以是這樣的：

分銷商選品完成后，還需要做哪些工作才能銷售呢？

分銷商選品完成，可是商品仍然還在電商平臺內(nèi)部，分銷商并無商品信息；所以分銷商需要獲取商品信息；并且轉換為分銷商識別的數(shù)據(jù)，保存在本地。

這個過程，電商平臺就需要提供一些列的商品查詢服務，分銷商需要逐一對接，完成商品本地化處理；并在本地化后，進行商品運營。

商品本地化過程中，雙方交互處理的主要內(nèi)容有：

1. 商品清單獲??；
2. 按商品編碼獲取商品資料（包含品牌信息，品類樹等信息，是一整套商品信息服務）；
3. 商品價格獲??；
4. 商品狀態(tài)獲取（這里的狀態(tài)主要是指商品上下架狀態(tài)，這兒的上下架狀態(tài)最好和對應主站的上下架分開，只用來控制實時分銷銷售渠道的是否可售）；
5. 商品庫存獲取；

分銷商完成商品本地化后，進行商品的基本運營（自主定價的商品重新定價，或者指定活動等）；最后在分銷商銷售平臺進行上架，完成銷售前的最后操作。

關于商品信息變更處理方案：

以上所說，是商品首次引入分銷商平臺，其實還需要考慮一個場景，分銷商已經(jīng)成功商品本地化后，商品信息發(fā)生變更。為保證電商平臺和分銷商的商品信息盡量保持一致。所以需要建立起一套商品信息變更通知機制；

建議方案：

1. 針對商品資料、商品價格、商品上下架狀態(tài)等信息變更：

• 電商平臺在商品信息發(fā)生變更后，記錄變更歷史。
• 分銷商定時獲取段時間內(nèi)的變更歷史，然后使用價格獲取，商品狀態(tài)查詢，商品資料獲取，獲取最新最新的商品信息；

2. 針對庫存狀態(tài)變更：

• 因為庫存變化比較頻繁，以及倉庫的覆蓋邏輯復雜，且不適合暴露給分銷商。所以這里需要經(jīng)過加工處理，按照配送區(qū)域記錄庫存信息，例如：（商品001，廣州市，庫存緊缺）。
• 分銷商定時獲取，段時間內(nèi)‘庫存狀態(tài)發(fā)生變更’的商品的最新庫存狀態(tài)。

以上信息變更同步方案中，都是基于一個前提，平臺明確知悉分銷商選品的內(nèi)容；不然就會出現(xiàn)一個場景，分銷商獲取變更信息時，永遠都需要將所有商品的變更信息獲取一遍，結果大部分商品自己并不使用。

所以分銷商選品，我建議是由電商平臺搭建公共選品工具，這樣平臺就能很簡單掌握分銷商的選品情況，甚至更深一步的控制分銷商選品范圍、選品數(shù)量等。雖然選品api也可以實現(xiàn)上述所說內(nèi)容，但是感覺實現(xiàn)起來反而更復雜些。

正向交易

用戶在購物平臺的基本操作如圖，分為兩個大模塊：“購物”與“履約”；

對于購物流程：

分銷商的業(yè)務場景往往更為靈活，無需逐步完成。但整體的模塊可分為兩個模塊，導購與交易；這兩個過程都需要較為準確的商品信息，用來保證最后交易的達成。而這個過程中就需要合作雙方密切的配合；

導購模塊中，商品列表的排序，篩選的功能所需要商品信息，分銷商只能依托分銷商本地的商品數(shù)據(jù)；所以需要盡量保持準確性，所以之前商品信息變更交互需要一定的實時性，需要較高的頻率處理。

展示給用戶的商品信息則需要精準，需要實時與電商平臺交互，獲取準確的商品信息；所以在購物流程中，電商平臺需提供精準的商品、交易服務：

• 商品聚合服務：主要是服務于商品詳情頁、購物車、結算頁實時查詢商品庫存、價格、核心資料。用來保證雙方信息的一致性；
• 提交訂單服務：指在分銷商下單的同時，電商平臺同步產(chǎn)生訂單，并針對分銷商訂單進行一些列的校驗，例如銷售價、結算價校驗；以及核心的庫存保留處理。
• 訂單支付服務：指在分銷商支付完成后，通知電商平臺完成支付，形成可執(zhí)行訂單的服務。

電商平臺提供了以上服務后，分銷商導購交易過程實時調(diào)度；這里分銷商就需要權衡，當真的本地數(shù)據(jù)與電商平臺不一致時，交易是否繼續(xù)。還是一定可接收的范圍的時候，交易可以繼續(xù)；

例如：本地數(shù)據(jù)對于商品A的記錄是，庫存充足，電商定的結算價￥100.00，分銷商定的售價￥120.00；交易過程中，發(fā)現(xiàn)電商平臺定的結算價漲為了￥110.00,這個時候，交易是否繼續(xù)？

對于履約流程：

產(chǎn)品實施比較簡單，首先在識別分銷商訂單后，只需要考慮以下幾點：

1. 發(fā)貨過程中，無需打印發(fā)票。因為貨權是先轉移到分銷商，分銷商銷售給用戶，所以電商平臺開票對象應該分銷商，由分銷商開票給用戶；
2. 電商平臺如果和分銷商有包裝定制合作，需要單獨包裝。
3. 電商平臺需要提供物流軌跡查詢服務，分銷商定時獲取物流軌跡，以供用戶查詢物流軌跡。
4. 用戶確認收貨后，分銷商需要盡快通知電商平臺，用來完成訂單，作為后續(xù)結算的依據(jù)，并且應該設置確認收貨倒計時。這里有一點需要注意，如京東、蘇寧等企業(yè)都有著自己的物流，確認收貨的狀態(tài)，可以基于物流人員結單為準，無需等待用戶確認收貨。

以上，便是實時分銷方案的“售前準備”“正向交易”兩個模塊的內(nèi)容，關于“售后服務”“財務結算”“入駐申請”三個模塊下次接著分享。

個人雖然參與主導這個項目，但終究不可能所有模塊都熟悉，很多模塊都只是介紹了下對應的業(yè)務流程以及大致產(chǎn)品方案，因為具體模塊產(chǎn)品實施有專門的同事，其中內(nèi)容可能有誤，望指正。

本文由 @JOJO_004 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。