明明是在電商平臺付款買的課程，為什么可以直接就在站內(nèi)學習完成后續(xù)的履約呢？渠道訂單如何實現(xiàn)站內(nèi)履約？本文對此進行了分析，一起來看看吧。

小明是一名大學生，大三在讀的他打算畢業(yè)后繼續(xù)讀研深造，他考慮近期報個考研的課程跟著老師學習。在挑選機構(gòu)和課程時，小明意外地發(fā)現(xiàn)，一些非常出名的在線考研的品牌在淘寶、天貓、拼多多這些大型電商平臺都有旗艦店，而且還可以疊加雙十一平臺活動。

小明對比了下，在電商平臺下單抵扣后的價格比直接在機構(gòu)APP上購買更便宜，咨詢客服后，客服反饋在電商平臺買的課程也可以在官方APP內(nèi)學習。還有這種好事？于是小明在某個在線考研機構(gòu)的電商旗艦店支付了一單。不一會兒他就發(fā)現(xiàn)，客服所說果然不假，他所購買的課程已經(jīng)下發(fā)到APP他的賬號里了，他可以在APP里直接聽課學習。

那么明明是在電商平臺付款買的課程，為什么可以直接就在站內(nèi)學習完成后續(xù)的履約呢？其實這是一類非常常見的交易場景，渠道訂單如何實現(xiàn)站內(nèi)履約，如果對此你感興趣就一起來看看吧~

一、什么是渠道訂單

在理解“渠道單”之前，先理解“渠道”是什么，渠道其實很好理解，就是指購買這個商品的來源。“渠道單”就是這個渠道下所產(chǎn)生的訂單。我們以上文小明的例子來看，機構(gòu)的APP、各個電商平臺都屬于是不同的渠道。其中機構(gòu)的APP、pc官網(wǎng)等都屬于站內(nèi)渠道，而像外部電商平臺、線下機構(gòu)等都屬于站外渠道。站外流量體量較大，所以隨著站內(nèi)流量逐步達到了瓶頸，很多公司都開始大力挖掘站外渠道，通過站外引流至站內(nèi)。

對于站內(nèi)渠道，用戶在自營APP主站內(nèi)購買商品后，課程會直接下發(fā)至用戶賬戶中，頁面上會直接引導用戶在類似于【我的課程】模塊進行學習，整個流程非常絲滑；那么為了保證用戶體驗，對于在站外平臺下的訂單，系統(tǒng)會自動為用戶履約，讓用戶無縫銜接在站內(nèi)完成履約

二、系統(tǒng)設(shè)計模型

如圖：模型總體來說分為三層：渠道層、網(wǎng)關(guān)層和基建層。

1. 渠道層

渠道層里面主要是分為站內(nèi)渠道和站外渠道兩大類：

站內(nèi)渠道包括自營商城，其常見表現(xiàn)形式為自營APP、pc官網(wǎng)、小程序等場景。

站外渠道這里我又將其分成兩種：第一種是淘寶、天貓、京東、拼多多等在線電商平臺，商家可以選擇在各類電商平臺開店，用戶在店鋪內(nèi)進行消費；第二種是一些線下平臺，以上文中小明要購買的考研課程為例，機構(gòu)合作的線下輔導班、學校等，這些線下渠道也可以為機構(gòu)售賣課程，用戶從線下輔導班、學校等途徑購買課程，然后到APP進行履約。

2. 網(wǎng)關(guān)層

這一層我把他定義為網(wǎng)關(guān)層，網(wǎng)關(guān)顧名思義，就是一個轉(zhuǎn)換作用的”路由“，網(wǎng)關(guān)層主要負責的工作是將上述站外渠道單進行統(tǒng)一轉(zhuǎn)換，然后由網(wǎng)關(guān)和基建層對接，實現(xiàn)后續(xù)的履約。

如用戶在淘寶店鋪和拼多多店鋪下單，其實對于底層基建層來說，并不會理解不同渠道，而是抽象成統(tǒng)一的交易服務(wù)，這其中就是由網(wǎng)關(guān)層進行封裝。

一般來說，網(wǎng)關(guān)主要是面向于站外渠道訂單。對于站內(nèi)訂單，一般直接對接基建能力。當然，各家實現(xiàn)的方案都不一樣，沒有對錯。不同站外場景下網(wǎng)關(guān)層的具體實現(xiàn)方案其實也大有不同。

上文我們提到過，站外渠道分為兩類：第一類是淘寶、天貓、京東、拼多多等在線電商平臺；第二類是一些線下平臺，如機構(gòu)合作的線下輔導班、學校等。對于系統(tǒng)來說，這兩類最大的區(qū)別是有無系統(tǒng)對接能力。顯而易見，對于第一類電商平臺，就是有系統(tǒng)對接能力的；對于一些學校、線下機構(gòu)等，認為是沒有系統(tǒng)對接能力的。

1. 對于有系統(tǒng)對接能力的，網(wǎng)關(guān)這里主要是兩種實現(xiàn)方案：

方案1：網(wǎng)關(guān)直接和各個系統(tǒng)對接進行數(shù)據(jù)同步，這個方案的優(yōu)點是對接非常直接，交互周期短；不涉及其他三方系統(tǒng)，通過雙方直接對接就可進行進行數(shù)據(jù)交互。

方案2：引入一個三方ERP系統(tǒng)，網(wǎng)關(guān)只對接ERP，由ERP對接其他電商平臺，這個方案優(yōu)點是隨著業(yè)務(wù)后續(xù)的拓展，開拓新的線上售賣渠道時，網(wǎng)關(guān)層不需要開發(fā)，由ERP支持即可。

