網店與門市同時接單，如何避免最後一件貨賣出兩次？

先定義可以承諾出售的存貨

畫面顯示「尚餘一件」，只代表某一刻的讀數。網店結帳頁和門市收銀機可能同時讀到這個數字，在任何一方寫入訂單前，都以為自己可以承諾同一件貨。因此先要界定「可售」：同一款式或規格、同一儲位、實際存在、沒有損壞，而且未分配給其他客戶。不同顏色、尺寸或地點的貨未必可以互換，不能只看產品系列的總數。Shopify 的庫存資料亦把貨品、地點和不同庫存狀態分開；即使沒有採用該平台，這些概念仍可幫助店主整理規則。

把每個數字由誰負責寫清楚。網店、收銀系統、市集連接程式和倉庫試算表，不能全部同時自稱最終準確。如果由一套系統掌管可售數量，每條銷售渠道就要向它取得預留結果；如果由平台掌管，其他渠道便要依照平台確認的結果。收貨、售出、退貨、損壞和人手調整都應保留原因及經手人，否則晚間只見到總數差異，仍然找不到成因。還要決定把貨放進購物車是否已經預留，或只在下一步才預留。過早預留會令棄置購物車長期佔貨；太遲預留則可能遇上另一宗成交。客戶提示和員工程序須採用同一規則。

讓最後一件貨只有一個成功承諾

關鍵動作不是讀取數量，而是在有並行規則下改變數量。如果零售商自己管理資料庫，可以在同一個交易中，只有未承諾數量足夠時才更新對應的貨品及地點紀錄。另一做法是先鎖住該紀錄、檢查數量、更新後才提交。PostgreSQL 文件說明，行鎖會阻止其他衝突寫入，直至交易完結；應用程式仍須檢查結果，並處理預留失敗。交易應保持短暫，不能在鎖住庫存時等待客戶慢慢輸入付款資料。成功的預留要有獨立編號、訂單參照、數量、地點，以及到期或轉為正式訂單的規則。

如果使用平台，應採用平台提供的並行控制，不能把快取畫面當成最終答案。Shopify 文件指出，某些庫存變更支援「比較後才寫入」；預期的舊數量已過時，操作便會失敗。平台亦區分預留貨及安全存貨等狀態。這只是平台功能，並不表示接上一部獨立收銀機後便自然同步。店主要實測網店、門市及連接程式遇到過時數量時如何反應。若某渠道無法取得確認的預留，可考慮預先分配有限的渠道額度，或保守顯示供貨狀態。但額度轉移和定期對帳要有負責人，不能把同一批實物貨憑空變多。

用最後一件貨演練兩條銷售渠道

假設中環門市只有一個可出售的電熱水壺，其他地點亦沒有可代替的款式。下午兩時，一名顧客開始網上結帳；幾乎同時，店員在收銀台掃描該件貨。網頁較早顯示的「尚餘一件」只供參考，不是保證。兩條渠道都要請求同一項庫存承諾。如果收銀台先取得確認，網店應在發出不能撤回的訂單確認前，清楚顯示這件貨已無法供應；其他購物車貨品應保留，並可提供到貨通知或替代貨品。收據要連到已確認的庫存變動。若網店先成功，收銀機則要在收款及交貨前警告店員。

再加入付款延遲。系統可能已預留貨品，但付款仍未有確定結果。店主要訂明預留維持多久、甚麼事件令它正式成立，以及過期後才收到付款成功通知如何處理。不能因為瀏覽器關閉便假設付款失敗而即時釋放；也不能永久佔住貨品，令可售數量失真。對於結果不明的個案，員工應在例外清單看到付款參照和庫存預留的關係，再作核查；不能悄悄開第二張訂單當作修補。這是供團隊演練的情境，不代表任何平台預設的結帳流程或適用於所有商戶的預留時限。

處理中斷及人手調整後的差異

庫存服務可能已成功預留，但呼叫它的網店收不到回覆。如果盲目重試並建立第二個預留，畫面便會錯誤地顯示貨被佔用兩次。每次購買嘗試應有穩定的請求識別碼；可行時重試應取得原有結果。記下由「已請求」轉為「已預留」、「已付款」、「已釋放」、「已取消」或「待人手覆核」的過程，並阻止同一批貨被釋放兩次。付款失敗與訂單取消不是同一回事；退款亦不表示退回的實物一定適合再售。員工檢查退貨後才應重新入庫。跨系統的訂單參照須連在一起，讓覆核者毋須逐個郵箱尋找線索。

實物和數碼紀錄須定期對帳，頻率可按銷量及風險決定。逐項比較不同渠道未完成的預留、已履行訂單、待定付款及人手調整，與該地點的庫存紀錄是否一致。特別調查負數庫存、過期卻仍佔貨的預留、已確認但沒有扣貨的訂單，以及有扣貨卻找不到訂單的紀錄。修正應是有理由的調整或正確的狀態轉換，不能直接用預期總數蓋過現有數字。Shopify 關於比較後寫入的建議正好說明：以過時數字覆寫，可能抹走其間真實發生的銷售。如紀錄互相矛盾，應暫停受影響貨品的新承諾，或改由員工實際核查，直至差異釐清。

正式使用前測試失敗情況

先選一個只餘一件可售貨的規格作受控測試，從兩條渠道幾乎同時提交購買，確認只有一方取得庫存承諾。然後再測試網絡回覆遺失、延遲付款成功、取消訂單、損壞退貨及人手盤點修正。除了核對庫存帳，也要看客戶收到甚麼訊息：即使預留在技術上被拒絕，若系統先發出確認信，仍會造成實際問題。不同儲位要分開測試，電話訂單或市集渠道如可繞過主結帳流程，也要包括在內。使用測試付款和不對外出售的測試貨，避免演練變成真正的客戶承諾。

給員工一張簡短的例外處理指引，列出哪套系統掌管庫存、在哪裏看預留和付款參照、誰可釋放或修正，以及何時通知顧客。開發人員可以建立交易鎖和待辦清單，但資料不確定時，應向顧客承諾甚麼，仍由店主決定。驗收時要能跨渠道追出「最後一件貨目前屬於哪張訂單」。如果連單一測試交易都無法重建，加一個漂亮儀表板也只會令不確定性看起來整齊。先從一款高風險貨品和兩條競爭渠道做起，檢視失敗個案，再擴展到其餘目錄。

如果店家有多個地點，還要決定顧客購買的是指定分店的現貨，還是要求店家從任何分店調貨。正在運送的貨，不等同已可供提取。網店若合併所有地點的數字，就要考慮運輸時間、誰負責調貨，以及員工揀貨前門市顧客可能先買走貨品。確認訊息須說明系統真正能承擔的交付承諾。庫存尚未核實時，先讓顧客查詢或要求確認供貨，比即時承諾出售更誠實。客服也要覆核成功及失敗預留的客戶訊息：再好的技術鎖，也需要在顧客錯過最後一件貨時清楚解釋。把相關畫面和回應連到交易紀錄，處理投訴時才不用猜測顧客當時看到甚麼。