跳到主要內容
獨立商品被塞進規格表，蝦皮改價流程出了什麼問題
很多人以為，在蝦皮後台「改價格」只是調整幾個數字。但只要實際碰過一次，就會發現問題根本不在於操作速度，而是在於商品結構與規格表被誤用後，所產生的人力災難。
這篇文章不是抱怨，而是試圖把結構講清楚，讓平台、賣家、客服都能理解：為什麼某些情況下，改價格會變成一件幾乎不可維護的事。
賣家誤用「蝦皮規格表」
在多數人的理解裡，規格表通常代表的是顏色不同、尺寸不同、材質或包裝不同——也就是「同一個商品，只是屬性不同」。但在實務上，並非所有規格選項都只是屬性差異。
在我所使用的規格表中，每一個選項其實都具備以下特徵：
- 各自對應到不同的實體商品
- 各自有不同的庫存
- 各自有不同的成本與售價
- 本質上是「獨立的特定商品」
換句話說，這些選項並不是「同商品的規格」，而是本來就應該獨立上架的商品。
獨立商品被「硬塞」進規格表
真正的問題出在這裡。為了方便前台呈現，或減少商品頁數，賣家將同系列、同車款，但實際上應該獨立存在的商品，全部塞進同一個車款商品頁的規格表中。
這樣做的結果是什麼？表面上看起來是「一個商品頁，有很多規格可以選」，實際上卻變成「一個商品頁，裝了數十到上百個本來就該獨立存在的商品」。這已經不是規格設計，而是用規格表取代商品分類系統。
商品頁成為「多商品容器」
在這種設計下，一個商品頁不再代表一個商品，而是變成：
- 一個頁面包含數十或上百個獨立商品節點
- 每個節點都有自己的價格需要維護
當這樣的結構被大量複製後，問題就會被放大。
以實際案例來說：同一車型有 56 個商品頁、每個商品頁包含約 100 個獨立商品選項，結果就是：
- 56 × 100 = 5,600 個獨立價格節點
改價格變成 5,600 次人工操作
在上述結構下，所謂的「改價格」已經不再是「調整一個商品的價格」，而是變成「對 5,600 個獨立商品節點，一筆一筆手動修改價格」。
而在蝦皮目前的後台操作情境中，這通常意味著：
- 沒有真正可套用的價格規則
- 沒有可靠的一鍵批次邏輯
- 無法用結構性方式一次完成
實際能做的，往往只剩下最原始的人工作業流程：
- 複製價格
- 貼上價格
- 儲存
- 切換到下一個選項
- 重複以上步驟
這不是人慢，而是設計逼人慢
在這樣的結構下，出現以下現象其實非常合理：
- 作業速度慢，是正常結果
- 長時間操作造成視覺疲勞，是必然
- 價格錯誤遲早發生，是風險累積
- 沒有人願意長期承擔，是人性
因為這套結構從一開始就不是設計來給人維護的。
做過一次，就不想再做第二次
只要親手完整改過一次價格，就會立刻明白：這不是「不想做」，而是「做過一次就知道，這件事不該用這種方式反覆進行」。也正因如此，這類工作往往會被延後、被擱置，直到出現一個「可以承接的人」，才重新被啟動。
結構性地獄任務，某人的痛苦
這裡其實同時存在兩種問題：
- 平台問題：抽成提高、後台缺乏結構化調價機制
- 人為設計：將獨立商品誤用規格表集中管理
但這兩者疊加的後果，通常不會反映在系統設計討論、管理決策會議、報表與數據上。最後只會反映在某一個具體的人身上，包括：
- 花掉的時間
- 承受的視覺負擔
- 必須高度專注避免錯誤的精神壓力
- 長期累積的身體極限消耗
請不要再說「不就改個價」
如果只看結果，確實只是「價格變了」。但你看不到的，是背後那 5,600 次本來不該存在的人力補洞行為。
當價格修改變成災難，問題不在於誰不夠努力，而在於結構本身，已經超出了人力可維護的範圍。這件事，值得被好好看見，也值得被重新設計。