2. 對于沒有系統(tǒng)對接能力的，一般采用人工導單的方式，將這種外部的訂單導入系統(tǒng)，然后對接網(wǎng)關(guān)，完成后續(xù)交易流程。

3. 基建層

這里的基建層就是指底層的基建能力，如交易、訂單、支付、履約、售后等，基建層并不感知渠道，只是和網(wǎng)關(guān)進行數(shù)據(jù)交互完成整個交易流。

三、系統(tǒng)實現(xiàn)思路

其實從小明在站外渠道買了課程，到小明完成履約整個模型里主要是三層【渠道】、【網(wǎng)關(guān)】、【基建】，那么第三部分我們從基建的維度，看下交易的主要流程中每個模塊承擔的怎樣的職責。

1. 商品

商品關(guān)聯(lián)&同步機制：

1）站外系統(tǒng)對接渠道

通過本地sku和渠道側(cè)sku進行唯一關(guān)聯(lián)。舉個栗子：商家在電商平臺店鋪中的skuID需要和本地站內(nèi)skuID進行唯一映射，也就是將站內(nèi)skuID 在站外平臺進行鋪貨，例如站內(nèi)skui等同于電商后臺的商品編碼等，商品信息和庫存信息保持一致，這樣做既保證前置不會賣錯、超賣，也是商品能夠在站內(nèi)履約的前提。

如果是上文提到的采用對接第三方ERP模式，那么sku關(guān)系的維護就是兩兩映射，外部ERP和站外渠道的sku可以關(guān)聯(lián)到，本地商品庫和外部ERP可以關(guān)聯(lián)到。

2）站外非系統(tǒng)對接渠道

非系統(tǒng)對接的方案一般較為粗暴，就是人工導入訂單，導入的商品信息就包括skuID、sku名稱，注意，這里skuID就和本地skuID保持一致即可。

2. 交易訂單

訂單同步機制：

1）站外系統(tǒng)對接渠道

其實對于訂單數(shù)據(jù)來說，通過網(wǎng)關(guān)拉取（或同步）到上游的訂單數(shù)據(jù)。

然后網(wǎng)關(guān)調(diào)用交易的下單接口下一筆站內(nèi)0元訂單，只是訂單存儲的時候會將網(wǎng)關(guān)獲取到的部分重要信息進行存儲，如訂單狀態(tài)、外部支付金額、用戶信息等。

2）站外非系統(tǒng)對接渠道

因為不涉及系統(tǒng)對接，所以也不存在訂單拉取的流程，可以認為人工導入訂單的過程其實就手動調(diào)用下單接口在內(nèi)部下了一筆訂單。

3. 支付

對于支付來說，訂單其實調(diào)用支付下了一筆站內(nèi)0元支付單。因為用戶已經(jīng)在外部平臺支付完成了，所以不需要在內(nèi)部重復(fù)支付

4. 履約

其實不管是站外渠道單還是站內(nèi)單，對于履約服務(wù)來說，他只關(guān)心【給誰】以及【履約啥】。

1）站外系統(tǒng)對接渠道

【履約啥】也就是履約哪個sku，這個要素其實上面商品同步的時候已經(jīng)可以定位到了，根據(jù)外部sku的信息找到對應(yīng)的本地skuID；【給誰】這個就比較麻煩了，因為對于站外渠道而言，站外的交易是一套完整的流程；站內(nèi)和站外渠道的賬號體系完全是兩套毫無關(guān)聯(lián)的。

一般這類問題的解決辦法是會在用戶在站外渠道下單的時候，填入手機號信息，該手機號作為登錄APP的賬號以此做關(guān)聯(lián)。對于實物訂單，則可以通過網(wǎng)關(guān)拉取到的用戶信息進行履約。

2）站外非系統(tǒng)對接渠道

其實在人工導單的時候 人和商品的信息就已經(jīng)提供這些信息，并不阻塞履約。

5. 售后

售后主要是分為錢和物權(quán)，也就是用戶支付的錢以及商家為用戶履約的物權(quán)。

• 對于錢的售后，全都找渠道，原因很簡單，錢是渠道收的；
• 對于物權(quán)的售后，全都找商家，原因也很簡單，商品是商家履約的。

其實售后最重要的一點是，對于站外系統(tǒng)對接的訂單，在外部退款時，要保證訂單狀態(tài)是同步的，不然就會出現(xiàn)用戶白嫖的場景，既退了款，又白嫖了商品；對于站外非系統(tǒng)對接渠道時，在給用戶退款時，也要記得內(nèi)部系統(tǒng)收回物權(quán)。

四、個人思考

隨著站內(nèi)流量逐步遇到瓶頸，利用站外引流獲客已成為不少商家嘗試的業(yè)務(wù)模式。上述設(shè)計思路的場景可以覆蓋各種類型的商品，因為不管是什么類型，交易本質(zhì)都是一樣的。

此外，在整個系統(tǒng)實現(xiàn)過程中，需要考慮商品關(guān)聯(lián)和同步機制、訂單同步機制、支付流程、履約服務(wù)以及售后處理等方面的問題。當然文章中提到的一些方案模型并不是一個標準，其實各廠實現(xiàn)的方案不盡相同，最重要的是根據(jù)業(yè)務(wù)需求和具體情況來選擇適合的方案，沒有標準答案，只要能為業(yè)務(wù)賦能解決問題，就是好方案。