網店庫存管理規劃：現貨、預訂與多渠道訂單如何避免混亂

網店庫存管理：最後一件貨在門市與網站同時售出

網店庫存管理最難的，往往不是在商品頁輸入「剩下一件」，而是門市、網店及其他渠道同時有人落單時，誰有權將這件貨留給哪張訂單。假設一間荃灣商戶在門市售出最後一件產品，網上顧客同時按下付款；若庫存只在職員每日收舖後更新，網站仍可能接受無法交付的訂單。這是用來推演流程的假設，不代表所有網店都適合把所有渠道接進同一套系統。

規劃前先分開三個數字：貨倉實際在手、已承諾給訂單而保留的數量、仍可供新客人選購的數量。三者可能因未付款訂單、退款、退貨、預訂及門市交易而變動；如果商品有顏色和尺碼，每個變體還需有清楚識別。先定義數字和更新責任，程式才有可能正確顯示。

狀態一：實際在手與網上可售不是同一回事

貨倉點算是起點，不是所有答案

職員盤點到十件貨，不代表十件均可在網上賣：部分已經預留給客戶、需要檢查品質，或放在另一個不供網店出貨的位置。應先寫下可售數量如何得出，哪些調整要記錄原因。商品後台不要用單一「有貨／無貨」標籤代替真正的進出紀錄；同一數量突然改變時，應能回查由哪張單、哪個渠道或哪次人工操作造成。

訂出何時扣減以及何時釋放

顧客把貨加入購物車時是否保留？進入結帳但尚未付款呢？付款被拒、逾時或顧客離開頁面時又幾時放回可售？每種做法都有成本，商戶要按付款方法、訂單確認時間和商品稀缺程度決定。不能把「顯示庫存」誤當成預留機制；由購物車到付款成功之間，另一名客人也可能買到同一商品。可把付款狀態與訂單對數納入庫存保留測試。

狀態二：預訂商品應另訂交貨承諾

預訂不是把庫存數字改成負數

若商戶容許未到貨商品先接受訂單，商品頁要交代這是預訂、預計交收方法，以及哪些日期只是估計、需要再確認。系統還要分清可訂數量是根據供應資料、商戶設定，還是沒有設上限。不能因為程式允許負庫存，就推定商戶真的能交貨；收到預訂後，要有職員跟進供應和聯絡客戶的流程。

現貨與預訂放在同一張單

假設購物籃有一件即日可出貨產品和一件需等到貨的預訂品，應由商戶決定一併送貨、分批交收或阻止混合落單。交收方法會改變運費、通知和退款處理，不能只改庫存標籤而不處理後面程序。網店送貨規則測試集已詳述混合購物籃的運費；本篇焦點則是如何在每個狀態承諾貨量及避免超賣。

狀態三：商品編號要能對上每個銷售渠道

用 SKU 識別變體，不靠商品名稱猜

同一款產品的尺寸、顏色或包裝可能不同，對庫存而言應明確分辨。門市收銀、網店和其他平台若各用不同名稱，先建立對照表，避免把「黑色細碼」與「黑色中碼」合成一件貨。若不同渠道使用同一 SKU，要問倉庫是否真的共用同一批貨；若庫存分開，也要知道何時移撥，避免兩邊同時把相同貨量當可售。

商品組合與贈品也會扣實物

一個套裝在前台只顯示一件商品，後台可能需要扣兩種實物；贈品雖然售價為零，仍有有限數量。須決定套裝能否拆賣、缺少其中一件時是否整套不可售，以及退貨時每個組件如何回倉。沒有組件對照，就算前台庫存看似正確，也可能在實際執貨時發現缺件。

多渠道同賣：先決定哪裏是庫存依據

同步方向與時間差

若門市系統是主資料庫，網店每隔一段時間讀取一次，可能在同步空檔重複售出；反過來說，讓兩邊任意改庫存也會出現衝突。先定義哪個系統擁有最終數字、各渠道的更新方向、同步失敗如何提示，以及發生衝突時誰有權裁定。要測試中斷連線後重新同步，不應只驗證兩邊都在線的理想情況。

同步不了時的臨時營運辦法

系統接口故障未修好前，是否暫時隱藏限量商品、減少可售配額，或以人工覆核接單？不同做法要由商戶按商品性質與客服能力決定。不要讓前台持續聲稱「現貨」，後台卻已知道數字不可靠。若有門市和網店分區存貨，轉貨需要有數量與責任紀錄，否則每個渠道都會覺得是另一方拿了貨。

• 訂出每個渠道使用的商品識別與庫存來源。
• 標記同步失敗後如何暫停或限制接單。
• 建立人工調整原因和操作人紀錄。
• 定期以實物點算結果對照系統差異。

