對于不同渠道的訂單該如何管理，才能有效的降低運營壓力？或許商鋪開放平臺能夠解決這一個問題。那么如何設計呢？文章對此展開分享。

很多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思維導圖整理如下，僅供參考：

相關閱讀：

電商開放平臺產品設計（1）：商品開放平臺

#專欄作家#

劉志遠，公眾號：遠哥聊產品，人人都是產品經理專欄作家?！峨娚坍a品經理寶典》作者，起點學院產品導師。多年電商產品實戰經驗。主導過多業務的電商產品搭建、更新迭代。關注電商領域，包括電商中臺、產品增長、商業模式、跨境出海等方面。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Pixabay，基于CC0協議