台北人資的佳穎要為新人安排海外配送，資訊部門收到的試算表卻同時包含住址、緊急聯絡人、薪資代碼和多年累積的備註。供應商問要不要直接串接系統，她先停下來問：這次送禮，真的需要把這些欄位一起交出去嗎？
選擇名單交付方式，應先決定誰有資格、需要什麼資料、由誰更正，以及何時停止使用。CSV、SFTP、API 與收件人自填各自解決不同問題；最先進的連線，不一定是這次專案最容易負責、最少必要的安排。
四種選擇，其實位於不同層次
CSV 是檔案格式，SFTP 是檔案傳輸方式，API 是系統介面，收件人自填則是資料取得流程。因此四者不是只能擇一：定期 SFTP 可以傳送 CSV，資格資料透過 API 更新後，也可以讓收件人自行提供地址。
以下比較的是哪一種安排適合成為本案的主要交付模式，而不是替技術排等級。是否能採用，仍須確認實際系統、服務範圍、資料用途與承辦責任，不能從一般整合能力推定每一種方式都已提供。
| 主要交付模式 | 適合的條件 | 必須指定的人 | 最低驗收證據 | 暫不採用的訊號 |
|---|---|---|---|---|
| 單次核准 CSV | 名單有明確範圍與截止點 | 名單覆核人與更正窗口 | 欄位表、核准版本、安全交付與處置規則 | 多人持續替換檔案卻無人定版 |
| 定期 SFTP 檔案 | 資料按可預期批次更新 | 寄送、接收及錯誤處理窗口 | 排程、檔案識別、接收與對帳回報 | 漏一批或退回一批也無人發現 |
| 來源系統 API | 資格變更需要約定時限內同步 | 來源資料負責人與維運人 | 識別碼、最小權限、重複處理與撤權測試 | 資料用途與權威來源尚未確定 |
| 收件人自行填寫 | 地址或選擇應由本人當下提供 | 邀請、逾期與未回覆處理人 | 告知、適當驗證、期限及後續方式 | 沒填寫的人沒有下一步負責人 |
判斷時，先看錯誤的後果。資格錯誤可能邀請到不適用的人，地址錯誤可能造成錯寄，技術傳輸成功卻可能同時包含這兩種問題。能把檔案送到另一端，不等於收件名單可以使用，更不等於已批准出貨。
佳穎因此要求候選方案回答同一個情境：一位新人改了公司信箱、尚未提供海外地址，原先福利資格則沒有變。哪個欄位由誰更新？是否會多發一次邀請？誰決定何時可以交付？這比單看介面名稱更能分辨可營運性。
先把領取資格與配送地址拆開
資格資料回答的是這個人能否參與某項禮品計畫，地址資料回答的是商品要往哪裡送。建立合資格名單時，可能只需要適當的識別碼、聯絡方式與資格狀態，不必同時取得完整住址。
員工編號即使沒有姓名，也不應因此被當成匿名資料。只要在實際情境中仍能連回本人，就需要按相應用途、權限與責任管理。減少欄位不會自動讓資料脫離應有的保護範圍。
國別也要分清用途。工作地國別可能用於初步規劃商品範圍，卻不一定是最後配送國別；有人可能在海外辦公，卻選擇寄往另一個已確認的地址。不要把一個欄位同時當成資格、地址與可配送保證。
最後，把參與資格和批准寄送分開。某人可以領取，不代表地址、商品或目的地都已確認。系統匯入一列資料後，應讓團隊知道發生了什麼，不要把可處理的名單悄悄變成不可逆的出貨指示。
在地個資要求，是用途確認的起點
全國法規資料庫的個人資料保護法第五條要求蒐集、處理或利用不得逾越特定目的必要範圍，並與蒐集目的有正當合理關聯。這提供欄位審查的依據，但不直接判定某一跨境送禮或委託安排是否已符合全部要求。
對佳穎而言，應先請各欄位的資料負責人解釋本次用途。緊急聯絡人原本是為了人事或安全需要取得，不會因為它恰好在同一張表上，就成為寄新人禮所需資料。無法說明用途的欄位，先不要放進這次交付。
地址由本人填寫，也不代表其他前提自動完成。仍要確認適用的告知、合法處理依據、服務對象與保管安排。不要用一個預設勾選或檔案建立時間，代替真實發生且適用於本案的必要證據。
若涉及不同地區或多個受託角色，應由相應的法務、隱私與業務窗口確認具體安排。本文用來比較如何分工與驗收，不替個別案件作法律結論；選擇傳輸技術，不能取代對資料用途和責任的確認。
單次 CSV，適合真正能夠定版的名單
一次性活動若有明確對象與截止日，核准後的 CSV 可以是可管理的起點。關鍵不是檔案看起來簡單，而是有人能指出哪個版本已被批准，以及截止後的新增、退出或更正應如何處理。
先約定欄位名稱、必要值、識別方式及覆核責任。地址空白不一定是需要補齊的格式錯誤，也可能表示尚未取得本人確認。不要為了通過匯入驗證，直接從歷史表格找一個住址塞回去。
CSV 本身不會提供加密，也不會決定誰可以看內容。應使用組織核准的交付與儲存方式，確認接收者和可存取人員。這些是實際方案要驗證的條件，不是看見上傳按鈕就能假設存在的能力。
定版後的更正也要保留脈絡。新檔案是否取代舊版，影響哪些人，之前是否已發邀請或建立訂單，都應能追到原批准。不能只因新附件名稱多了更新兩個字，就讓它覆蓋後來已完成的收件人選擇。
定期 SFTP，買的是有人管理的批次節奏
當資料依固定週期變動，可以比較定期檔案交付。必須同時有人負責來源排程、接收確認與退回資料，否則只是讓相同風險定期發生。排程存在，不等於每一批都有人核對。
OpenSSH 的 SFTP 官方說明描述以加密 SSH 傳輸進行檔案操作。這處理的是傳輸通道，不會自行證明檔案欄位適合本案、接收方有權取得，或下載後的副本保管正確。
請對方示範漏掉一批和整批退回的情境。來源端應知道預定版本是否被收到，接收端應能說明哪些資料可用、哪些被保留或拒絕。只顯示傳輸成功，無法取代名單是否已被正確處理的結果。
再確認每批代表完整快照還是異動清單。某人沒有出現在檔案裡，是取消資格、資料尚未送齊，還是本次沒有變更？這個意義需要雙方明確約定，不能由維運人憑經驗猜測。
也不要從供應商說有系統整合，就推定它一定提供 SFTP。必須確認實際產品、帳戶、目的端及權限方式。若沒有人願意處理漏批和退件，就先保留這個模式，並以範圍清楚的方式進行可管理的試點。
API，適合有權威來源與持續維運的情境
資格需要在約定時限內更新，而來源系統也有人負責時，可以評估 API。請先定義業務能接受多久的延遲，再討論技術；即時兩個字如果沒有對應驗收時間，就很難判斷提案是否符合需求。
連線不會讓來源自動成為權威。人資和活動單位若各有一套資格標準，應先決定本案由哪個來源控制，例外如何批准。兩套矛盾資料都接進來，可能只是讓衝突更快散布。
要求候選安排說明識別碼、最少欄位與可撤銷權限。重複更新、延遲事件、已交付後才收到取消資格時，應由誰作什麼決定？這些是實際介面需要展示的結果，不是僅憑 API 名稱就能視為已支援。
移除權限要與新增權限分開測試。能加入人員，不代表之後一定能停止邀請；能取消下一步，也不代表已送出的商品可以自動追回。應明確確認每一個實體作業階段的變更界線。
若目前沒有維運人處理錯誤、權限更新和欄位變更，可以先做有範圍的檔案試點，同時建立這些責任。選比較容易維持的安排，不是技術倒退，而是讓可承擔的工作與專案要求一致。
收件人自填，解決的是資料從哪裡來
如果人資只需要確認領取資格，住址則應由本人在領取時提供，自填流程可以減少預先匯出地址的需求。這個模式可以和單次檔案或 API 搭配，不一定要取代全部系統連線。
但填入地址不等於已驗證本人，也不等於可以處理所有目的地。請確認邀請對象、可接受的驗證、更正方式與商品選擇限制。這些都要依實際專案決定，不能把一個表單當作完整控制。
邀請期限與未回覆處理同樣重要。有人未開啟、有人不想收禮，有人需要已批准的替代方式。應有窗口決定提醒、展延或結束，不能把沒回覆解釋為同意使用人資原有的住址。
對使用者而言，流程應說清楚為什麼需要資料、何時需要、如何更正以及不提供會怎樣。若選擇地址可以稍後再填，就不要在資格建立時先要求所有人交出完整住址，增加不必要的中間副本。
第一個判斷：一千二百名新人，如何承接持續異動
假設佳穎收到一千二百筆新人相關資料。依本次已約定規則覆核後，一千零四十人可參與，九十人待確認，七十人不符合資格。三個數量相加為一千二百，這些都是用來比較流程的假設，不是實際客戶成果。
九十筆待確認資料可能缺少核准紀錄或資格狀態互相矛盾。應交由適當的業務負責人判斷，而不是由匯入操作人把它們改成可用。只要問題未解決，就不包含在已批准的邀請範圍。
佳穎先比較一次定版 CSV 與每週 SFTP 批次。如果這批新人有明確截止點，人資能管理後續例外，單次檔案可能足夠；如果每週變動都要持續承接，人資還需要能準時交付並處理拒收回報。
再假設下週有三十項異動：八人退出資格、十人更正聯絡方式、十二人新增資格。原本一千零四十人，減八加十二後為一千零四十四人。十筆聯絡更正不會多出十位新人，也不應新增十次領取權益。
若原九十人仍待確認，原七十人加上退出的八人形成七十八人不符合資格，整體來源人數就是一千二百一十二：一千零四十四加九十加七十八。新增十二人解釋了總人數增加，而異動筆數三十不是新增人數。
驗收時，請候選安排在測試環境重複收到同一批變更。第二次不應再加十二或再減八，也不應因信箱改變而把同一人辨認成另一個人。這是本案要求展示的處理行為，不是宣稱某個介面天然保證不重複。
若每週更新可以滿足需求，且來源端願意承擔批次節奏，SFTP 可以成為候選。如果退出資格需要更短的更新時限，再比較來源 API。人數多本身不是選擇 API 的理由，真正的依據是可接受延遲、責任與實際測試。
第二個判斷：三百位海外同事的地址要由誰提供
再看另一個情境：台北團隊向三百位已批准的海外同事發出領取邀請。組織已有合適的工作聯絡方式，但不需要先匯出人事系統中的家庭資料，便可建立這次領取資格，因此比較由本人提供配送資訊。
假設截止時，二百三十八人已完成可接受的配送提交，二十二人需要確認替代安排，十二人選擇不收禮，二十八人未回覆。四個狀態合計三百人。這是營運算例，不是預估領取率或行銷成效。
二十二人不能因為已打開邀請，就被算成可以出貨。可能需要確認商品、目的地或另外批准的方式。下一步要由具有權限的角色處理，只取得該決定需要的資料，不把整份人事檔案重新提供給每個窗口。
二十八人未回覆，依專案規則決定提醒或結束。不要為了讓報表完成率好看，直接從歷史資料補入地址；原本的未回覆狀態沒有因此變成一次真實的地址確認，組織也不能省略應有的決策。
十二人的不收禮選擇應與本次計畫相連。下一版來源名單若仍顯示他們是合資格員工，不代表可以自動重新發出相同邀請。資格資料與本人已完成的回覆，需要各自有權威來源與適當處理。
假設已提交的二百三十八人中，有五人在約定出貨截止前更正地址。人數仍是二百三十八，變更的是五筆資訊。需要確認更正確實到達履約決策，不是只看到自填頁顯示成功，就以為倉儲正在使用新地址。
這次可以由最少欄位的批准名單建立資格，再接本人自填地址。驗收資料應能對上三百人的狀態，並為每一組未完成項目提供負責人與下一步；不是只把收到表單的數量當成全部禮品都已交付。
一個空白值，可能代表完全不同的決策
除了正常更新，還要測試空檔案、空欄位和來源未到。完整快照若是空白，是否表示全體取消資格？異動檔若是空白，是否只代表沒有變更？這兩種解釋差很大，必須由原始規則決定。
地址被清空，可能代表本人要求修改、來源欄位不再提供，或某個匯出步驟發生錯誤。不要用同一種預設，把三個情況全部變成沿用舊地址或取消訂單。先辨認變更的意義，再決定誰可以處理。
同樣地，API 沒有回傳某個欄位，不一定等於要求刪除它；檔案新增一欄，也不代表接收方有理由保留。每個版本需要清楚的欄位約定，遇到未確認的變更時，保留受影響部分而非自行擴張解讀。
這類邊界測試不一定需要大量資料。先用不含真實個資的測試紀錄，確認各端理解一致，再取得正式操作所需批准。不要拿真實員工名單邊傳邊試，才發現空白值會觸發與預期不同的外部動作。
錯誤回報也是一次資料交付
檔案被拒收時，回報應能指出受影響的識別、問題規則與處理窗口，但不必把完整住址、私人電話和所有備註複製進每張工單。誰需要看到完整內容，誰只需要知道該筆待修，都要先決定。
對聯絡方式更正，也應確認回報不會送往舊的錯誤地址。若以同一個錯誤欄位作為通知與身分辨識的唯一依據，操作人可能無法找到正確的人。來源負責人應提供適合本案的識別與核對方式。
系統回報逾時時，不要直接重送整份名單。先確認原版本是否已接收，哪些業務動作已發生，哪些仍無法確認。改檔名、換排序或重新匯出，不會讓未知結果自動變成安全可重試。
若部分結果已確認，可以把未確定的部分分開保留，讓已核准且獨立的資料繼續。前提是狀態與對外承諾一致，不把已收到資料、已發出邀請、已建立訂單和已交付混為同一種完成。
在開始蒐集時，就決定如何結束
資料保管期限應根據實際用途與適用要求決定，不是從其他公司的範本抄一個天數。請確認由誰持有哪一份資料、為了什麼目的、到什麼條件需要停止使用或處置，以及能提供什麼確認。
來源匯出、核准名單、錯誤報告、配送資料和必要業務紀錄，可能有不同的用途與負責人。刪掉一個上傳檔案，不代表所有下游副本或備份都已消失；應向實際保管方確認其安排，而不是對外作超過證據的保證。
專案也可能需要保留有限的決策或結算證據，卻不再需要完整地址表。這要由適當的角色有意識地區分，不把需要某項紀錄，擴張成所有欄位都可以永久保留的理由。
結束測試包括撤回不再需要的存取、讓邀請按規則失效、指派未完成項目的處理，以及確認約定的資料處置。技術連線還能運作，不代表它在業務目的結束後仍應繼續取得資料。
把欄位表變成可以驗收的約定
最少欄位不能只是一張刪過幾欄的試算表。每個保留欄位都要寫明本次用途、來源、可以更正的人，以及接收後會參與什麼決策。否則今天認為必要的欄位，下次很容易因為檔案格式方便而繼續被複製。
例如資格識別碼用來連結同一人的變更，聯絡方式用來送出已批准的邀請，國別可能只用於初步評估選項。這只是待核准的用途例子，不是供應商已接受的正式欄位。實際名稱、格式及是否必填，都需要與接收端確認。
請以一位更正公司信箱的測試人員，檢查來源端、邀請端與錯誤回報是否仍指向同一人。若舊信箱和新信箱形成兩份資格，即使檔案欄位全部正確，業務結果仍不符合一次領取的要求。驗收應看最後的對應，不只看匯入筆數。
再用有前導零的識別碼、中文姓名與需要保留原樣的地址內容測試。團隊要確認傳送、接收和人工檢視後是否仍一致；任何顯示上的轉換，都不能不經確認就回寫為本人的正式資料。便利的格式整理，不應改變資料原意。
權限也依用途分開。人資可能需要看資格來源，客服只需要處理特定邀請，履約方則需要已批准的配送資料。哪個角色能看到什麼，不應由曾經拿到完整附件的事實來決定，而要回到實際工作與核准範圍。
測試還應包含離開原職務的人。當窗口換人或專案結束，舊的連線、資料夾或下載權限如何處理，應有負責人驗證。不能只替新窗口增加存取，卻一直保留原窗口不再需要的同等權限，讓每次交接都累積另一份可取得的資料。
正式驗收時，保留測試使用的欄位版本、預期結果與實際結果，並註明由誰接受差異。若接收端臨時增加必填欄位，先回到資料用途審查，不應為了讓流程繼續，就由操作人隨意從人事系統補齊。測試紀錄應能讓接手者辨認，當時批准的究竟是哪一種交付範圍。
最後，欄位增加要成為可辨認的變更。來源系統下次多匯出一欄，不代表原來的批准已自動涵蓋；接收方應知道哪些變更需要重新確認。把用途、版本和批准接在一起，才有機會在需求擴大時仍維持最少必要，而不是讓第一版的好決定逐漸失效。
把維運工作放進模式比較
比較成本時，使用相同的受眾、欄位、更新頻率與可接受延遲，問清建置、監控、對帳、收件人支援及來源變更由誰負責。不能把檔案流程假定為不用人管，再把 API 維運視為額外成本，反之亦然。
例如每週需要兩次各四十五分鐘的覆核，試點八週，就是七百二十分鐘，也就是十二小時。若用每小時六百元作為內部規劃價值，合計七千二百元。這是透明假設，不是薪資、業界標準或自動化保證省下的金額。
若供應方案已含相同覆核，就不能把該工作同時計入外包費和內部工時。應逐項列出工作一次，再確認誰真正承擔，才能知道較低的傳輸費是否把大量例外處理留給人資。
改用新模式的理由，應是更合適的更新時限、可靠的權威來源、可管理的例外或更少不必要資料。把同一份過度完整的人事檔案更快送出去，並不等於資料交付已經改善。
用一份小型決策包定案
定案資料可以包括最少欄位表、資格與配送的責任分工、正常與失敗測試、變更界線、未回覆處理，以及保管與結束規則。重點是從一位收件人的資格，能一路追到實際地址決策與後續狀態。
資料負責人不在時，也應有另一位同事能解釋目前使用哪個版本、哪一批仍有問題、誰有權修正。若需要靠原承辦人記得某封郵件，這個交付模式就尚未完成交接，不宜只用成功傳輸來宣布上線。
當來源、欄位、目的地或受眾改變，重新確認受影響的部分。上一次用另一份名單的成功測試，可以說明經驗，卻不能覆蓋本次新增的處理目的或不同權限。每季或遇到重大變更時，都應檢視原先選擇是否仍合適。
佳穎最後要交出的不再是一份最大的員工匯出，而是一條能對資料負責的流程。哪些人能領、哪些資訊現在需要、由誰更正、什麼情況可以寄送，都有明確答案，技術才真正接上了業務決定。
與 Giftpack 確認實際可承接的資料路徑
Giftpack 的平台整合與企業贈禮說明提供系統、資料流程、權限與專案安排的討論方向。API 與整合範圍仍需依實際產品及帳戶確認，不能由一般整合介紹推定所有檔案傳輸方式都已支援。
如果本案適合由收件人在領取時提供地址，也應確認具體邀請、驗證、逾期與更正流程，而不是假設每個計畫都相同。帶著最少欄位表、兩個工作情境、失敗更新測試和結束規則來規劃，讓 Giftpack 一起確認能承接的安排，再開始正式交付名單。