起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識電商開放平臺產品設計（2）：店鋪開放平臺
對于不同渠道的訂單該如何管理，才能有效的降低運營壓力？或許商鋪開放平臺能夠解決這一個問題。那么如何設計呢？文章對此展開分享。
很多B2C電商平臺都會允許第三方入駐，在平臺上開設店鋪，提供商家管理后臺進行店鋪管理。隨之而來就會給一些大的第三方商家帶來困擾，除了有自營電商平臺，并且進駐天貓、京東等平臺開設品牌店鋪，如何統一管理不同渠道的訂單？怎樣降低維護不同渠道帶來的運營壓力？
這時候電商平臺就需要考慮“店鋪開放平臺”，提供給平臺上的商家同步店鋪中的商品、訂單、庫存等數據，保證店鋪數據與商家自營平臺的統一。
既然“店鋪開放平臺”是提供給第三方商家使用的，我們首先來分析下商家的需求：
- 同步各渠道的訂單到ERP系統中，并且及時自動更新不同渠道的訂單狀態；
- 商品信息能同步至各渠道，無須重復編輯，并且可上下架各渠道商品；
- 管理各渠道的商品庫存，同步更新，避免超賣或缺貨；
- 統一管理各渠道的售后申請與審核，僅在自己的ERP系統中操作即可，與平臺數據同步。
分析之后，我們就可以總結出“店鋪開放平臺”的基本框架，如下圖所示。
如果電商網站提供店鋪服務，除了完善平臺體系內部的店鋪管理工具，首要考慮的應該是開放訂單、庫存等接口，供平臺上的商家使用，這樣才能吸引有實力的商家入駐。當然如果平臺目標群體是一些微店鋪（個人開店），就沒有必要性。
“店鋪開放平臺”保證了平臺商家在核心數據上的及時更新，能夠自動化處理訂單業務，減少人工對接，提高服務質量。下面詳細講解下“店鋪開放平臺”的產品設計，思路與上節講到的“商品開放平臺”有些類似，不過會有些區別。
1.基礎數據
“店鋪開放平臺”提供給店鋪商家同步店鋪數據的權限，需要給商家相應的API證書，以及對商戶的接口權限進行定義。
不同于“商品開放平臺”，在平臺店鋪發生交易行為時，數據流只在平臺內部進行，無須與外部交互，這樣保證了平臺數據的運行穩定。
除了通過主動獲取相關信息，“店鋪開放平臺”還可以向店鋪商家提供“消息訂閱服務”，在店鋪關鍵信息（例如訂單、商品）變動時，發送“消息”通知店鋪商家。
2.商品
提供給店鋪商家相關接口，以便可以直接在ERP系統中管理商品，包括商品上下架、各渠道共享庫存等，減少運營人員在更新商品資料的重復勞動。同時可以保證各渠道的商品統一。
類目
獲取商品的類目信息，主要是在添加商品時使用，通過接口添加商品時，除了商品掛載的類目，還要填寫必填的商品屬性。
主要有以下接口：
- 獲取類目信息（接口）：返回返回類目名稱（一級、二級、三級等）。
- 獲取類目屬性（接口）：查詢某個類目的屬性，返回屬性名、屬性值、屬性類型（必填、非必填）等內容。
商品
提供給店鋪商家更新商品詳細信息，包括商品信息、SKU信息、上下架狀態等內容。
主要包括以下接口：
- 新增商品（接口）：填寫商品名稱、類目、規格、外部sku碼、價格、數量、屬性、上下架狀態、詳情描述（文字、圖片描述）等內容，成功返回商品ID.
- 更新商品（接口）：按照商品ID更新商品相關信息。
- 添加SKU（接口）： 新增一個SKU到商品中，綁定規格，設定數量、價格以及外部sku碼，返回sku編碼及相關信息。
- 更新SKU（接口）：用于更新SKU相關信息。
- 刪除SKU（接口）：通過規格組合來刪除SKU。
- 添加商品圖片（接口）：添加商品圖片，可設為主圖。
- 刪除商品圖片（接口）：刪除商品圖片。
- 上架商品（接口）：批量上架商品；
- 下架商品（接口）：批量下架商品；
價格
提供給店鋪商家更新商品價格。
主要包括以下接口：
- 獲取商品價格（接口）：用來實時查詢商品價格；
- 更新商品價格（接口）：更新商品價格，若有多規格，則應該在SKU的最高價與最低價的區間內；
- 更新SKU價格（接口）：按照規格組合來更新SKU價格；
庫存
提供給店鋪商家同步更新SKU庫存，保證商品不會發生超賣，產生客訴。
主要包括以下接口：
- 獲取商品庫存（接口）：用來實時查詢商品庫存；
- 修改商品庫存（接口）：用來修改商品庫存，如果設定了SKU庫存，則需要修改SKU庫存。
3.訂單
訂單直接在平臺成交，這個過程不會和商家發生交互。只有在發生售后（退貨退款），才會需要店鋪商家介入。商家對訂單的管理也可以通過自己的平臺來進行，只是通過API來同步相應的操作。
訂單同步
商家的工作都是圍繞訂單展開，首先將訂單同步到本地。商家通過ERP管理訂單的發貨和售后。
主要包括以下接口：
- 訂單列表查詢（接口）：查詢對應周期內的訂單列表。
- 單個訂單詳情查詢（接口）：查詢單個訂單的詳細信息。
- 訂單發貨（接口）：管理訂單發貨，反饋物流公司和單號。
- 訂單拆單發貨（接口）：但需要多包裹發貨時，就需要進行拆單，對子訂單進行發貨。
訂單售后
提供給商家管理訂單售后，在用戶申請退貨退款時，可以直接通過API進行統一操作。
主要包括以下接口：
- 獲取客戶售后申請信息（接口）：獲取客戶的售后申請（退貨退款）；
- 審核客戶售后申請（接口）：對客戶的售后申請（退貨退款）進行審核操作；
- 獲取客戶退貨信息（接口）：獲取客戶的退貨信息；
- 退款操作（接口）：退款操作（確認／拒絕）；
物流
對店鋪商家的物流相關進行操作。
主要包括以下接口：
- 查詢地址區域（接口）：查詢平臺的地址信息（省市區縣等）；
- 店鋪地址庫管理（接口）：店鋪的發貨地址管理，主要指倉庫地址；
- 修改物流公司和運單號（接口）：修改訂單的物流公司和運單號；
4.消息服務
除了以上所述的商家通過API主動向平臺獲取信息，平臺還可以提供“關鍵信息”的訂閱，以便在訂單、商品信息發生變動時及時反應。當然由于平臺商家較多，只有在商家訂閱時，平臺才會主動推送相關信息。
“訂單”在以下情況，推送相關變動信息
- 訂單下單成功
- 交易關閉
- 交易成功
- 訂單退款成功
- 部分子訂單發貨
- 子訂單退款成功
“交易全鏈路”在以下情況，推送相關變動信息
- 交易狀態發生變動
- 售后單狀態變動
“退款”在以下情況，推送相關變動信息
- 退款成功
- 退款關閉
- 客戶申請退貨
- 客戶填寫退貨信息
“商品”在以下情況，推送相關變動信息
- SKU庫存變為0
- 商品上架時
- >?商品上架時
- 商品新增時
“物流”在以下情況，推送相關變動信息
- 物流狀態有變動；
“評價”在以下情況，推送相關變動信息
- 店鋪新增評價；
5.總結
說完“店鋪開放平臺”的產品設計，我們可以看到的是，相對于“商品開放平臺”還是要復雜些。當然還可以把活動運營的相關能力開放API，不過對于商家的實用性不大，一般商家會直接在平臺上進行管理。
“店鋪開放平臺”之于店鋪商家，能夠幫助統一訂單管理，在商家的ERP中從訂單到WMS自上而下統一管理，避免數據脫離造成的管理缺失，出現紕漏。
“店鋪開放平臺”的API思維導圖整理如下，僅供參考：
相關閱讀：
#專欄作家#
劉志遠，公眾號：遠哥聊產品，人人都是產品經理專欄作家?！峨娚坍a品經理寶典》作者，起點學院產品導師。多年電商產品實戰經驗。主導過多業務的電商產品搭建、更新迭代。關注電商領域，包括電商中臺、產品增長、商業模式、跨境出海等方面。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Pixabay，基于CC0協議
專欄作家
劉志遠，公眾號：遠哥聊產品。產品團隊leader。暢銷書《電商產品經理寶典》，起點課堂產品導師。多年電商產品實戰經驗，電商產品類暢銷書作者。主導過多業務的電商產品搭建、更新迭代 。關注電商領域，包括電商中臺、產品增長、商業模式、跨境出海等方面。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
基礎數據模塊，商品類目屬性對接時，如果第三方商家系統中類目與電商平臺不一致，怎么處理
同問
今天要做一個同步訂單的設計硬是不知道怎么設置，干貨慢慢，后臺好搞，界面怎么打通呢
建議舉例說明，有例子的話可以幫助理解，不會像現在這么抽象，對于外行來說太難理解了。有點浪費整篇文章滿滿的干貨。
有點像阿里的“小前臺-大中臺”+后臺erp模式，后臺可以采用平臺自帶的，需要付費使用，也可以是商家自己開發的，非常棒
挖個墳：有文章有異議的老鐵，不要激動。 這套方案適用大的供應商和平臺直接的對接，如果是中小型的供應商，直接入駐平臺， 直接在平臺操作。
B2C電商平臺有很多家，每家對商品的屬性要求必填和非必填都不一樣，而且訂單的狀態也不同，對于發貨處理退款怎么在店鋪開放平臺統一管理呢？
微信登錄，百度地圖，QQ登錄等等其它三方平臺，提供的開放api，總體的思路和這些沒有太大區別，這個思路轉到各大電商平臺。挺好。但是如果沒有一定經驗，或者說不是程序開發者出身，理解下來要難許多，我相信很多產品，要提供個QQ登錄，要提供社會化幾大平臺的分享推廣途徑，大多可能都不清楚這其中一個實現流程。幸好我是程序出身。
文初解釋的電商平臺和商家之間因多對多關系造成的進銷存和訂單難以同步問題，采用這種解決方案，我認為很棒。打通各大河流匯總。不過這樣就有幾個問題，對于究竟需不需要提供這種需求的解決方案，影響因素還是比較多。
1.不管入駐哪個電商平臺的商家，若要實現這個功能，就必須有自己的開發部分，更迭代碼，接入開放api，他們的成本就產生，因為要接入每個投放了店鋪運營點的電商平臺api到自己的ERP系統中。這就要求這個商家非大戶不可，我知道文中有提及此項內容，但我認為這個成本必須再說。
2.比方案前提，電商平臺需開發這些開放api給大企的商家，但首先需保證每個電商都能提供此種開放api，最終達到商家統一管理的需求高度。但市面上的京東，淘寶等用戶流量大的電商是否會提供出來呢？這就又說回到第一點，許多入駐電商平臺的商家我個人是認為不是大企，而且比重應該很大了。而這些一般店鋪都是從其它大企產生他們自己的進銷存。品牌類的更是。
總說幾句，我最想說的還是這個思路真的很棒，我自己看完，再思考，感覺就是很豁然開朗，從自己的分析點上就是考慮這個需求是否能夠滿足普遍商家上。這種比較適合大型企業和電商平臺的合作，但中間開放些什么api，簡單點就是數據了，數據安全多么重要，所以還是要好好考慮了。以上，純屬個人想法，感謝這種解決問題的思路方案，也是受益良多。
你好，感覺好復雜，B2C電商平臺開放給第三方商家入駐，給商家更多權限，自主管理商品和訂單支付渠道，這樣不可以嗎？
對于一般的商家而言，也沒有那么多的資源來對接各家的API，一般的平臺肯定會提供基本的可視化管理功能，這個是基礎和前提，只有是大戶人家，才會去考慮合并第三方平臺的api接入到自己的erp，以求統一，快速，高效的一致性管理