如果同事已經在聊天工具裡討論送禮，申請入口通常不必另外換一套平台。真正要比較的是：Slack、Microsoft Teams 與 Google Chat，哪一種路線能讓公司確認申請人、保留核准版本、攔下重複指令，並在下單結果不明時找到原始紀錄。收到訊息不等於核准，按下同意也不代表禮物已經寄出。
先決定誰能核准，再決定在哪裡填表
對臺灣企業的人資、資訊與採購團隊而言，選擇協作工具常從使用習慣出發：同事在哪裡找得到主管，哪個群組回覆最快，既有帳號是否容易管理。這些都是實際條件，但不能代替送禮制度。主管在群組說「可以」，可能只是同意活動構想，未必同意某位外部收禮人、預算幣別與寄送國家。
先把一份申請的範圍寫清楚。它是員工周年紀念、客戶感謝，還是合作夥伴活動？誰負責認定資格，誰負責支出，誰能處理例外？同一位主管可以兼任幾個角色，但每個角色都要有明確責任與備援人。不能讓程式用「出現在這個頻道」推定有核准權。
本文比較的是從對話進入正式申請的架構，不是一般聊天軟體排名，也沒有實測某家公司租用環境。最後文件查核日期為二○二六年十月十八日。平台順序依題目所列方案，不依贊助、使用率或虛構分數；實際方案、權限、保存範圍與費用仍須由買方確認。
把條件分成必要門檻與便利偏好。必要門檻包括來源驗證、核准人權限、申請版本與可追查的下單結果；便利偏好才是介面是否熟悉、填寫步驟多少。缺少必要證據時應記為未確認，不能用其他方便功能加分抵銷。更大的制度分工可搭配全球企業送禮營運指南閱讀。
用相同問題比較三條路線
比較單位應是準備部署的實作方式，不是整個品牌所有功能的集合。不能把機器人的身分能力、另一個流程的核准介面與不同產品的保存功能拼起來，宣稱那是一套已可直接使用的送禮系統。先指定路線與負責人，再要求相同的驗收證據。
比較表：從申請入口到證據留存的選型問題，第一版，二○二六年十月十八日。
| 入口 | 可研究的起點 | 主要取捨 | 買方應取得的證據 |
|---|---|---|---|
| Slack | 用互動視窗收集固定欄位 | 視窗之外仍需維護授權與狀態 | 來源簽章、重複測試與紀錄匯出 |
| Microsoft Teams | 結合既有身分與核准流程 | 卡片、機器人與流程的前提不同 | 選用路線、管理同意、核准歷程與備援 |
| Google Chat | 以互動對話框收集資料 | 接收互動與後續呼叫授權須分開 | 端點驗證、權限方式與持久申請紀錄 |
Slack 適合已有使用習慣，也有應用程式維護人的團隊先試行。互動視窗能把自由文字轉為固定欄位，但人員資格、預算核准、重複攔截與異常補救仍是另外的工作。若資訊團隊無法接手維護，先採受控網頁表單，可能比一個漂亮但無人負責的視窗更實用。
Microsoft Teams 值得優先試行的原因，是公司已經有可維運的身分與核准環境，而不是「公司買過辦公軟體」。Power Automate 的核准說明列出相關前提。買方須確認實際授權、正式環境、流程擁有人與離職後的接管方式，不能把示範者個人環境的成功當作公司環境驗收。
Google Chat 可作為既有協作環境中的申請介面。官方文件所述對話框只顯示給開啟者，適合收集表單資料；這不等於資料天然不會進入後端紀錄。買方仍要確認應用程式取得哪些內容、後續服務由誰授權、資料存在哪裡，以及誰能看見匯出的證據。
Giftpack 在這個比較中的位置
Giftpack是核准後可評估的送禮、商品與履約執行端，不是聊天平台，因此不應被硬放進訊息工具評分。先確認實際交付範圍、資料條件、下單與狀態查詢方式，再決定如何銜接。本文沒有證明三個平台與 Giftpack 之間存在原生串接，也不把人工受控交接視為比較失敗。
把來源、本人與業務權限拆開
一個請求至少有三種身分問題：哪個服務送來、哪個人操作、那個人能決定什麼。Slack 的請求驗證文件說明簽章驗證；技術來源確認後，公司仍須把使用者對應到組織職責。聊天顯示名稱、頭像與轉傳截圖都不能單獨充當核准人識別。
採用 Teams 機器人時，Microsoft Entra ID 單一登入說明有其適用範圍與同意程序。先列出提交、查閱、核准與匯出需要的最小權限，不要為了省事索取所有資料。能登入公司帳號，和能批准外部對象禮物，是不同層次的授權。
Google Chat 的端點驗證說明處理接收請求的可信來源；驗證與授權文件另區分使用者及應用程式執行身分。應用程式能發出確認訊息，並不代表它取得申請人的支出決定權。每條路線都需要公司自己的角色對照。
特別測試訪客、跨法人支援人員與調職主管。訪客能參與討論，不表示可以讀取地址或核准費用；主管離開原部門後，舊卡片也不應保留原核准資格。權限應在作出決定時重新核對，而不是只在最初安裝程式時檢查一次。無法確定的人員先進例外處理，不猜測其職級。
還要把申請人、預算負責人、履約人與稽核讀者分成不同測試帳號。用管理員身分一路測通，會掩蓋正式使用者權限不足，也可能掩蓋權限過大。驗收紀錄應同時包含允許與拒絕案例，以及拒絕後該由誰補正，才有辦法判斷設計是否可運作。
先保存一份可辨識版本的正式申請
聊天訊息可以是入口，不適合當唯一的業務紀錄。正式申請至少要有申請編號、版本、組織、申請人、用途、收禮人參照、目的國、預算、幣別、適用制度版本與核准負責人。地址及其他敏感資料宜放在受控位置，以參照連結交接，不應為了方便而貼進共同頻道。
欄位設計要能指出缺少什麼。缺幣別時不要默認新臺幣，缺目的國時不要沿用申請人的所在地，缺收禮人類別時也不要自動歸為員工。系統應回傳可修正的問題；制度負責人決定哪些欄位是送出前必填，哪些可以在交付前補足。表單完整與業務合格仍是兩件事。
核准應綁定被審查的版本。有人把預算、國家或收禮人改掉，原來的同意不能默默套到新內容。保留舊版、建立新版，並依受影響的條件重新審查。純粹修正錯字與變更收禮對象的處理可以不同，但差異要由制度決定，不能讓程式自行推斷哪些變更不重要。
來源配信編號與業務申請編號也要分開。前者處理服務重送，後者處理同一筆需求透過不同入口提交。兩位同名收禮人未必相同；同一位收禮人在兩個合格場合也可能有兩筆合法申請。去重規則應根據活動、對象與場合的業務定義，不能只比較姓名或電子郵件拼法。
保存紀錄時加入負責人、最新處理時間與下一個動作。只有紅色失敗標籤，並不能讓備援人接手；只有「已完成」也無法解釋到底完成了審查、下單還是寄送。讀者應能從同一個編號追到目前已知狀態，不必翻閱整段聊天猜測進度。
六個交接點，各自留下可驗收的結果
以下是可執行的架構順序，不是假設任何平台已自動提供整套控制。小公司可以由少數人兼任，但不能省略交接結果。每個階段都要能回答：輸入從哪裡來、誰有權改動、成功留下什麼、失敗時如何復原。
-
接收並驗證互動來源，保存來源識別、組織與接收時間。操作紀錄不應含有密鑰或不受限制的個人資料。
-
找到或建立正式申請。重送應回到既有編號與版本，不另生一筆看似新的需求。
-
按指定制度檢查資格、預算與衝突。技術上送出成功，仍可能因收禮人或場合不合格而停止。
-
由具權限的人核准確切版本，保存決定、身分、時間與範圍，而不是僅留下模糊的聊天評語。
-
由有執行權限的元件交付核准指令，保存供應端參照；若結果不明，明確標示不明，保留原操作。
-
分別核對訂單、寄送、收禮與財務結果。收到確認訊息，不能充當送達證明；折讓也不代表原交易從未存在。
這個順序讓入口故障時仍可繼續處理已存在的申請。備援人可在原紀錄內依核准程序人工接手，不需要另外做一張沒有對照的試算表。人工補救若換了申請編號，後續自動化恢復時就可能把同一筆需求再做一次，因此備援也必須遵守同一識別規則。
職責要跟著交接點指定。資訊人員負責部署與技術身分，制度負責人判定資格，預算負責人決定支出，營運人員處理寄送例外，紀錄管理人負責存取與保存。供應商負責的是約定服務，不會因收到一個核准欄位就取代公司的法律、稅務或雇主決定。
重送、逾時與取消需要不同處理
Slack 的事件配信文件要求及時回覆並說明失敗後的重送；Google Chat 的互動回應文件區分同步回應與後續經驗證的非同步處理。Teams 則須依選用的機器人、流程或介面確認規則，不可把另一平台的時限整段搬過來。
接收回覆代表「已收到」，不是「已批准」，更不是「已寄出」。把較長的業務處理放到受控執行程序，讓入口先保存可恢復的接收狀態。重複送達同一個核准指令時，應回傳已知結果，而非重新購買。試算表查到同一列不代表已具備可同時處理的鎖定機制，並行測試不可省略。
下單逾時尤其不能當成普通通知失敗。供應端可能已接受指令，只是回應沒有送回。此時保存原操作識別，以支援的狀態查詢或對帳方式確認，不要換一個新編號再送。通知可否重發與訂單可否重送，要由不同的證據判斷，否則一封漏掉的確認信可能變成兩份支出。
取消也有階段差異。交付前可以阻止尚未執行的指令；交付供應商後則是提出取消要求，必須等實際結果；送達後可能涉及退回或折讓。不要把申請人刪除訊息直接解讀成取消成功，也不要用刪除紀錄掩蓋已發生的費用。顯示給同事的狀態應包含下一位負責人與可預期的更新方式。
把維運成本與交接條件放進選型
授權費只是成本的一部分。評估時還要記錄誰會修改欄位、誰會更新角色對照、誰會處理例外，以及維護人休假時由誰接手。若現有流程由外部顧問建立，也要確認公司能否取得必要設定與操作文件。一次性的建置報價，不能自動涵蓋以後的人員異動、權限調整與紀錄匯出。
不要先把所有成本換算成一個看似精確的年度總價。先分清已取得報價、內部估算與尚未確認的項目，保留幣別、計價基礎與有效日期。沒有證據的維護工時應列為待確認，而不是填零。比較三個入口時使用相同的活動量與驗收範圍，才不會把簡單通知和完整核准架構拿來比價。
一個具體做法是列出每個月預期會發生的變更。例如新增活動需要誰調整申請類別，主管輪調需要誰更新權限，供應商暫停某個寄送國家需要誰暫停選項。由各負責人估算自己的工作，再說明哪些變更會要求重新核准、哪些只是更新介面。這是工作分解，不是平台效能測試。
同時寫清楚可接受的人工範圍。少量外部收禮例外可以交給指定人審查，卻不適合由聊天機器人猜測資格；少量結果不明的訂單可以逐筆對帳，卻不應因人手不足改成自動重送。人工步驟若有原編號、期限與負責人，仍然可被管理；完全沒有紀錄的便利操作才難以擴大。
正式移交前，請一位沒有參與建置的人照文件操作。給他一筆退回補正、一筆重送、一筆已核准但結果不明的測試申請，要求找出正確版本與下一步。他不需要看懂全部程式，但必須知道不能重送的原因、可以找誰決定，以及已知事實與待確認事項各是什麼。
如果交接演練失敗，修正的是文件、權限或狀態定義，而不是降低驗收門檻。若流程只能由建立者處理，就先縮小試行範圍，保留受控人工入口，等到責任與備援落實後再增加自動化。不要把更換聊天平台當作所有維運問題的解法，也不要把原本就缺少的制度責任算成某一平台的缺點。
假設案例一：已有 Slack 的軟體團隊
假設一家臺灣軟體公司準備用既有 Slack 工作區辦理員工里程碑贈禮。人資提供合格名冊，財務確認預算與幣別，資訊人員負責維護應用程式。試行共有八十筆不同申請，接收紀錄有八十八次配信，其中八次是重送。這些是示範數字，不是平台可靠度或 Giftpack 客戶成果。
團隊選用互動視窗，因為場合、收禮人參照、目的國與幣別必須固定填寫。替代方案是受控網頁表單，而不是要求同事在群組貼出地址。選擇視窗的代價是必須有人維護角色對照、欄位驗證與錯誤處理；若維護人不在，熟悉的聊天介面本身不會解決交接問題。
八十筆申請中，六十筆完成必要核准，十二筆退回補正，八筆不符合制度而拒絕。八次重送沒有新增申請。人資驗收的不是六十張綠色卡片，而是八十個不同申請編號、八十八筆配信參照，以及每個退回或拒絕的原因。補正後應產生新版，不抹掉原始審查。
六十筆核准指令中，五十九筆取得已建立訂單的參照，一筆回應逾時而不明。營運人員保留那筆原操作並向供應端核對，不能為了讓畫面全綠而再送第六十一筆。已建立訂單仍須另外追蹤是否出貨、是否送達；核准數不能直接拿去報告履約成功率。
最後做一次維護人交接演練：撤銷測試程式的一項權限，由備援人從正式紀錄找出待辦。若只能靠原維護人的私人對話找訂單，試行不通過。若備援人能說明每筆停在哪裡、由誰接手、如何避免重複，才有足夠依據討論正式上線，而非以一次成功訊息當結論。
假設案例二：併購後的兩個聊天環境
另一個假設集團的母公司使用 Teams，新併入團隊使用 Google Chat。歡迎活動有二十四位不同提名對象，其中六位透過兩個入口重複提交，因此總共收到三十筆表單。五位須接受外部收禮人審查，十九位可以進入一般核准程序。數字只用來示範對帳，不能據此推定稅務或雇用身分。
兩邊各自做一套同名自動化看似最快，但會留下兩份資格名冊與兩個支出入口。較可控的選擇是兩個入口接到同一份正式申請服務，以活動、收禮人參照與合格場合對應共同編號。真正不同的需求可以由有權人員例外放行，不能只因電子郵件大小寫不同就當成新對象。
母公司先試行維運中的核准流程，新團隊試行對話框。資訊與人資共同檢查兩邊能否輸出相同欄位與核准版本；如果其中一邊做不到，暫時統一使用受控網頁表單。這是有意識的過渡安排，不需要宣稱某平台落後，也不應為了保留兩個熟悉入口而接受不一致的授權邊界。
失敗演練包含三件事：核准後變更目的國、移除某位審查人存取權、刪除測試聊天訊息。目的國改變觸發新版與相關重審；已撤權的人不能靠舊卡片核准；刪除訊息不會讓正式紀錄或原訂單消失。五筆外部案例持續等待負責人決定，不得混入一般員工名單一起放行。
驗收時須重現二十四個不同提名、六組跨入口對照、十九筆一般路線與五筆暫停原因。備援人不必登入離職同事的私人聊天，也應能找到決定與後續訂單參照。若仍有一筆無法解釋，就修正那個缺口，而不是把三十次提交誤報成三十份成功贈禮。
保存必要證據，不等於永久複製聊天
Slack 保存設定與Teams 訊息保存說明都提醒買方檢查實際配置。訊息、檔案與其他工作資料未必由同一政策處理；Google Chat 的保留與匯出範圍也須依公司的實際合約及設定確認。本文不提供通用保存年限。
紀錄管理人應先說明保存目的、讀取對象、保留規則與適用的暫停刪除要求，再決定需要哪些證據。核准人與申請版本可能必須保留，但不表示同事的完整私人對話都應被複製。地址與收禮偏好宜另行管理；可參考企業贈禮資料治理指南拆解用途與區域存取。
訊息被修改或刪除時
保留被審查的正式申請版本。修改聊天內容只是提出變更，不是自動替換已核准條件；刪除訊息也不代表有權取消訂單。測試刪除影響的是連結、通知或必要證據，再由負責人決定修復方式。
訪客、撤權與離職交接
以訪客、調職主管及已撤銷權限的測試身分重跑查閱與核准。備援人必須能透過核准的紀錄系統接手，不可要求保留離職者個人帳號作為正常流程。權限拒絕應保留精確原因，不以更高權限繞過。
重複指令與下單結果不明
測試同一事件重送、同一需求跨入口提交，以及下單後回應中斷。三種情況分別保留配信、申請及操作編號。先查原結果，再決定是否需要補救；不能只換編號重送。
評估工作簿只填證據所在位置，不放真實地址、密鑰或完整個人資料。稽核讀者需要足夠權限驗證某個控制，不代表必須取得所有收禮資料。實際匯出也要用第二位有權人員重新讀取，確認不是只能在建立者自己的畫面裡看見。
還要測試通知順序改變。例如已確認出貨的申請，稍後又收到較舊的接收事件，不應因此退回等待狀態。制度與技術負責人應共同定義允許的狀態轉換，保留原事件及判斷理由，不能只按通知抵達的先後決定業務上的最新事實。這項測試也能揭露人工交接與自動處理各自持有不同進度的問題。
若兩邊紀錄不一致，先凍結受影響的後續指令，核對原申請、版本與供應端參照，再由有權人員決定修正。不能為了讓兩份報表數字相等，就把真實發生的訂單或失敗記錄刪掉。對帳應解釋差異，而不是只消除畫面上的差異。
用同一份試行記錄完成選擇
下載繁體中文評估試算表第一版，內含比較、使用說明、來源與可填寫的試行紀錄；檔案語言為繁體中文。
本篇提供的繁體中文工作簿把六個問題套用到三個平台，形成十八列證據記錄。第一個頁籤提供比較、方法與來源，第二個頁籤記錄確認狀態、負責人與證據位置。方法不加權、不預填勝方；只有三項輸入都齊備才顯示已提供證據，未確認或缺人、缺參照時仍顯示不足。
它計算的是哪些列缺少證據，不判定證據內容真偽，也不代替預算核准。填入一個位置後，仍須由審議人查看是否對應正確環境、日期與申請版本。十八列都填完，只代表可以進入選擇討論，不代表十八個控制已被獨立驗證，更不代表有權建立真實訂單。
先用合成身分與假資料試行，不寄真實禮物。逐項演練來源與業務身分、欄位缺漏、版本變更、重送、下單逾時、訪客、撤權及刪除訊息後的匯出。完成後再取得公司對小規模實際試行的另外授權，記錄尚未證明的條件與負責人，不把它們藏在一個總分裡。
文件與工作簿版本日期為二○二六年十月十八日，預定二○二七年一月十八日季檢；權限、產品或制度變更則提前重查。比較不需要每天重做全部測試，但影響既有證據的變更必須使對應項目失效，安排針對性複驗。保留原結果與修正，不把舊失敗紀錄全部刪掉。
選 Slack，是因既有工作區與維護責任能支撐這條路線；選 Teams，是因實際身分與核准環境通過要求；選 Google Chat，是因相同的控制在既有環境可被證明。三者尚未達標時，保留受控表單並不丟臉。最重要的是申請到決定可重現、交付結果可追查、例外有人接手。
在這個邊界確定後，可帶著申請欄位、核准分工與例外證據，與 Giftpack討論實際送禮執行需求。履約服務應補足公司的決定，而不是默默取代資格、法律、稅務、隱私或雇主責任。