訂單例外：取消、退款和退貨如何回庫

取消訂單不一定即時變回可售

付款失敗後通常要知道貨是否仍被保留；付款成功後顧客要求取消，還要看貨是否已執好或交給送貨。不能對所有「取消」都自動加回可售數量，否則貨物可能根本不在貨倉。先把訂單狀態與倉庫動作對上，由負責人核准退回數量，並防止同一事件處理兩次造成多加庫存。

退貨要先確認狀態和檢驗結果

貨品寄回不代表可立即轉售。商品可能缺件或損壞，亦可能需要重新包裝。退款與庫存是兩個相關但不同的事件：財務完成退款，不應自動代表倉庫已收到可售商品。記錄檢查人、檢查結果及數量，才可判斷回到可售、另行處理或報廢。

把庫存問題轉成清楚的事件紀錄

每次數量改變都有來由

商品可售量從三件變成兩件，可能是網店新訂單、門市銷售、職員移倉，亦可能是發現其中一件損壞。系統需要把「事件類型、商品識別、數量、時間、操作來源」記下；直接改寫餘額而完全不留原因，月底盤點時很難追查。這不一定需要複雜的倉庫系統，重要的是每個渠道有一致的紀錄方式。若人工調整，應寫明調整前後的數量及批准人。

假設同一 SKU 在短時間出現兩張訂單，要判斷哪張先保留，應以系統實際確認的順序和商戶同意的規則處理，不能靠職員憑電郵到達時間猜。訂單通知可能延遲；實際資料庫紀錄與付款確認也可能分階段寫入。設計時要先說清在哪個狀態才承諾貨量，供客服查核時也能讀懂。

批量匯入不是逐格人工輸入的放大版

商品資料若從試算表大量匯入，需要先定義 SKU 必須唯一、數量欄位容許哪種值、空白代表忽略還是清零，以及匯入失敗時整批回退還是只處理錯誤列。職員應在測試環境用含重複 SKU、錯誤尺寸與空白數量的資料做演練，確認錯誤報告能指出具體哪一列。直接在正式站上載未檢查的檔案，可能把原本正確的可售數量覆蓋。

匯入後不能只看「成功」訊息，要抽查幾件高銷量產品及少見變體，比對原始表和網站前台。若同一時間仍有客人落單，先定義匯入期間新訂單如何計算；否則批量數據可能把剛扣減的數量寫回舊值。較穩妥的做法取決於系統功能與店舖營運安排，先在低風險時段測試，再決定正式流程。

兩人同時搶最後一件貨，程式要有明確結果

購物車上的數字不是最終確認

客人 A 把貨放入購物車但未結帳，客人 B 可能已完成付款。若商戶沒有設定預留機制，購物車只能顯示當時看到的可售狀態，真正提交時仍需重新核對。若選擇短暫預留，則要有到期處理，避免大量未完成訂單永久鎖住貨品。兩者各有商業取捨，應由商戶明確說明給顧客，不能在按付款時才突然出現無解釋的「缺貨」。

技術上，同時提交必須避免兩張單都認定自己買到最後一件。開發同事應按資料儲存及交易流程設計一致的扣減，並用平行落單的測試檢查結果；不能在讀取頁面時做一次數量判斷，隔一段時間才無條件寫入。若付款已成功但庫存衝突，還要按商戶政策有清楚的補救與退款處理，不能只在網頁跳出錯誤便結束。

支付失敗後釋放預留，避免幽靈缺貨

某些顧客可能在付款頁離開或付款被拒，後台留下待確認訂單。這類訂單幾時不再保留存貨，要配合實際付款流程及商戶接單政策；設定過長會令有貨商品顯示缺貨，過短又可能讓稍後成功的交易找不到貨。不要抄一個固定分鐘數套在所有付款方式；先記錄每種方式如何確認成功，再設定對應的保留與人工覆核步驟。

測試時建立一張未付款訂單，觀察可售數量，模擬付款逾時，再檢查是否只釋放一次。接著測一張付款確認延遲才到達的訂單，看看庫存和財務狀態會否出現衝突。客服應有可查看的異常狀態和跟進方法，不能默默把已付費客人的訂單取消。

商品組合及退貨需要單獨的庫存表述

套裝拆開退其中一件時怎樣算

假設套裝由主機與配件組成，客人只退配件，前台的一套商品不能直接整套加回可售。倉庫應記下收回的實物及狀態，後台則依既定規則調整組件；若套裝不能分拆退，亦應在銷售與售後安排中清楚說明。選擇簡單的庫存系統時，要看它能否表達真實的退貨流程，否則就要安排明確的人工紀錄。

