中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

一、什么是渠道訂單

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

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

二、系統設計模型

如圖：模型總體來說分為三層：渠道層、網關層和基建層。

1. 渠道層

渠道層里面主要是分為站內渠道和站外渠道兩大類：

站內渠道包括自營商城，其常見表現形式為自營APP、pc官網、小程序等場景。

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

2. 網關層

這一層我把他定義為網關層，網關顧名思義，就是一個轉換作用的”路由“，網關層主要負責的工作是將上述站外渠道單進行統一轉換，然后由網關和基建層對接，實現后續的履約。

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

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

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

1. 對于有系統對接能力的，網關這里主要是兩種實現方案：

方案1：網關直接和各個系統對接進行數據同步，這個方案的優點是對接非常直接，交互周期短；不涉及其他三方系統，通過雙方直接對接就可進行進行數據交互。

方案2：引入一個三方ERP系統，網關只對接ERP，由ERP對接其他電商平臺，這個方案優點是隨著業務后續的拓展，開拓新的線上售賣渠道時，網關層不需要開發，由ERP支持即可。

2. 對于沒有系統對接能力的，一般采用人工導單的方式，將這種外部的訂單導入系統，然后對接網關，完成后續交易流程。

3. 基建層

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

三、系統實現思路

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

1. 商品

商品關聯&同步機制：

1）站外系統對接渠道

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

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

2）站外非系統對接渠道

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

2. 交易訂單

訂單同步機制：

1）站外系統對接渠道

其實對于訂單數據來說，通過網關拉取（或同步）到上游的訂單數據。

然后網關調用交易的下單接口下一筆站內0元訂單，只是訂單存儲的時候會將網關獲取到的部分重要信息進行存儲，如訂單狀態、外部支付金額、用戶信息等。

2）站外非系統對接渠道

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

3. 支付

對于支付來說，訂單其實調用支付下了一筆站內0元支付單。因為用戶已經在外部平臺支付完成了，所以不需要在內部重復支付

4. 履約

其實不管是站外渠道單還是站內單，對于履約服務來說，他只關心【給誰】以及【履約啥】。

1）站外系統對接渠道

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

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

2）站外非系統對接渠道

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

5. 售后

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

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

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

四、個人思考

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

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