電商后期制作「電商處理售后怎么做比較好」

編輯導語：商品在整個電商系統(tǒng)中處于核心位置，因此商品維護對于電商后臺設計的重要性不言而喻，本文作者以此為出發(fā)點，和我們聊一聊在電商后臺設計中關于商品維護的那些事。

對于電商系統(tǒng)來說，商品模塊的維護可以說是核心功能了，整個系統(tǒng)都是圍繞商品來進行運營的。所以能否設計一個靈活便捷的商品模塊，對于整個系統(tǒng)的操作都非常重要。

今天我們就來聊聊商品管理那點事，對于商品信息的維護，它的本質是對一堆屬性和屬性值的管理，理清其中的關聯關系，就能將其玩轉的游刃有余。

首先我們先來看看一個商品都有哪些屬性，下圖是某電商平臺的商品圖：

整理一下可以得到其中的屬性：商品名稱、品牌、品類、顏色、內存、價格、圖片、商品編碼、CPU型號、機身存儲、商品毛重、操作系統(tǒng)等等。

在上一篇《電商后臺設計：屬性管理》中，我們將這些屬性分了四類：基礎屬性、銷售屬性、搜索屬性、特有屬性。除了其中的搜索屬性被融合在特有屬性中，其它的功能在商品信息維護中都有所涉及，接下來我們一一進行討論。

一、基礎屬性

對于所有商品包含的屬性，都可以歸類到基礎屬性中，如商品名稱、品牌、品類、狀態(tài)等。對于基礎屬性的維護比較簡單，由于都是單一可以確定類型，通常根據數據展示形式一一維護即可。

其中有幾個屬性需要說明一下：

品類：由于商品的特有屬性和搜索屬性都關聯在品類上，所以商品品類是必須選擇的。狀態(tài): 上架/下架，確定是否在前臺展示當前商品。這是整個商品的全局控制；如果上架，則之后關聯的SKU也一同上架；反之則一樣。商品類型：單品/復合商品;部分平臺上支持打包出售的模式，也就是一個商品實際上是包含多個關聯子商品的。可以通過商品類型字段先標記出當前商品是單品還是復合商品；如果是復合商品，之后還需要關聯對應子商品。

二、特有屬性

在上一篇《屬性管理》中，我們介紹了商品特有屬性的設置以及與品類的關聯綁定。在商品信息維護時，當選定品類后，我們就能獲得已經設置好的配置內容，接下來根據配置將表單展示出來，并維護好其中的屬性值即可。

品類綁定屬性設置

規(guī)格參數維護表單

三、銷售屬性

在說銷售屬性前，我們先來了解兩個基本概念：SPU和SKU。

SPU：Standard Product Unit (標準化產品單元)

SPU是商品信息聚合的最小單位，是一組可復用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。

SPU通俗的來講就是一類具有相同屬性、屬性值的商品，這些屬性和屬性值通常不參與商品的銷售價確定。如iphone6s就是一個SPU，無論你在那個平臺或者實體店查詢iphone6s，他們給出的商品屬性信息都是一致的。

SKU： Stock Keeping Unit(庫存量單位)

SKU即庫存進出計量的單位， 可以是以件、盒、托盤等為單位。

SKU是物理上不可分割的最小存貨單元，而這個不可分割是相對于儲存場景的，對于相同的商品，在不同的倉儲場景下，對SKU的管理是不一樣的。

舉個列子，我們平時去超市買早餐奶，可以買一袋，也可以買一箱。按最小單元來說，那么”袋”就是超市管理早餐奶的SKU。超市的貨源是來自供應商的，供應商是按箱賣給超市的，所以”箱”是供應商管理早餐奶的SKU。

不知道大家有沒有留意過，在物美、家福樂去買一箱奶，結賬的時候，收銀員不是掃描箱子上的條碼，而是打開箱子取出一袋來進行掃碼，然后再輸入數量最后結賬，這也就能看出這些大超市的對奶制品的管理方式。

SKU可以簡單理解為：SKU = SPU 銷售屬性，當在SPU上添加上商家、顏色、內存等影響銷售加價的屬性后，這個商品就成一個SKU。

看著和上面SKU的定義有點出入，如果仔細想想，商家對商品價格的定義不就是按照商品的最小單元設置的嗎？

