企業贈禮的核准紀錄，不只是把報價放進「已核准」資料夾。真正要回答的是：哪位有權限的人，在什麼時間、依哪一版政策，核准了哪一份內容？Confluence、Google Drive 與 SharePoint 都可能承接部分紀錄，但文件物件、核准設定與匯出結果並不相同。應先定義可調閱的證據，再選擇團隊能持續管理的工具。
先分清政策、決策與執行三種紀錄
同一個贈禮專案，通常同時存在公司贈禮政策、個別活動的核准決定，以及採購出貨資料。三者可以相互連結，卻不能互相代替。政策說明誰有權決定、哪些對象需要例外審查；核准紀錄說明這次實際同意了什麼；執行紀錄則證明後續採購及交付是否符合核准範圍。只有資料夾名稱，無法建立這三者的關係。
例如，財務同意總預算，並不一定表示法務已確認收禮對象符合規範；業務主管同意活動目的，也不表示採購可以自行替換材質或增加數量。檔案庫能保存決定，不能自動補足決策人的權責。涉及收禮方雇主政策、稅務、個資、反賄賂或其他法律問題時，仍由相應的內部負責人及專業顧問判斷，不應以系統顯示的核准圖示取代。
建議為每項決定建立一份精簡的「核准索引」，列出決策編號、活動編號、文件物件識別、核准版本、決定時間與時區、核准人身分及職責、適用政策版本、金額或數量上限、附帶條件、修訂連結，以及保存責任人。若另存核准快照，也記錄檔名與雜湊值。雜湊值有助於比對檔案位元組是否改變，但不能單獨證明核准人的身分或法律效力。
收件人姓名、地址與聯絡方式，應保留在另有授權的履約環境。索引可以寫明「四十人名單第二版」，連結到受限制的物件，而不是把整份名單附在所有審查者都能下載的位置。需要理解申請、核准與出貨之間的責任交接，可先參考全球企業贈禮營運指南。檔案庫要支持既有流程，不應另外長出一條無人負責的核准路徑。
人力較少時，同一人可能兼任申請與檔案整理，但仍要把角色寫清楚。由誰準備資料、誰有權核准、誰維護索引、誰負責依核准版本下單，應能一眼辨識。若因人力限制必須自我核准或例外放行，必須依公司規則留下例外依據，而不是讓軟體可編輯就默認有權決定。
用相同問題比較三種保存方式
以下比較依二〇二六年十月二十日查閱的官方文件整理，屬於適配性分析，不是實際租戶測試、價格評分或推薦排名。各公司的帳戶方案、管理員設定與政策可能不同，因此「尚未測試」應保留為未知，不能直接給零分。表格依產品名稱字母順序排列，沒有預設優勝者。
| 工具 | 需要識別的紀錄 | 必查設定 | 要刻意測出的失敗 |
| --- | --- | --- | --- |
| Confluence | 已發佈頁面版本、核准週期與附件 | 方案資格、頁面核准、空間及頁面限制 | 頁面或附件更新後，無法辨識原核准組合 |
| Google Drive | 原生文件修訂或上傳檔案版本，以及決策紀錄 | 帳戶資格、變更後重審方式、舊版保留與調閱權限 | 把上傳檔案誤當原生文件，或誤用先前核准 |
| SharePoint | 文件庫項目、指定版本與核准索引 | 版本設定、草稿可見性、內容核准及實際權限 | 審查者開到目前草稿，卻以為是放行版本 |
比較方法是把身分、版本、權限、修訂及匯出五個問題，逐一套用到候選工具。團隊已經具備的身分管理能力、同事熟悉度、第二個資料位置的維護成本，也都屬於決策輸入。如果現有系統通過要求，換工具不一定更好；如果某項必要控制無法達成，才針對具體缺口評估替代方案。
文件庫適合由採購集中維護報價及規格的情境；頁面型知識空間則可能更容易說明決策背景與例外理由。但易讀不等於可保存，資料夾整齊也不等於有權限邊界。若頁面連到會被覆寫的附件，或文件庫只有檔案沒有決策人，兩者都還不是完整證據。
核准功能要看方案與物件，不靠印象
Confluence 雲端版的頁面核准說明目前列明適用於 Premium 與 Enterprise 方案，也就是官方所稱的進階與企業方案。文件說明核准對象是頁面，而不是即時文件或網誌文章；提出與回應核准需要編輯權限，空間管理員也需要確認功能及相關設定。活動紀錄可呈現核准週期、參與人、時間與留言，因此不能再籠統宣稱它沒有核准功能，也不能推論所有帳戶預設都具備。
不過，頁面核准只是工具中的工作流程。公司仍要規定誰的確認代表預算同意、誰處理政策例外，以及該次決定究竟涵蓋頁面本身還是特定附件。若頁面文字說「附件如報價」，卻沒記錄哪個報價版本，活動紀錄再完整，也可能無法確定後來採購的東西是否經過同意。
頁面編輯與版本說明指出，更新會建立版本，還原舊內容會產生新的版本；刪除某版則是永久移除，後續版本編號也會重新排列。因此不能把「第五版」當作永遠不變的證據識別。應同時記錄頁面身分、核准決策及受控快照，並由檔案管理政策限制破壞性操作。不要為了測試功能去刪除真正的核准歷史。
權限也要分開理解。頁面限制文件區分檢視限制與編輯限制的繼承方式：父頁面的編輯限制不會自動套用到所有子頁。不能只看到上層空間有鎖頭，就推論實際決策頁、附件及子頁都符合需求。請使用預定的審查身分，實際走一次需要開啟的路徑，並記錄不該看到的內容是否確實遭到限制。
Google Drive 的版本管理說明則提醒，原生文件與上傳的圖片、報價檔等二進位檔案，不是相同的版本系統。上傳檔案的舊版可能在三十天後，或已有一百個較新版本後遭到移除；需要依官方方式設為永久保留並符合組織保存規則。不能因為原生文件能看修訂，就假設每份上傳附件也有相同保存方式。
原生文件的修訂紀錄說明要求編輯權限才能查看先前版本。若審查者本來只應讀取，不宜只為了看歷史就直接給予廣泛編輯權；可改由檔案負責人提供受控的核准快照及索引，讓審查需求與最小權限原則兼容。快照仍須連回原始決定，不能獨立漂流成另一份「最終版」。
Drive 的核准文件也說明帳戶資格及設定會影響結果。要求所有審查者核准相同內容的設定啟用時，修改會重設核准；停用時，修改後的處理不同。應由管理員核對實際方案與畫面設定，不宜照其他公司的經驗推定所有帳戶相同。鎖定也不代表永遠不可變更或自動符合組織封存規定。
SharePoint 應查閱適用於實際部署的版本，避免把舊伺服器文件套用到目前的線上文件庫。現代介面版本設定指南涵蓋主要與次要版本、草稿可見性、內容核准及版本數量限制等設定。請讓該文件庫管理員核對現況，而不是只看產品名稱。還原會形成新的版本，應當作新事件記錄，不能用來掩蓋曾經修改的事實。
假設案例一：二十五人團隊，四十位客戶的活動
以下為假設情境，不是客戶案例，也沒有宣稱已測試任何企業帳戶。一家二十五人的公司原本使用 Google Drive，準備向四十位客戶送禮。行銷負責人提出規格、數量、用途及預定出貨日；財務確認預算；政策負責人處理對象資格及例外。資料整理者為本次決定編上「贈禮四十號」，把政策、申請、報價與受限名單版本連到核准索引。
假設商品規劃額度是每人新臺幣一千二百元，四十人合計四萬八千元。這只是示範計算，不是市場行情或供應商報價。索引必須明寫運費、稅費及服務費是否包含在額度內；如果尚未取得運費估算，就把核准條件寫成「取得完整費用後由財務確認」，不能讓執行者自行猜測四萬八千元到底是商品預算還是全部支出。
整理者先判斷報價是原生文件還是上傳檔案。若是上傳的報價檔，依保存政策保留指定版本，記錄受控快照；若是原生文件，則記下修訂身分與審查者可讀取的核准物件。把檔名改成「最終已核准」不算驗收，因為同名檔案可能再被更新，也可能和核准留言指向的內容不同。
財務留下核准人、職責、時間時區、上限與條件；政策負責人另記適用規則及例外結論。整理者把兩項決定綁定到確切規格及報價版本。接著請沒有參與整理的第二位同事，只憑索引找出可下單的品項、數量、費用定義及出貨條件，而且不開啟收件地址。這一步測的是交接能力，不是原整理者能不能回想過程。
再加入一個受控變更：供應商表示原材質缺貨，提出不同表面處理。不能覆寫舊報價後沿用原核准狀態。整理者應建立修訂紀錄，連回「贈禮四十號」，列出新舊差異、費用及交期影響，請負責的核准人確認是否在原授權範圍內。未得到明確放行前，採購停在原狀，不因出貨時間接近就自行把新版當作同意。
驗收時，第二位同事必須找得到原決定及修訂，辨識目前允許執行的版本，並證明自己的權限沒有包含地址名單。若只能找到最新檔案，或必須取得整個活動資料夾的編輯權才能理解決策，先修補索引與存取安排，再重測失敗項目。測試表記下實際證據、責任人及日期，而不是由申請者直接勾選「應該沒問題」。
通過後，這家小公司可能繼續用原有工具就足夠。若實際方案無法證明必要的版本保存或權限分離，才把缺口交給管理員評估。將同一份缺漏資料搬到新的頁面工具，不會自動補上核准身分；為了看起來制度完整而增加維護位置，反而可能讓下次調閱更困難。
假設案例二：一千二百人組織的跨部門調閱
第二個假設情境是一千二百人的公司：採購以 SharePoint 管理受控檔案，業務團隊在 Confluence 記錄作業程序。這不是已安裝整合功能的實例。先由檔案負責人指定單一權威決策位置，再決定另一邊如何提供導引。一種做法是由受限文件庫保管索引與核准附件，程序頁只連到該處；另一種是受控決策頁連到文件庫中的指定版本。兩邊不能各自宣稱自己是唯一正式版。
採購提供報價與規格，業務核准活動目的，財務核准支出；另有一位審查者只需要確認兩項決策是否完整。資訊管理員建立不含真實個資的拋棄式測試資料，分配兩位核准人及一位審查者，另準備一個不應取得資料的測試身分。所有權限變更都在已授權範圍內進行，不能拿正式專案的歷史紀錄做刪除實驗。
先提交一版申請，完成兩項核准，匯出預定交付的證據包，再由審查者調閱。接著由管理員撤銷其中一位測試核准人的存取權，建立修訂，並依允許範圍測試還原。記錄每一步的操作者、時間、測試物件及結果。測試重點是權限變更後，原決策仍可追溯到當時的身分與授權，而不是要求離職或轉職人員永久保有登入權。
若匯出檔只剩頁面文字、沒有核准人及時間，就補上受控的決策索引或調整匯出流程；若索引連到可變動的「最新報價」，就改成明確的放行版本；若被拒絕的測試身分仍能開附件，即使頁面本身已受限，也不能視為通過。每個失敗都要有責任人、修正方式與重測證據，不能以其他項目平均分數掩蓋必要控制失敗。
審查者還要確認，修訂後的產品、數量或預算，沒有默默繼承原商業核准。內容核准旗標可能只表示文件符合發布流程，不等於該次贈禮符合公司的支出及對象規範。公司需定義何種變更一定重審、誰可判定純文字修正不影響決策，並把判定理由記錄下來。綠色狀態不應掩蓋未記錄的裁量。
最後由檔案負責人與法務、個資及業務責任人確認保存、刪除與例外處理。審查資料應足以證明決策，不需要因此匯出完整收件人資料庫。關於同意、區域存取與保存期限的分工，可參考企業贈禮資料治理指南。工具比較能支持討論，不能代替這些組織決定。
用工作簿執行試行，而不是填出預設冠軍
下載繁體中文核准紀錄保存評估工作簿。這是二〇二六年十月十八日第三版，官方資料查核日為十月二十日；三個工作表分別是使用說明與評估準則、調閱試行、來源與版本紀錄。檔案為繁體中文，不是預先填好的產品排名，也不是法律合規認證。
先選一個活動與目前使用的保存方式。在評估準則表，為必要控制指定負責人，寫清楚為什麼不可妥協。在調閱試行表，對實際考慮的工具執行六項測試：允許讀取、拒絕讀取、核准版本、修訂、受控刪除與還原、匯出完整性。沒有實測的候選工具留白，不要為了填滿三組欄位而推測結果，也不要把產品文件當成自家環境的測試證明。
結果欄使用數字零或一。空白表示尚未測試，零表示失敗；要記錄成功，還需要證據位置、負責人及有效的試算表日期。日期只填整天，不含時間；負責人仍須確認測試確實發生，以及所填日期正確。文字、超出範圍的數字及缺漏證據會產生不同提示。「已記錄」只表示這筆觀察資料完整，不等於核准業務決策，更不是工具推薦。檔案負責人仍要判斷該結果是否滿足原定要求。
為什麼匯出快照不能直接當作完整歷史？
匯出檔可能保存頁面當時的外觀，卻沒有包含核准週期、留言、附件版本或權限紀錄。原生文件修訂、上傳檔案版本與匯出快照是不同物件，索引應分別列明需要保存哪些內容。Confluence 匯出文件說明可用格式，但沒有保證每種格式都能成為完整核准封存。請用預定的審查身分開啟實際匯出包，依組織政策保留必要的原始參照。
可依以下順序完成一次可重做的試行：
-
政策負責人先定義本次決定、授權層級及必要證據，再開始整理檔案。
-
檔案負責人識別測試物件，保存現行版本與設定的查核依據。
-
管理員只授予預定的測試權限，確認測試範圍與無真實個資的資料。
-
核准人完成假設決定，再由第二位操作者找出可執行的證據組合。
-
審查者檢查允許與拒絕存取、修訂、還原及匯出的實際結果。
-
所有必要失敗項目都有負責人與重測結果後，業務負責人才接受流程設計。
試行的資料量要刻意縮小。先用一份虛構報價、一份規格、一份核准與一項修訂，就足以觀察主要問題；不用把整年度的活動資料搬進來。管理員變更權限前，先記錄測試參與者與影響範圍，確認不會改到正式共用群組。測試結束後移除臨時權限，依核定範圍保存結果，避免測試本身反而增加未受管理的個資或長期存取。
失敗原因要能讓接手者理解。例如，「開得了檔案」並不表示調閱成功：審查者可能看到規格，卻找不到核准時間；匯出包可能有時間，卻沒有決策人；索引可能寫了人名，卻無法知道當時是否具有授權。這些是不同缺口，不能全部寫成系統問題。將缺口拆成缺少的證據、受影響的決策、負責補正的人及預定重測條件，才有辦法判斷修正是否真的完成。
修正策略也不應只有「再試一次」。若問題是權限太寬，應先重新劃分讀取對象；若問題是舊版可能消失，先確認保存設定與受控快照方式；若問題是匯出遺失核准身分，就調整證據包內容。修正後用相同角色、相同物件類型與相同驗收條件重測，不能換一個比較容易通過的情境，卻把原失敗悄悄關閉。
對外供應商的便利與內部審查的需求也要分開。供應商可能需要設計稿、交貨規格及確認的數量，卻不需要看到公司內部例外理由或完整客戶名單；財務可能需要費用與核准條件，也不一定需要每位收件人的地址。先依用途決定可以共享的最小證據，再產生對應的交付包。用一條所有人都能開的連結，雖然能讓測試迅速完成，卻失去原本要驗證權限的意義。
交接時，原整理者應提供核准索引、放行版本、未解問題與責任人，讓接手者實際示範一次調閱，而不只是回覆已收到連結。若原整理者離開座位後，下一位同事就無法判斷哪個版本能執行，流程仍應維持試行狀態。這是日常營運的可交接門檻，不是保證任何稽核或法律要求都能用同一份資料滿足。
若發現資料被誤刪、版本指向失效或權限意外變更，先暫停受影響的下單與出貨，通知既定的檔案及業務責任人，再依核准的復原程序處理。不要為了補洞而倒填核准時間，也不要把事後補做的決定寫成當時已存在。復原後保留事件、補正與重新授權的順序，讓接手者能分辨原始決策與後續修復。
保存期限也不宜只填一個通用數字。檔案負責人應記錄期限由哪一份組織政策決定、適用哪些物件，以及誰有權處理保留例外或暫停刪除。若尚未取得政策答案，就將此項列為待決，不得從工具可保留多少版本反推公司應保留多久。技術容量、商業需求與法律義務是不同問題，分開記錄才能避免錯把功能當成規範。
最後，評估結論宜採條件式敘述，例如「在目前帳戶、指定文件庫與已測試角色下，可以完成本次調閱」，並附上尚未測試的範圍。不要把單一活動的成功延伸成全公司、所有附件格式及所有地區都已通過。保留範圍限制不會削弱結論，反而能讓下一次擴大使用時，清楚知道還有哪些項目需要補測。
工作表中的來源與版本紀錄，應隨方案、管理設定、供應合約或公司政策變更而更新。下一次文件查核預定在二〇二七年一月十八日，若發生相關變更就提前。這是本範本的維護方法，不是保證產品功能不會改變。舊試行結果也要保留，避免後來改進後，反而失去當初為何否決某個設計的脈絡。
選擇能交接的最小系統
評估會議可以分成兩個問題來作決定：第一，這個工具在目前設定下能否完成必要控制；第二，團隊是否有能力長期維護它。前者需要測試證據，後者需要指定人力與交接安排。功能足夠但無人維護的系統，可能在下次人員異動後失去可信度；大家熟悉但無法保存指定版本的環境，也不能因為方便就直接放行。把這兩種風險分開，才不會用熟悉度取代必要控制，或用功能列表掩蓋維運負擔。
會議紀錄應寫明選擇理由、未採用方案的具體原因、尚未解決的問題，以及誰能接受剩餘風險。例如某候選工具並非整體不合適，而是本次帳戶沒有需要的核准設定；這是範圍明確的限制，不該寫成產品永遠沒有該能力。同樣地，選擇保留現有工具，也不表示後續增加地區、數量或新審查角色時可以免測。每次擴大用途，都應對新增範圍提出相應證據。
首次上線後可安排一次短期回顧，由下一個實際專案的接手者指出哪個欄位不易理解、哪條連結會失效，以及哪項證據取得成本過高。若要簡化索引，先確認刪掉欄位後仍能回答身分、版本、時間與條件四個核心問題。簡化應減少重複輸入，不應刪掉決策所需的脈絡，也不應讓後來的人只能靠詢問原承辦人才能理解紀錄。
最合適的保存方式，是能在實際環境中保留可歸屬的決定、可辨識的核准版本，以及範圍適當的調閱權限。現有系統通過測試且責任清楚，就不必為了功能列表搬家；確有缺口時，再把移轉、連結維護及歷史保存成本一起納入評估。介面上的核准圖示，永遠不能取代可重現的證據路徑。
小團隊優先做好放行索引與第二人調閱，大型組織優先建立單一權威位置與跨部門權限驗證。兩者共同的停損點都是：當執行版本或決策人不明，就暫停下單與出貨，先把紀錄補清楚。時程緊迫可以成為升級處理的理由，不是沿用模糊核准的理由。
在正式授權清楚之後，Giftpack可依約定範圍協調選品、生產與履約，團隊再把適當的執行證據回存到既定檔案庫。這是相鄰的營運協作角色，不是文件治理系統的替代品，也不代替雇主贈禮政策、法律、稅務、個資或內部核准責任。