台北的員工商城剩下一件大尺寸外套。營運怡安看見客服正在替同事開草稿訂單，同一時間，網站上另一位員工還能選這個尺寸。人資又提醒，晚班同事要到晚上才有空登入，不能把原先答應的名額全交給白天先到的人。怡安現在必須決定，哪一個動作才真正占用最後一件，而不是先把畫面上的數字改成零。
保留時點要跟承諾一致。事前分配給特定員工群組的配額，保護的是整組人在期限內的機會；有期限的領用保留，保護的是一位正在完成流程的人；訂單成立時占用庫存，則把容量交給已被系統接受的訂單。付款完成可以是其中一個條件，但不能假設每個免費領禮、兌換碼或人工訂單都有相同付款事件。
比較這三種方式，最有效的問題是：只剩一件、兩個人同時要，誰得到明確的接受結果？另一人看見什麼？原本保留過期、取消或延遲回覆時，這一件又回到哪個池？本文用草稿訂單與員工分池兩個案例，把這些判斷變成商城上線前能實際驗證的條件。
先寫清楚承諾，再選庫存保留時點
「收到邀請就能選一份禮物」不一定等於「每個尺寸都替你保留一件」。前者可以透過一組核准選項與替代方案履行，後者需要對具體款式、尺寸和數量建立保障。如果邀請文案沒有區分，工程即使沒有超賣，員工仍可能認為公司沒有兌現承諾。
因此先請活動負責人用一句話說明規則。晚班同事是否有獨立名額？同一部門能否跨活動領兩次？領用是先到先得，還是只要期限內完成就應保證有禮？這些都是活動設計，不是單靠商城的付款按鈕就能決定。先把承諾範圍定好，後面才知道哪個保留模型適合。
也要定義訂單成立的意思。有些流程先接受訂單，再等待付款；有些要確認付款後才建立可履約承諾；企業全額負擔的領禮可能完全沒有收款。不要把已付款當成所有流程的共同終點，而應查明實際哪個事件接受了庫存，以及哪個事件只是在等待下一步。
畫面上的可選數量、後台可售數量、已保留數量和實體數量，也應分開看。一位客服說幫你開單，可能只是建好草稿，未必已執行所需的預留操作。另一種情況則是草稿已明確保留，正式轉單時不能再扣一次。差別要靠實際設定與紀錄確認，不能只從單據名稱推測。
三種模型的比較，重點是誰擁有這一份容量
| 保留模型 | 何時退出共同可用量 | 主要價值 | 主要代價 | 必須驗證的結果 |
|---|---|---|---|---|
| 群組事前配額 | 核准數量分配給指定群組時 | 避免較晚登入者的機會被其他群組用掉 | 未使用名額在釋放前不能自由調用 | 外部群組不能侵占，期限後只釋放未使用餘額 |
| 有期限的領用保留 | 合格使用者取得明確保留結果時 | 讓使用者有時間完成選擇或地址確認 | 需處理到期、重試與延遲結果 | 最後一件只有一位有效持有人，過期者不能晚到後重新占用 |
| 訂單成立時占用 | 設定好的權威訂單事件接受數量時 | 把庫存連結到可追蹤訂單 | 較早的瀏覽或填寫階段可能沒有保障 | 接受總量不超過可用量，取消只回補原池一次 |
這不是平台評分表。相同平台可能因付款方式、應用程式、庫存追蹤和人工操作而呈現不同流程。比較的是活動要採用哪種容量規則，再用實際產品文件與測試確認能否落地。關鍵條件尚未成立時，不要用其他項目的高分把它平均成通過。
地點也必須進入比較。台北活動現場的一件，不能因為網頁顯示全台還有庫存，就被快遞訂單直接拿走。若要共享，要有人負責調撥與時間；若現場領取本來有保障，就先隔離該用途的量。全公司總數正確，不代表每個取貨點都履行得了自己的承諾。
事前配額適合保障機會，但不是永久保留所有餘量
對輪班、新進員工或有特定到場期限的群組，事前配額能讓領取機會不完全取決於登入速度。活動負責人先指定數量與適用群組，其他計畫不能在開放期間占用。這裡保護的是可用容量，實物不一定要搬到另一個倉庫，但共同庫存的權限與數量必須真的分開。
配額應精確到承諾需要的程度。若員工只被保證能選一份禮物，可以在核准的選項間安排容量；若承諾特定尺寸外套，就不能只保留總件數。十件小尺寸和十件大尺寸，不能拿來證明二十位需要中尺寸的人都有保障。尺寸池與一般禮品額度是兩種不同的限制。
未使用名額也要有退出規則。寫明哪一天停止新領用、誰確認未完成請求、誰核准釋放，以及釋放後回到哪個用途。期限到了，不能把最初分配的全部數量重新加回共同池，因為其中一部分可能早已屬於有效訂單。可以移轉的是經核對後的剩餘量。
若後台無法證明其他活動不會消耗這個池，就不能只在試算表上畫一條界線當作隔離。可以詢問可支援的群組控制、獨立庫存來源，或另行採用經驗證的作法。規則寫得漂亮不等於系統能執行；一筆來自池外的競爭請求，是驗證隔離是否成立的必要測試。
領用保留適合短暫完成流程，但倒數必須有實際依據
領用保留應從使用者得到明確接受結果開始，而不是從打開商品頁開始。只有畫面上的倒數，卻找不到後台對應的容量紀錄，無法證明最後一件已受到保護。使用者完成地址、選項或確認步驟之前，需要知道目前保留的是哪個品項、數量，以及有效到何時。
保留多久應按流程判斷。單純確認一個選項與需要檢查海外地址的時間不同；把所有流程一律設成很短，可能增加失敗與客服，設得很長則會減少其他人的機會。先用小範圍試行觀察完成時間，再由活動負責人選擇合理窗口，不把任一數字描述成通用標準。
到期後的舊連結，也需要明確結果。原持有人若晚到，不能直接取回已被下一人接受的庫存。應依核准規則重新選擇、提供替代品或進入人工處理；如果涉及款項，另外查明授權、收款或退款的實際狀態。庫存保留結束，不等於款項問題也自然結束。
對重試則要追蹤同一個動作。員工因網路中斷再按一次，不應因此取得第二件；過期事件收到兩次，也不應回補兩次。這是要交給實作與驗收負責人確認的結果，不是宣稱任何現有商城都已提供的保證。沒有重試證據的倒數功能，仍不足以讓活動放心上線。
訂單成立時占用，先查清楚草稿和正式訂單的關係
Shopify 的繁體中文庫存狀態說明區分現有、可售、已預留、無法販售與待入庫。文件把為草稿訂單預留的單位列在已預留範圍內。這不等於所有草稿一建立就自動鎖貨，實際是否已執行預留，仍要核對目前後台操作與設定。
客服流程因此應包含一個可觀察的檢查點。建立草稿後，查可售與已預留數量是否按預期變動；若未變動，就不能向員工宣稱外套已留好。若需要另外的保留操作或條件，應在客服使用的正式步驟中寫明，並確認不會與其他渠道的庫存決策脫節。
正式轉單時也要測。原本已預留的一件，轉為後續訂單承諾，應保留同一份容量的連續關係，而不是把草稿和正式單各算一件。轉單失敗、取消或部分數量調整時，也要能解釋各自留下了什麼。只看訂單畫面顯示成功，不足以證明庫存沒有重複占用。
付款不是唯一變數。免費員工兌換、公司補助與自行加購，可能有不同的接受路徑。如果同一活動同時支援這些方式，就要分別測試。不能在一般刷卡流程驗證成功後，便推論客服草稿、兌換碼和其他收款方式都一樣安全。
案例一：客服替同事開草稿，網站仍有人選最後一件
怡安先用一件可用的大尺寸外套做封閉測試，不開放預購，也不讓替代尺寸自動補上。下午一點，客服為甲員工建立草稿，但檢查發現可售仍是一、已預留仍是零。此時客服只能說草稿已建立，不能說外套已確保。乙員工若從網站取得有效接受結果，就可能成為真正的持有人。
這個結果讓怡安發現，原先的客服話術比實際庫存動作更早做了承諾。她先修正流程：需要保障時，必須完成可支援且經核對的預留步驟，並查看其結果。若系統無法在該流程提供保障，就改用不承諾特定品項的說法，或採另一條已驗證的領用路徑。
第二次測試，客服完成明確預留，可售從一變零，已預留從零變一。乙員工再要求同一件，不能得到第二個有效承諾。甲的草稿轉成正式訂單時，仍只有一件容量被占用，不是草稿一件加正式單一件。現有一件、已預留一件、可售零件，數量與權利應保持一致。
再測取消。甲在尚未出貨、且符合釋放條件時取消，系統應依實際流程解除那一份預留；確認可售回到一、已預留回到零後，才允許下一位取得。相同取消結果再送一次，不應使可售變成二。若第二次回補真的出現，怡安就保留紀錄，暫停這個品項的放量，而不是把多出的一件手動刪掉後當作通過。
最後測一個延遲轉單結果。甲取消後，乙已取得唯一外套，舊的甲轉單回覆才到達。流程必須辨認舊權利已失效，不能把乙的物品重新交給甲。客服接到的應是明確待處理個案，包含原草稿、取消與目前有效訂單，而不是一句系統延遲，讓下一位同事重新幫甲再開一次。
怡安因此選擇的不是草稿優於網站，而是所有入口都要經過同一個可驗證的容量接受點。客服可以保留人工服務的彈性，卻不能繞過最後一件的競爭規則。當轉單、取消與延遲結果都能保持唯一持有人時，這條人工輔助路徑才適合正式使用。
案例二：晚班保障配額，不能被一般商城吃掉
人資另有一批同尺寸外套，共五十二件在庫。其中四件檢查後隔離，不可拿來履約；可用四十八件。公司決定保護十八件給晚班員工，另三十件供一般商城選擇。晚班的保障期限到週五，白天同事不能因為先登入，就使用這十八件尚未被領走的數量。
到週四，晚班已接受十一筆有效領用，剩七件配額未用；一般商城已接受二十五件，剩五件可用。此時帳可以寫成四件隔離、十一件晚班已承諾、七件晚班未用、二十五件一般已承諾、五件一般可用，合計五十二件。把七件算進一般可用量，雖然總數仍可能看似正確，卻已破壞承諾。
若一般商城有人一次要六件，就不能從晚班未用的七件中補一件。可以讓對方修改數量、選擇其他已核准品項，或走活動負責人的例外審核，但不能由客服為了讓訂單成立，私下跨池挪用。例外若被核准，也應留下誰改變了哪個群組的保障，而不是假裝原規則從未改過。
週五截止後，負責人先停止新的晚班領用，再核對截止前尚未有明確結果的請求。若沒有新增有效承諾，能釋放的是七件，一般可用量從五變十二。已接受的十一件仍屬於晚班員工，不會因活動關閉而失去保障；四件隔離也不會跟著配額釋放自動變成可用。
若最後一位晚班員工在截止前已被系統接受，只是畫面回覆較晚，晚班有效承諾便是十二件，未用配額只有六件。一般可用量應從五變十一，不是十二。怡安需要查權威接受結果與事件先後，不能只看員工手機上按鈕的時間，也不能只看客服收到訊息的時間。
人資最後採事前配額，因為輪班差異比即時使用率更重要。一般加購則可以採另一套已驗證的接受規則。共用同一倉庫並不要求所有活動使用同一種保留時點；只要容量隔離、操作權限與釋放紀錄都成立，兩種承諾可以並存。
用同一套最後一件測試，才看得出模型差異
每一輪測試先回到相同起點：一件已驗證可用的特定尺寸、指定地點、沒有舊保留、兩位合格使用者。替代品、預購與其他自動補貨條件都應明確控制。否則兩個請求都成功，可能只是系統換了尺寸，並不能證明最後一件的規則正確。
先測同時競爭，再分別測未完成、取消與重試。兩個人都看過有庫存不一定有問題，兩個人都得到相互衝突的有效承諾才是問題。驗收者要指出哪一個訊息代表接受，哪一個只是收到請求，才能把畫面與真正的權利對起來。
接著測部分變更。原訂兩件改成一件，應只釋放一件；整筆取消只可處理仍可釋放的部分。若已出貨，不能把訂單狀態改成取消就直接回補可售。先確認實物與履約結果，再依真正完成的退回或其他核准處理更新，避免同一件同時在員工手上與商城裡。
再加入不同地點。台北自取與新北快遞備貨，即使品項相同，也要分別說明接受容量從哪裡扣、取消回哪裡。若取消後全台總數增加，但現場取貨點沒有恢復可用，下一位仍無法取得保障。全域總量與原地點可用量都要核對。
最後把人工客服放進同一輪。請客服建立草稿，同時讓網頁送出領用，觀察是否只有一個接受結果。只測標準網站流程，會漏掉最常被信任的人工通道。測完也應記錄需要多少人工追查，因為處理成本是選模型的一部分，不能等上線後才交給客服承擔。
失敗時保留原始結果，不用手動補數掩蓋
取消後沒有回補，先找原本的保留、取消與出貨紀錄，確認這一件是否仍有其他有效權利。不要直接把可售加一當成一般修復；如果延遲事件稍後也回補，就會多出一件。暫停受影響的品項與池，讓其餘經證明獨立的選項繼續，能兼顧安全與活動進度。
延遲付款或訂單回覆也採相同原則。把舊請求與目前有效承諾連在一起，由指定的人判斷後續處理。款項是否已收、是否已退款，要查實際結果；重送一個退款指令不是退款完成的證據。庫存與金流可以互相關聯，卻不應靠猜測互相代替。
遇到共享控制失效，就不能假裝每個尺寸都完全獨立。如果所有渠道都靠同一個接受服務，而該服務出問題，影響範圍可能比單一外套更大。保留哪一部分，應按真正依賴來決定；畫面在哪一頁報錯，不一定就是整個故障範圍。
恢復條件也要具體。原個案已核對、目前數量可解釋、重複事件不再多扣多補，而且失敗的最後一件測試在修正版本通過，才算處理完成。保留設定版本、時間、操作者與測試結果，日後更換付款方式、庫存邏輯或出貨流程時，才知道哪些驗收需要重做。
同時看等待時間、公平與客服負擔
事前配額可能讓一部分數量短暫閒置，換來指定群組的保障；短期領用保留讓人有完成空間，卻要處理到期與晚到結果；較晚的訂單承諾減少前期占用，但失敗者可能已花時間填完資料。沒有哪一個模型能消除所有代價，營運需要明確選擇要保護什麼。
比較時不要編造轉換率或假定每一位員工都能在固定分鐘內完成。可以先記錄實際試點的完成時間、未完成比例、人工介入件數與等待原因，再決定政策。若還沒有資料，就把假設寫在內部決策紀錄中，不把預估當成平台保證或對外成果。
也要測資源已用盡的邊界。可用零時，新的請求應走明確結果，不能把零當成尚未載入而繼續接受。配額為零但共同池仍有貨，是否可以轉用，也需要核准規則。負數或超額狀態一旦出現，要先確認是允許的預購設定、資料延遲還是真正異常，而不是直接把所有值重設。
沒有付款的員工商城尤其要把完成事件講清楚。若使用者按確認後即成立，後續地址修改不應意外再占一份；若需要管理者審核，員工應知道審核前有沒有保留。讓等待狀態與實際保障一致，比增加更多通知信更能減少誤解。
採購展示要看一次完整失敗，不只看順利結帳
請供應或技術團隊用準備採用的設定展示，而不是另一個沒有外掛、沒有人工訂單的示範環境。先列出商品追蹤、允許預購、付款方式、群組規則、地點與人工操作入口。這些條件只要不同，展示成功就未必能回答你的活動問題；記錄設定，是為了讓測試可以被重做。
展示開始前，先約定你要看的權威結果在哪裡。可以是受支援的後台狀態或可取得的作業紀錄，不一定要客戶看見內部程式。但至少要能確認哪一筆請求被接受、哪一筆被拒絕，並把它連回相同品項、數量與來源池。只有兩個漂亮的成功畫面，反而不能證明最後一件沒有被答應兩次。
再要求示範一位使用者放棄的情況。不要由展示人員直接把數量改回一，而應走產品真正支援的到期或取消程序，查看結果與責任歸屬。如果需要人工處理，應把該工作納入方案，而不是把人工介入當成產品自動功能。能準確說明限制的方案，比把限制留到活動當天更容易管理。
付款延遲則要測仍在等待與已確定失敗兩種狀態。尚未確定的結果不能被當成完全沒有收款，也不能為了騰出庫存就刪掉原請求。指定負責人應能查出目前狀態，以及在庫存已換人時採取哪一條核准處理。沒有辦法取得結果的交易，留下明確個案，不盲目重做。
如果保留時間靠不同畫面顯示，還要確認真正判斷到期的是哪個時鐘。員工手機可以快慢不同，通知信也可能延遲；不能因畫面還剩一分鐘，就保證權威保留仍有效。活動對外顯示應與實際接受規則一致，臨界點的請求由同一套可核對的先後與結果處理。
對多人共用的客服帳號或輪班操作，要求示範交接。第一位客服尚未看到結果就離開，下一位是否能找回同一筆請求，而不是再開一張單？事件編號、狀態與下一步如果只在個人聊天視窗裡，重複占用往往來自善意協助。這也是操作設計的一部分，不宜全部視為使用者失誤。
最後要求一份簡短的驗收結論，逐項標明通過、未通過與未驗證。缺少延遲事件證據就是未驗證，不應因正常流程成功而一併通過。記錄本次使用的品項、地點、群組、設定版本與測試日期，下次改動後才知道要重做哪一段。比較方案時，也能看出差異來自模型還是實作缺口。
活動上線前，讓客服拿到能直接回答的規則
客服需要的不是三種模型的抽象名稱，而是可以回答員工的具體句子。選擇中是否保留、保留到何時、逾期能否重選、沒有該尺寸時有哪些已核准選項，都應有一致答案。如果供應方尚未確認某一點，就先把承諾縮到可證明的範圍，不讓前線自行補上保證。
例外權限也要說清楚。主管要求替一位同事保留，是否可以跨群組挪量？如果可以，誰必須批准、原群組保障如何調整、是否需要通知活動負責人？把例外寫成獨立變更，才能知道它真的改變了哪一份容量，不會讓看似偶發的人工幫忙逐步吃掉整個保障池。
對替代品，先區分員工同意與系統自動選取。原本承諾特定外套，不能只因另一款還有貨，就默認員工接受。可以讓員工重新選擇或由活動規則明確授權替代，但通知、差價或補助條件仍要確認。替代路徑的價值是讓失敗可收尾，不是讓最後一件競爭測試看起來永遠成功。
活動結束後，分開統計完成、未領、過期、取消、人工例外與仍待調查的個案。不要只報一個領用率，讓庫存差異和金流待辦消失。這些資料能幫下一次調整保留窗口與配額，而不是憑某一則客訴把所有活動都改成同一種模式。
讓領禮承諾與商城實際能力一起決定
怡安回到客服的草稿單，先確認是否真的完成預留，再回覆員工；她也替晚班保留獨立配額，不用一般商城的登入順序決定誰有機會。三種模型可以各自適合不同活動，但都要能在最後一件、兩個請求與一個延遲結果面前，說清楚誰擁有容量。
Giftpack 的品牌商城與企業贈禮說明可協助團隊討論受眾、選項、預算與履約安排。具體配額、保留時點、人工訂單和取消行為，仍應針對專案確認並驗證。帶著你的員工承諾、尺寸需求與測試結果規劃商城，才能讓前台選擇與後台發送接得起來，而不是在缺貨發生後才重新定義原本的保障。