所以當我們想要確定一個SKU時，首先需要明確有幾個屬性在影響價格，找到對應的屬性，列出每個屬性的屬性值，通過屬性值的組合就能確定所有的SKU。

對于銷售屬性的維護，也是通過屬性和屬性值來操作的，但是有兩個特殊的地方需要處理:

在完成屬性值的維護后，需要根據屬性值組合來生成SKU：這個是整個商品模塊最關鍵的地方，因為后面的價格、庫存、圖片都依賴于生成的SKU。屬性值的個性化設置：如同一款手機中的相同紅色，不用商戶的叫法各不相同，如炫彩紅、玫瑰紅等待，以及不同的顏色上會上傳不同的款式的手機樣式圖。

維護好銷售屬性和屬性值后，就能通過組合產品唯一的SKU，之后商品的銷售價格、訂單、庫存等一些屬性信息，都需要與SKU直接掛鉤。

所以這里有一個特別需要注意的地方，一旦確定了組成商品的SKU銷售屬性后，就不能再做對銷售屬性進行修改；如果添加或刪除銷售屬性，之前生成的SKU數據肯定就不對了，而添加或刪除某個具體銷售屬性的屬性值僅會影響部分SKU的數據。

1. 商品價格

在SKU維護時，有多個價格的設置，需要注意每個價格的用途：

1）采購價

采購人員從供應商那里采購商品時的價格，系統(tǒng)中有幾個處會使用采購價的地方：

商品采購入庫時，商品的采購價格會同商品信息一起保存在入庫單中；在填寫商品的日常銷售價和活動銷售價時，會通過對比采購價，防止銷售價格過低而使企業(yè)受損失；商品完成訂單銷售后，系統(tǒng)計算銷售成本和應收金額時使用。

2）吊牌價

吊牌價通常是供應商在商品出廠時，為商品所設置的一個市場銷售參考價，價格通常會和商品的一些質檢信息一同寫在商品的吊牌上。吊牌價一般在線下使用的比較多，如商場里的服裝時最為常見。

在線上系統(tǒng)設計時，吊牌價僅僅為銷售價設定起到一個參考作用，實際價格我們一般采用另一個概念——銷售價，銷售價又分日常銷售價和活動銷售價。

3）日常銷售價

商品在沒有參與活動時所設置的出售價格就是日常銷售價格，商品在上架期間日常活動價會一直存在的。

如果是個體商戶，戶主自己根據進貨價設定價格，如果是大的自營電商，通常由采購人員根據采購價和期望利潤來確定日常銷售價。

4）活動銷售價

商品參與活動時所設置的銷售價格就是活動銷售價，活動銷售價只有在活動期間有效；活動過期，商品售價又會使用日常銷售價。大的自營電商里面，通常由采購人員來維護。

5）預警價

預警價格的設計主要是為了防止商品運營人員錄入失誤，將商品出售價格設置的過低，導致企業(yè)損失而設置的預警功能。

這個和采購價有部分類似，一般低于采購價是允許出售的。如一些即將過期的產品或拉新做的活動，但是低于預警價通常是不讓出售的。

常用的兩個地方：日常銷售價維護和活動價維護，這兩個價格在保存前都需要和預警價進行比對，如果低于預警價，系統(tǒng)會給出提示，以確保價格設置正確。

2. 庫存

對于SKU的出售自然就涉及到了庫存，在商品維護界面僅有一個對庫存數維護的地方，也就是實際可售庫存。

對于大平臺的入駐商戶來說，通常采用手動錄入方式(有開發(fā)能力的可以做系統(tǒng)對接)，讓商戶自己維護SKU的銷售數量。具體填寫多少由商戶自己決定，這個填寫的數字就是實際可售庫存。

而對于平臺自營來說，公司通常都有自己的倉儲系統(tǒng)，每個SKU都有明確的存儲記錄，并且部分SKU參與內部任務(如調撥、拍照、戰(zhàn)略儲存等)使得當前時間不可售。

因此實際的SKU庫存可能并不等于全部可售，具體實際可售庫存需要通過倉儲系統(tǒng)經過統(tǒng)計同步到商戶模塊中，而不是由買手自己手動維護。

3. 上架/下架

除了在商品的基礎屬性上設置有商品的上架/下架操作，通過在具體的SKU上也設置一個上架/下架操作，可以更加細粒度的管理到具體的SKU上下架狀態(tài)。

4. 第三方編碼