贈品也可能因訂單取消而回收，但若贈品已交付、主商品後來退款，是否收回由商戶政策決定。技術系統不應憑「主商品退款」便自動把贈品數量增加。加入活動前，營運同事最好挑最容易出錯的套裝、贈品與換貨情況做演練，從出貨、退款、退貨到重新入庫都走一遍。

換貨是一次退回與一次新保留

客人由中碼換大碼，表面是一宗售後查詢，但兩個變體的庫存都會受影響。舊尺碼是否可重新出售，要等實際檢查；新尺碼是否預留，則要有職員確認時間。若兩個動作只在聊天紀錄中討論，網店前台可能繼續出售已答應留給客人的大碼。將換貨需求與相關訂單連起來，客服、貨倉與店主才看見同一版本的資料。

如需寄回後再交付，送貨狀態亦可能有兩段，不能用第一次配送的「已完成」掩蓋第二次交收。按店舖實際工作方法決定新建紀錄還是於原單建立子流程，重點是每個 SKU 的數量更動有依據，客人也收到一致說明。

數據對不上時，不要急著把系統數改成點算數

先追差異從哪天開始

點算發現系統顯示五件，貨架只得四件，先記錄商品、地點、批次及實際點算人。查最近銷售、取消、退貨、調撥、贈品活動和人工更正，看看是某筆事件漏記還是貨品真的遺失。若直接把系統改成四件而不留下原因，明天同一條漏記的同步事件再次發生，差異又會重現。需要即時避免超賣時可暫時限制可售數量，但同時開一張待查事項。

若涉及多個平台的時間差，對照各方紀錄時要確定時區與訂單識別一致。相同客人可能改過單、取消再重買，不宜只按姓名或總金額去配對。找到源頭後修流程：例如門市職員用錯商品代碼、網店重複處理通知，或匯入檔覆蓋了最新數字，改好後再重跑例外測試。

盤點頻率由風險決定

銷量快、貨量少或容易混淆變體的產品，較需要頻密抽查；存放穩定的普通商品則可按商戶人手安排。不要為了製造一個整齊的「每週盤點」規則而犧牲營運能力。先找過去最常有差異的商品類型與渠道，用一份明確的抽查表記錄結果，將問題回饋給商品資料、銷售和倉庫各自的負責人。

經常追不到差異的網站，可能需要更細的事件紀錄及更清楚的權限，而不只是把顯示數量改得更快。先補證據和分工，再決定是否需要新功能。商戶即使只賣少量貨，這份紀錄仍有助避免客服向客人作出沒有貨的承諾。

第一版系統可以怎樣收窄範圍

先揀能代表難題的商品

與其一次匯入所有產品後才測，不如先挑一件單規格現貨、一件有尺寸顏色、一件套裝、一件預訂，以及一件不能送貨或需特別交收的商品。每件都準備虛構訂單，跑過付款成功、失敗、取消與退貨。若現有員工能按這組樣本完成操作，才逐步擴展其他商品；如果連樣本都含糊，立即匯入全店只會放大錯誤。

這也能幫商戶決定是否需要即時跨渠道同步。假設目前門市每天只賣少量不同商品，但網店商品屬高度限量，可先研究可售配額與人工覆核如何配合；若兩邊經常同時出售同一 SKU，便要更重視同步失敗的處理。不要把「即時同步」當成一句無條件承諾，要求系統供應方展示實際事件流程與異常處理。

員工交接也屬於庫存設計

負責人放假時，誰批准人工調整？門市點貨發現少一件，向誰回報？網店接到缺貨訂單，由誰核對付款、通知客人和決定退款？把這些實際工作寫進後台權限、通知和簡單操作說明，系統才能跟人合作。若只有一位老闆記得所有例外，網站顯示的數字終究難以保持準確。

每次修正庫存規則後，拿相同測試商品重跑一輪，尤其檢查訂單失敗和重複通知。保存「改動前問題、改動後結果、仍需人工處理的事項」，讓下位同事能接手。平台選擇、商品輸入與交收測試都是相連工作，但真正開始仍是清楚分開實物、保留與可售數量。

先演練一個完整的工作日

開門前先看哪些訂單仍佔貨

門市同事準備開舖時，先在一個可見的位置查待付款、待包裝和已承諾自取的訂單，知道哪些貨不能再擺在貨架當現貨出售。如果不同人各自從手機訊息抄訂單，便很難確認最新版本。簡單交接表可列 SKU、數量、訂單狀態與交收方式，讓門市和網店同事用同一組資料開始工作。後台顯示有貨時，也要問這是剛同步的數字，還是昨晚已過期的資料。

中午出現庫存衝突，誰先處理

