寄出企業贈禮邀請，只代表收件人取得選擇資格，不代表倉庫已經替他留下一件商品。當限量商品同時供多個活動使用，或部分現貨正待品管確認時，這個差異會直接決定承諾是否可信。可執行的預留制度必須回答：數量何時離開可售池、哪一筆紀錄擁有保留量、何時到期，以及如何只釋回原本那一筆預留而不誤動其他活動的庫存。
先把邀請承諾與實體預留分開
先問三個問題：收件人只是收到邀請，還是已選定品項？營運端是否已接受一筆可履行的訂單？這三個事件可能相隔幾秒，也可能相隔數日。若全都叫做「已預留」，團隊就看不出庫存風險從哪一步開始。
邀請資格描述收件人可以提出什麼選擇，通常包含適用對象、回覆期限、可選組合、地區限制與替代方案。它不是商品已在倉庫，也不是商品已禁止分配給別人的證明。實體預留則會針對特定地點與品項，從可分配數量中扣除一個明確數字。訂單一旦被接受，執行義務更強，也不能只因邀請期限結束就被自動刪除。
本文以 Shopify 官方庫存狀態說明 作為範圍明確的例子，不把其欄位視為所有系統的共同規格，也不代表 Giftpack 的實作。該說明將現有庫存分成可售、已預留與無法販售等狀態；已預留可能包括未出貨訂單或草稿訂單所保留的單位，無法販售則可能包括損壞、品管、安全庫存或應用程式保留的單位。待入庫商品尚未收貨前，不應被當成可售數量。
企業贈禮作業即使使用不同系統，也應採用同樣清楚的定義。「現有」是地點中記錄的實體總量；「可分配」是仍可承諾的已驗證數量；「預留」是暫時指派給穩定活動鍵或收件人選擇鍵的數量；「已訂購」是已進入履行流程的接受請求；「不可用」是實體存在，但因損壞、品管、隔離、安全庫存或其他限制而不能分配的數量。
不要用「有貨」取代所有狀態。倉庫可能有一百件現貨，但二十件已有訂單、十件正在隔離，因此真正可承諾的只有七十件。同樣地，寄出一百封邀請不等於保留一百件。專案負責人定義對收件人的承諾；倉儲負責人確認可分配量；採購負責補貨與供應商承諾；履行營運負責允許的訂單執行；財務、法務、隱私與稅務決定仍由相應專業負責人掌握。
這些狀態名稱不是會計或法律結論。預留本身不決定所有權、付款、稅務或收入認列。本文要解決的範圍更窄：守住數量、不做互相衝突的承諾，並留下另一位營運人員可以重現的證據。
還要把「可見」與「可分配」分開。商品出現在收件人畫面，只證明目錄規則允許展示；它可能仍受地區、活動、包裝能力、個人化截止或實體品管限制。畫面層應讀取可承諾結果，而不是自行從現有總量推算。若資料截止已過期，安全作法是暫停承諾或顯示需要確認，不是沿用昨天的數字。
為每個狀態寫出開始與結束條件。可分配只有在入庫驗收、地點啟用與限制檢查完成後成立；預留只有在條件式扣數成功並留下識別後成立；訂單只有在履行流程接受後成立；釋回只有在原預留仍處於允許狀態，而且剩餘量足夠時成立。這些條件讓交接人員不必從介面顏色猜測商業意義。
建立能承受重試的預留紀錄
每筆預留都需要獨立於按鈕或電子郵件的識別。實務上可由活動、收件人選擇或共享池、品項、地點與唯一預留識別組成。至少記錄請求量、接受量、建立時間、含時區的到期時間、目前狀態、責任人、理由、來源事件與前一狀態。若允許替代品，應另列核准的替代集合，不要默默改掉原始品項。
同一商業事件可能到達兩次。瀏覽器會重試，串接流程會在逾時後重播，操作人員也可能在第一次請求仍處理時重新整理。使用可重入鍵，讓重複請求回到原結果。「重試」應代表查詢或安全完成同一操作，不是再扣一次數量。若第一次結果未知，先對回原請求與庫存帳，再考慮任何新異動。
指定單一權威負責把可分配量轉為預留。其他系統可以提出請求，但不應各自在同一池中扣數。若公司商店、活動表單、客服工具與人工表格都能各自保留庫存，卻沒有共同權威，帳面終究會承諾超過倉庫能履行的數量。
| 狀態 | 營運意義 | 必要證據 | 允許的下一步 |
| --- | --- | --- | --- |
| 可分配 | 已驗證庫存仍可承諾 | 地點、品項、盤點截止、限制 | 建立一筆帶鍵預留或移入隔離 |
| 已預留 | 數量暫時為明確目的保留 | 預留鍵、數量、責任人、建立與到期時間 | 轉成訂單、依規則延長或釋回 |
| 已訂購 | 接受的請求已進入履行 | 訂單鍵、接受品項、時間、原預留 | 揀貨、包裝或依授權取消 |
| 不可用 | 實體存在但不能分配 | 隔離原因、數量、審查人 | 檢驗後恢復、修復或依規則處置 |
| 已釋回 | 特定預留結束且未耗用全部數量 | 原預留鍵、釋回量、理由、時間 | 重算後只公開已驗證可分配量 |
守恆檢查很簡單，也很有力量。對明確品項與地點，現有數量應等於可分配、已預留或已承諾、不可用，以及其他互斥實體狀態的總和。待入庫商品直到收貨驗收完成前都不能加入。若「已訂購」本來就是承諾狀態的子集合，就不能同時在預留與訂單中重複扣除。團隊必須把實際採用的等式寫清楚。
狀態轉換應盡量保持單向。預留可以轉成訂單，或成為已釋回預留；不應靠改識別碼變成另一筆無關預留。取消訂單只有在取消已生效、實體狀態已確認，而且個人化或損壞條件允許時，才可能回到可分配。已出貨商品不會因邀請紀錄到期就自動回庫。
紀錄也應保留數量變動前後值。若預留兩件，寫出可分配量由十二變十、預留量由零變二，以及觸發事件與操作人。後續釋回一件時，引用同一預留並留下剩餘一件，不要只把總量改成十一。前後值、穩定識別與時間組合起來，才能在逾時或重播後分辨「尚未處理」與「已完成但回應遺失」。
權限採最小必要原則。活動人員可以查看自己的池與例外，不代表可以改倉庫基準量；倉儲可以確認實體狀態，不代表可以改收件人資格；客服可以提出取消，不代表能直接釋回已個人化商品。緊急管理權也應具名、限時並留下理由。若單一帳號可以建立、延長、轉單、取消與刪除證據，試行時就要把這項集中風險列為缺口。
在寄出邀請前先選定保留政策
常見設計有三種，沒有一種永遠正確。為每封邀請保留一件，承諾最強，卻可能在收件人考慮期間鎖住大量庫存。等到收件人選定才預留，可以提高利用率，但較晚回覆的人可能拿不到原選項。建立有上限的活動共享池，則讓活動先占用一段數量，再由收件人在核准品項與期限內競逐。
選擇時應列出明確輸入：收件人數、已驗證可分配量、回覆期間、過往選擇型態、補貨前置時間、承諾落空的影響、個人化發生點、地區品項限制，以及遲到收件人能否接受替代品。資料不足時，不要把樂觀回覆率藏進假設；應先做保守試行並寫好備援。
逐邀請預留適合承諾必須確定、而且庫存足夠的情境。預留仍須對應實際品項或受控共享池，不能只寫「一份禮物」。十選一活動若沒有分池與替代邏輯，就不能隨意保留一件不確定商品。若收件人可以改選，規則要說明新商品先保留後釋出舊商品，還是改選失敗時完全不產生第二筆保留。
選定時預留適合在介面上清楚說明「完成選擇後才確認庫存」的活動。邀請不應暗示特定商品已保證。營運端必須準備遲到處理：提供核准替代品、說明可驗證的延後日期，或清楚道歉與升級。事前說明限制，通常比失敗後假裝有貨更能維持信任。
活動共享池適合先從通用庫存切出數量、但不急著逐人分配的情境。必須定義池內品項與地點邊界、替代品是否共用上限，以及未使用數量如何回庫。共享池不是維護兩套互相競爭表格的理由；活動池與一般池仍應由同一預留權威管理。
上線前，專案負責人核准承諾文字與備援；倉儲營運確認盤點截止量；採購確認補貨是可行選項，而不是願望；紀錄負責人保存狀態定義、測試證據與責任人。完成這些工作後才適合排程邀請。
同一政策也要處理部分成功。收件人一次選兩項商品時，應事先決定需要全數保留才算成功，還是允許一項成功、一項提供替代。前者適合不可拆分的禮盒，後者適合獨立品項。回應必須逐項顯示接受、拒絕與原因，不能用單一「成功」遮住其中一項未保留。履行端收到的訂單應與這個結果完全一致。
若活動跨多個倉庫，不要把總量相加後才決定出貨。先確認各地點的品項、運送範圍、截止與限制，再決定預留是否綁定地點。允許換倉時，將它做成可追溯轉移：新地點先成功保留，再釋出舊地點，或在無法同時保證時明確失敗。直接改掉地點欄位會掩蓋兩邊曾經同時承諾的風險。
把到期做成可稽核轉換，而不是清除計時器
到期時間表示暫時權利進入檢查或釋回條件，不應是看不見的背景刪除。保存用來計算到期的時區與規則版本。若活動依收件人所在地午夜截止，就要定義多時區、日光節約時間與時鐘誤差如何處理；若全體共用單一活動截止，則直接說明。
到期也需要緩衝規則。收件人可能已完成選擇，但下游回應延遲。若系統在同一瞬間直接釋回，就可能造成超賣。較安全的流程是先停止新選擇，等待已記錄的事件處理區間，對回處理中的請求，再只釋回仍符合條件的預留。該區間必須依實際系統決定，不能假造一個普遍秒數。
釋回操作必須引用原預留鍵與剩餘量。五件預留若已有三件轉為訂單，到期最多只能釋回兩件。取消訂單若商品已個人化且不可再用，也不能回到可分配。若實體商品正進入隔離，解除預留後應轉到不可用，而不是可分配。
每次釋回要有明確原因，例如到期未選、收件人拒絕、活動取消、修復重複預留、訂單取消且商品可再用，或管理員更正。管理員更正應留下工單或等效證據；數量或活動風險較高時，應由第二人覆核。「系統清理」不足以解釋會改變可承諾量的異動。
定期執行程序只能執行同一套已記錄規則。它應挑出符合條件的預留，針對預期前一狀態做條件式轉換，再寫回結果。若另一程序已將預留轉為訂單，釋回應成為無異動，而不是扣掉訂單。重跑同一批到期工作不能讓可分配量增加兩次。
例外面板：隔離品或個人化商品預留結束時仍需確認商品是否可再分配。破損、缺標、待品管、召回或已個人化商品，必須維持不可用，直到授權負責人處理。紀錄品項、地點、數量、原因、檢查人、決定時間與允許的處置。活動期限不能凌駕安全、品質、合約或隱私限制。若系統無法表達這個差異，寧可維持不可用並升級，也不要樂觀回庫。
假設案例一：八十封邀請與六十個馬克杯
假設一場活動有八十名符合資格的收件人、六十個已驗證可分配的馬克杯，以及營運端選定的七天回覆期。這是營運演練，不是客戶案例。專案負責人擁有承諾文字；倉儲營運擁有可分配量截止；採購負責任何補貨決定。除非活動刻意做出保證，收件人不會只因符合資格就自動獲得馬克杯。
方案一是替所有邀請保留。它立刻失敗，因為六十件無法支撐八十筆確定預留。團隊可以把邀請限制為六十人、上線前取得更多已驗收庫存，或改寫承諾；不能先做八十筆保留，再期待至少二十人不回覆。
方案二是在收件人完成選擇時預留。八十人都可收到邀請，但體驗要說明商品在選定時才確認。預留權威只在可分配量仍大於零時，條件式建立一筆預留。六十個馬克杯全數預留或下單後，較晚收件人看到核准替代品或清楚的無貨訊息。此設計利用率較高，但必須有誠實備援，也必須測試同時請求。
方案三建立有上限的品項組合。例如活動先保留四十五個馬克杯，另以獨立上限提供另一種核准商品，並留下十五個馬克杯給其他已授權專案。活動紀錄要清楚寫出選擇受共享池限制，池耗盡時即關閉。這能保護共用庫存，但活動池與一般庫存必須能對回同一實體數字。
測試時使用穩定活動鍵與收件人選擇鍵。讓兩筆請求同時爭最後一個馬克杯，只有一筆可以從可分配轉成預留，另一筆要收到既定替代結果。重播勝出請求，確認不再移動第二件。讓未接受的預留到期，確認只釋回該筆。另有一筆預留在到期前轉成訂單，確認執行程序不會動到它。
再加入延遲的倉庫更正：一個已預留馬克杯被發現破損。營運將該單位從預留移到不可用，並標明受影響活動。專案負責人採用核准替代品或說明延後，不讓帳面憑空產生替代件。驗收條件是六十件在所有狀態間守恆、每次轉換可追溯，而且較晚回覆的人不會收到無法兌現的保證。
假設案例二：兩個活動與五件隔離品
假設兩個活動同時要求同一批三十件商品，另有五件同品項正隔離。此處「同一批三十件」指三十件已驗證可分配量；五件隔離品雖實體存在，卻不屬於這個池。本案例專門揭露權責與併發錯誤。
先定義單一預留權威，以及活動、品項、地點與明細的唯一鍵。活動甲與活動乙可能幾乎同時送出。若採先確認先分配，系統依權威接受順序，對共用可分配餘額做條件式分配。若採核准優先分拆，專案負責人需在競爭發生前依書面規則預先切分。串接流程不能在衝突發生後自行發明優先順序。
讓兩個活動各要求二十件。正確帳本可以接受一方二十件、另一方最多十件，或依預先核准分拆；不可能接受四十件。未完整取得數量的一方應收到結構化結果，而不是只看到逾時並盲目重送。專案負責人可選替代品、縮小範圍或升級採購。
以相同可重入鍵重播活動甲的已接受事件。回應應指向原本二十件預留，數量不變。再用不同鍵但相同商業參照重播，檢查重複偵測規則。若系統無法自動判斷，就把衝突留待對帳，不要預留兩次。
接著取消活動甲的五件。釋回前確認個人化、包裝或出貨是否開始。若仍可再用，針對原預留釋回並公開五件可分配量；若已個人化，則移到記錄好的不可用或活動專屬處置。再執行一次相同釋回，第二次應無異動或回報明確衝突，絕不能多生五件。
最後由品質負責人完成檢查，將一件隔離品從不可用恢復為可分配。這個動作與活動到期彼此獨立。驗收要求是：同時請求不會讓可分配量為負；重複事件不會重複移動數量；取消明細保留實體可用性判斷；任何活動都無法釋回另一活動的庫存。
在宣告成功前，先對回帳本與倉庫
預留服務可能內部完全一致，但貨架數量仍然錯誤。建立固定對帳流程，在明確截止時間比較預留帳、接受訂單、不可用異動與實體盤點。目的不是立刻把所有差異改成零，而是分類差異、停止危險承諾並指派復原。
若接收、儲存、循環盤點與揀貨控制仍未定義，可先閱讀 企業贈禮倉儲完整指南。預留準確依賴這些基礎。再精確的到期程序，也修不好未記錄的破損箱或尚未驗收的到貨量。
例外佇列至少應涵蓋：可分配量為負、沒有責任人的預留、到期後仍啟用的預留、釋回量大於剩餘量、應有預留卻直接出現的訂單、品項或地點不一致、相同可重入鍵帶入不同內容，以及超出容許範圍的實體差異。每件例外要有負責人、首次發現時間、影響數量、隔離措施、證據與解決結果。
先控制風險，再修飾數字。當數量不確定時，暫停受影響品項或活動。不要直接把可分配數字改到「看起來正確」。追到最後一個可信截止點，在受控環境重演證據，再以引用原錯誤的更正異動保留歷史。直接覆寫會讓下一次調查更困難。
資料來源健康與商業核准也要分開。串接可能正確送出每件事件，但活動政策本身錯誤；活動也可能已核准，卻因未知操作結果而無法安全執行。因此營運驗收要同時包含政策證據、狀態守恆、負面路徑測試與實體或倉儲系統對帳。
每日控制可以列出各互斥狀態數量、即將到期的預留、釋回錯誤、未知結果與對帳例外。不需要發明「庫存信心分數」。呈現實際數量、截止時間與未解案件；趨勢可協助發現累積，但每一筆例外才是需要完成的工作。
設定可操作的截止，而不是只做月底報表。高風險活動在寄出前、主要截止前與大量釋回後都應對帳；日常共享庫存則依異動量與容錯能力安排。每份報告要標明資料來源、抽取時間、涵蓋地點與尚未完成的事件。兩份數字若截止不同，不應直接判定其中一份錯誤，而要先對齊時間邊界。
復原後也要證明問題不會重現。把造成差異的事件變成測試案例，例如逾時後重播、取消與到期同時發生、隔離品被錯誤釋回，或一個地點的調整套到另一地點。只有原缺陷已修復、歷史已保留、帳本與實體重新對齊，而且相同輸入不再產生錯誤，才可關閉例外。
交接紀錄要讓下一班人看得懂目前風險：最後成功步驟、未完成操作、受影響數量、禁止重做的事項，以及下一個可安全執行的動作。沒有這些內容，夜間逾時很容易在隔天變成第二次扣數。
使用營運人員真的能執行的驗收清單
上線前完成以下檢查：
-
在實際系統中定義邀請、可分配、已預留、已訂購、不可用、已釋回與待入庫。
-
指定專案、預留權威、倉儲、採購、紀錄與升級責任人。
-
保存預留鍵、品項、地點、數量、建立與到期時間、時區、責任人、理由與來源事件。
-
在逐邀請、選定時或活動共享池中選一種政策，並寫出它如何符合承諾。
-
定義替代、遲到、補貨、個人化、取消與隔離處理。
-
測試最後一件同時請求、事件重播、未知結果、到期前轉單、部分轉單、重複釋回與跨活動隔離。
-
在明確截止點，把帳本對回接受訂單、不可用異動與實體或倉儲系統數量。
-
確認對外邀請文字與營運端實際能支撐的庫存承諾一致。
只有在每次數量異動都遵守既定等式、每個重要轉換都有穩定參照，而且另一位營運人員可以重現結果時才驗收。介面顯示成功，不代表庫存承諾已安全。
若測試失敗，先隔離受影響品項，保留原事件與操作識別，對回結果，以引用原問題的更正異動修復帳本，再重跑失敗情境。不要清除嘗試歷史，也不要只為讓狀態變綠而換新識別。外部依賴若回傳未知結果，就停止可能重疊的異動，直到原操作被查清。
需要把庫存控制放回完整流程時，可參考 全球企業贈禮營運中樞，將庫存、資格、核准、寄送與證據的責任邊界對齊。
建立庫存帳真正守得住的承諾
核心原則很簡單：選定政策與共用帳本都確認商品可分配之前，不要承諾該件商品。邀請、預留、訂單、隔離與釋回是不同事件，也有不同責任人。到期不是刪除，而是針對特定預留做條件式異動。取消不等於可用，還要檢查實體資格。重試不是第二筆請求，而是查清第一筆操作。
最好的制度不是扣數最快，而是在爭最後一件、事件延遲與實體盤點不完美時，承諾文字、倉庫數量、併發控制與復原證據仍然一致。先以單一活動、單一地點與小型品項組合試行；在擴大前，先證明失敗路徑可被安全處理。
當庫存邊界與營運模式都經驗證後，可把 Giftpack 納入商品、品牌商店或獎勵方案的執行選項之一。請在方案設計階段確認專案需要的庫存、預留、到期、替代與串接行為；本文不宣稱 Giftpack 實作任何特定預留機制，也不取代企業的倉儲、合約、會計、法務、隱私或稅務負責人。