平臺在生成SKU時，會為每個SKU也分配相應的揀貨碼(可能是商品身上的條碼，也可能是公司內部自己定義的編碼)，以方便揀貨時使用。

如果是自營平臺，買手采購時供應商會提供給采購平臺以便錄入系統(tǒng)；如果是平臺商戶，一是平臺沒有辦法采集數據，二是各商戶各自在揀貨時使用的規(guī)則各不相同，所以僅給一個可以讓商戶自己維護的字段。

當有訂單產生時，在訂單模塊中導出的揀貨單中會帶有維護的第三發(fā)編碼以供商戶進行揀貨操作。

5. 圖片維護

商品各位置的展示圖片，圖片維護通常有三個地方：列表圖、SKU圖組和默認圖組。

列表圖：主要是搜索列表所展示的圖片；SKU圖組：為每個具體的SKU上傳對應的一組展示圖片，主要用在商品詳情頁的展示上；默認圖組：如果對應的SKU未設置展示圖片，則顯示默認的這組圖片進行展示。

小知識點：圖片在展示時，為了能夠提升圖片展示速度，優(yōu)化頁面展示速度，商品圖片在上傳時通常會通過縮放，將圖片保存成多個不同的尺寸，以方便不同頁面進行調用。

6. 導入功能

電商平臺上的商品成千上萬，如果都通過常規(guī)的表單一個一個維護，維護人員就得被累死了(看一下一個電子產品有多少產品規(guī)格)，通常系統(tǒng)都會設計導入功能供維護人員使用。

在商品信息的導入功能里有兩個限制：

一是一次只能導入一個品類，因為不用品類的特殊屬性不一樣，沒有辦法合并在一起；

二是僅能導入基礎屬性和特殊屬性信息，銷售屬性信息不支持通過導入生成，因為銷售屬性需要通過屬性值組合成SKU信息，系統(tǒng)需要生成唯一ID， 內部邏輯比較復雜。

【#】后面為需要導入的特殊屬性列表。

上面介紹的內容，基本涵蓋了一個商品的核心信息，大家有需要的可以根據自己的實際業(yè)務場景再進行優(yōu)化修改。

四、商品維護流程

最后我們再來看一下商品的維護流程。

在電商平臺上的個體商戶，由于自家SKU數量比較少，從錄入商品參數到商品拍照、上架一個人基本都能解決。

但是對于自營平臺過萬的SKU，這樣的方式顯然是不行的。大平臺對一個商品的維護需要多個部門協同合作來完成，基本流程如下：

采購部：買手先維護好后端品類，為每個品類綁定關聯屬性，并設置好屬性輸入方式、搜索方式等基礎配置信息。采購部: 買手從供應商獲取采購商品基本信息，并將商品基本信息導入系統(tǒng)中，并根據銷售屬性生成SKU。采購部：買手通過采購單采購商品，并協同倉庫一同將商品錄入倉庫完成商品采購，系統(tǒng)完成SKU同步庫存信息，買手完成日常銷售價格的維護。采購部：買手在系統(tǒng)提交商品圖像采集工單。圖像采集部：圖像采集部同事根據工單申請倉儲圖像采集調撥工單(將之前錄入的SKU每件調撥出來一件)。倉儲部：根據圖像采集調撥單，準備調撥商品。圖像采集部：圖像采集部同事和倉儲部進行交接出庫，拿到樣品、進行拍照、修圖，完成后再上傳到系統(tǒng)中。圖像采集部：拍照完成后，將商品再還回倉庫中。倉儲部：將商品重新放回倉庫中。采購部：買手檢測商品信息完善后，就可以進行日常上架銷售了。

以上四個步驟中，除了第三步采購入庫、設置價格會經常使用，其它的三步僅在商品第一次錄入系統(tǒng)的時候需要維護。

對于上述操作流程有人可能有疑問，通常不是運營在做產品銷售嗎，這里怎么是買手呢？

在電商企業(yè)中買手的工作范疇主要是維護商品信息、采購、維護銷售價格以及下上架；而運營人員主要負責構建活動、專題框架、活動和專題中的具體商品由買手來決定是否來參與，最終的利潤由雙方來分(運營和買手的薪資是和銷售額有關的)。

這個在后期的運營篇中會給大家繼續(xù)講解！

作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)

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

題圖來自 Pexels，基于CC0協議。