假設店員售出最後一件，但網店同期產生待付款訂單，先核對交易的實際時間、已保留政策與付款結果，不要只看哪個同事先報錯。若確定無法按原計劃交付，由指定負責人通知受影響客人，說明可選的改期、更換或退款安排；網站也要立即更正可售狀態。別讓客服自行作出沒有供貨依據的承諾，亦別把庫存負數藏在後台而讓新客人繼續落單。

收舖盤點後，怎樣防止舊資料覆蓋新單

員工在門市盤點並輸入系統時，要確認網店當日的新訂單已經計入；否則一個「晚上更新存貨」的表格可能把傍晚剛售出的貨又寫回可售。盤點與訂單紀錄最好有一個共同的截止時間，清楚指出盤點表是截止哪一刻的實物數量。若不能即時整合，安排人工比對和暫時降低可售，直到數字對得上；採購新系統前，這個流程也可以作為必須演示的例子。

低貨量商品的通知要精準而不製造假警報

預警對象應是能採取行動的人

某 SKU 接近缺貨時，後台通知應送到能補貨、停售或回覆客人的負責人，而不是無差別發給整間公司。對預訂商品，低貨量可能意味已承諾數量超出可交付上限，處理方法和現貨補貨不同。先分類商品及例外情況，再定提示文字和接收人。若每天發大量無法處理的警報，職員很容易忽略真正緊急的訂單。

通知亦要提供可查證資料：哪個 SKU、哪個渠道、系統認為剩多少、最近哪幾筆事件改變數量。若數字來自延遲同步，提醒要說明資料更新時間，避免營運同事立即按過期數字安排採購。收到通知後由誰確認、怎樣標記已處理、何時再查，均可在小商戶的簡單工作表裏完成，不必先買一套龐大工具。

顧客看見「有貨」應對應實際承諾

對低存量商品，網站可以按實際可售狀態清楚說明現貨、預訂或需要確認，並確保商品頁與結帳頁用同一邏輯。不能商品頁寫現貨，付款前才以小字改為待確認。假設供應商只能給不確定的到貨期，應由商戶制定對外說明與接單上限；系統不能把不確定日期顯示成準確的交付承諾。營運同事定期抽查幾件暢銷貨的前台文字，能發現後台狀態同步不到位的情況。

三張對照表，讓新同事也能接手

第一張是商品識別表，列出各平台名稱、SKU、變體與套裝組件；第二張是狀態表，寫明待付款、已確認、取消、退貨各如何影響保留及可售；第三張是例外表，列出同步失敗、調貨、盤點差異與售後換貨的處理人。即使目前使用人工表格，也能依這三張表發現規則矛盾。日後換網店平台時，便能把具體工作和資料結構交給供應方，不用只說「要一個庫存功能」。

每張表都要定維護人和更新日期。若更換套裝內容或新增銷售渠道，先更新識別與狀態，再進系統改設定；工作次序倒轉，前線便會跟不上網站顯示。這份文件只要足夠清楚讓新同事按流程處理首宗訂單即可，不必寫成技術術語堆砌的手冊。

如果商戶由供應商代為保管部分貨品，系統顯示的「在手」還要標明地點與可取貨狀態。帳面上有貨但尚未到達可出貨倉庫，是否開放網店接單，應由商戶按照交付承諾決定。網站不能只把幾個地方的數量相加就宣稱立即有現貨；前台交付說明與庫存可售定義必須一致。

測試時分別讓門市與網店同事處理同一款商品，觀察一方完成交易後另一方何時看見變化。若不同步，記錄可接受的人工限制及臨時停售方法。成功的庫存管理不只是兩個畫面數字相等，而是接單、執貨和售後的人都知道那個數字代表甚麼，以及遇上差異應找誰確認。

若商品因品質檢查而暫停出售，系統應容許標記不可售及調查原因，避免職員為了讓前台顯示無貨而直接刪去真實在手數量。完成檢查後再依紀錄恢復，日後盤點才可分辨實物仍在與已經售出。

對供應商而言，庫存狀態也應可由商戶自行看懂與查證；若一有差異便要等待開發人員從資料庫逐筆找原因，日常接單會受到影響。需求中可要求簡單的查詢和匯出方法，並用真實工作樣本驗收。

建立測試清單，把最後一件貨重演一次

用虛構訂單走完整個路徑：先在網店與門市幾乎同時售出最後一件，再測試付款逾時、員工人工調整、其中一張單取消、另一張單要求退貨。每一步都核對實際在手、保留及可售，並看顧客是否收到正確的交付說明。準備新網上商店時，應把這些例外列入需求；若涉及網站後台設計和主機接駁環境，則要確認錯誤可見及操作可追查。網店平台比較與開張前檢查提供選擇與上線層面的問題；如要按現有庫存流程討論實作，可從聯絡 Black Media開始，先帶商品和訂單狀態清單。