大量招募的需求收集設計

大量招募的需求收集設計，會把招募需求轉成一份計畫，包含分組、證據、預留的工作時數、負責人和停止點。不論招募量多大，這份計畫都維持同樣的標準；它是一份計畫，不是職缺開立申請，也不是對候選人供給量的預測。

如何為大量招募需求分組

只要職缺、地點、班別、語言或到職時段會改變成果、證據、對候選人的訊息或核准方式，就把招募需求拆成不同的分組。記下訊號、期間、負責人和狀態。沒有負責人的數字是未知，不是目標。

撰寫需求說明之前，先用一張分組表整理：

如果某項重大差異會改變甄選證據，就另外建立一個分組，或取得核准。

大量招募的需求說明要寫什麼？

每個分組各寫一份需求說明，並標上版本號。需求說明要列出成果、範圍、地點／班表、僱用類型、評估條件與相近路徑、證據來源／問題、候選人流程、階段、升級處理方式和具名負責人。每項評估條件都需要一個與工作相關的理由，以及一致的證據問題。把偏好歸類為加分條件；公開個人檔案裡缺少的細節，維持未知。

校準時使用這張評估條件表：

在同一個分組內，審閱者記錄有支持、不支持、有矛盾或未知，並附上來源和擷取日期。分數無法把不確定變成事實。

如何建立大量招募的審閱產能模型

用「完成的工作單位」來建立審閱產能模型。選定一種單位，例如一筆可審閱的紀錄、一次交接、一次篩選或一輪面試，並且只計算這種單位。每個階段分開報告；絕對不要把時數除以一個未知的錄取人數。

Net stage hours = reserved hours - leave - committed work - required meetings - protected reserve

Review capacity = FLOOR((net stage hours - setup hours) / (minutes per completed review / 60))

上面兩個公式分別計算階段淨時數（預留時數扣掉休假、已承諾的工作、必要會議和保留緩衝），以及審閱產能（淨時數扣掉準備時數後，除以每次完成審閱所需的小時數，再無條件捨去）。這個示意計算只適用於所述的分組、期間、負責人、版本和事件。沒有預留的輸入值是未知或一個範圍，不代表對候選人或錄取的保證。

這些數字都是虛構的，不是業界基準。規劃一個批次時，以篩選或面試小組中最小的產能為準；絕對不要把各階段加總成一個招募管道總數。

大量招募的需求收集應該使用哪些證據關卡？

大量招募的需求收集使用五道證據關卡。每道關卡只有在負責人記下最低限度的證據後才會開啟：

擴大批次之前，先由兩位審閱者評估一小份樣本，比較彼此的歧見，並替規則變更標上版本。校準控制的是解讀方式，不是公平性，也不是預測。

如何在大量招募中保護候選人體驗、公平性與隱私

告訴每個人所屬的分組、下一個階段、問題由誰負責，以及需要提供哪些資訊。使用一致的狀態和結案原因。承諾回覆時間時，要有具名的負責人；絕對不要暗示做過其實沒有發生的人工審閱。提供無障礙的替代方式，並限制合理調整紀錄的存取權限。

W3C WCAG 2.2 建議標準是 W3C 在 2023 年 10 月 5 日發布的建議標準，於 2026 年 9 月 4 日查核；它是技術參考，不是招募政策。請向當地負責人確認哪些規定適用。

把公平性監控和甄選分數分開。一致地套用評估條件、記錄人工覆寫、檢查篩選機制、限制敏感資料，並以彙總數據報告。

美國公平就業機會委員會（EEOC）的法規與指引頁面於 2026 年 9 月 4 日查核，連到美國的甄選指引，包括 29 C.F.R. Part 1607（美國聯邦法規第 29 編第 1607 部分，1978 年）。請取得合格的當地專業審查。

處理個人資料時，記錄目的、最少必要欄位、存取權限、保存期限和更正管道。資料公開可見，不代表可以重複利用其中的每一項細節。英國資訊專員辦公室（ICO）對以 AI 輔助招募的考量重點發布於 2024 年 11 月 6 日，於 2026 年 9 月 4 日查核，是英國的指引。

使用候選人排序工具時，要定義目的、輸入、限制、監控方式和事件處理管道。NIST AI 風險管理框架 1.0發布於 2023 年 1 月 26 日，於 2026 年 9 月 4 日查核，是自願採用的指引；必須由人暫停流程並檢查證據。

大量招募的需求收集應該追蹤哪些指標和分母？

替每個事件指定負責人，並讓每個分母都看得見：

報告數量時，附上日期和分組標籤。沒有分母的比率不是訊號。只有在階段、期間、資料品質和推進機會都可比較時，才比較不同分組；數量很小時，就不公開，或改用質性方式回顧。

何時停止、升級處理或變更大量招募的需求收集

出現以下任何一種情況，就暫停大量招募的需求收集：

• 核准已經到期；
• 評估條件或產能有所改變；
• 證據無法追溯；
• 某項對候選人的承諾或合理調整沒有負責人；
• 疑似發生隱私事件；
• 某種甄選模式需要合格人員審查。

升級處理紀錄要包含分組／版本、時間、問題、受影響的紀錄、控制措施、負責人、下次回顧時間和未知項目。只保留最少的受限資料；不要改寫處置結果。

對成果、分組、評估條件、證據、班表、管道、階段、產能或工具的重大變更，都要進行變更控管。記錄原因、生效日期、受影響的紀錄，以及是否需要重新審閱；舊版本以唯讀方式保留。

虛構範例：拆分季節性客服的需求收集

這個虛構範例說明，季節性客服的需求收集要在任何審閱開始之前，先依語言和班別拆分。虛構的 Harbourlight Services 要在粵語晚班和英語日班兩個分組中，開出 40 個季節性客服職缺。財務部核准的是時段和負責人，不是人數：「申請 40 人，核准待定。」

兩份需求說明共用同一個成果，但把語言和班表的證據分開。在預留 32 小時、準備 3 小時、每次抽樣 24 分鐘的情況下，FLOOR((32 - 3) / 0.40) = 72 是示意的工作單位，不是供給量，也不是錄取人數。

審閱者對零售業的工作經驗能否支持「客戶管道」這項評估條件意見不一。主管暫停流程，新增一條相近證據規則，替需求說明更新版本，標記受影響的紀錄，並更新對候選人說明下一步的措辭。

可直接複製的大量招募需求收集工作表

每個分組各複製一次下方的工作表，並讓每個重要欄位都有核准的來源或決策紀錄作為依據。

大量招募需求收集
分組／職缺類別／地點／班別／僱用類型：
需求說明版本／狀態／生效日期：
需求訊號、期間與核准人：
要求人數或情境（標示為已核准、提案中或未知）：

成果與評估條件
這個分組負責的成果：
範圍內／範圍外：
必備條件／與工作相關的理由／證據問題／來源：
加分條件／它不構成否決條件的理由：
可接受的相近路徑：
核准的限制與合格核准人：

產能與分母
主要完成事件：
預留時數／準備時數／每單位抽樣分鐘數：
已承諾的工作、休假、會議與保留緩衝：
低／基準／高假設與來源日期：
計算出的工作產能（不是錄取或成果保證）：
瓶頸階段與負責人：

品質與體驗關卡
校準樣本與結果：
必填紀錄欄位與證據狀態值：
對候選人顯示的狀態、回覆負責人與無障礙管道：
保存、存取，以及更正或停止處理的管道：

負責人與控管
需求負責人／需求說明核准人／審閱者：
候選人體驗負責人／變更核准人／最終決策負責人：
停止條件與升級處理管道：
指標、分子、分母與回顧日期：
變更紀錄或受影響的先前決定：
決定：啟動／修訂／縮小批次／暫停／結案
下一步行動、負責人與回顧日期：

Talent Summoner 在大量招募需求收集中的定位

Talent Summoner 是我們的人才搜尋與候選人排序產品；它不是大量招募的營運系統。人才搜尋於 2026 年 10 月 3 日查核，會從一份職缺需求說明開始，從公開來源回傳排序後的結果。請在需求說明核准之後再使用；由人查證背景脈絡並決定下一步。

如果你有一個經授權的履歷庫，候選人排序於 2026 年 9 月 30 日查核，會比較你提供的履歷，供人工審閱。設定需求、計算產能、檢查公平性、操作 ATS、處理合理調整、進行面試和決定錄取，仍然由你的團隊負責。

只有在經授權交接的情況下，才從人才搜尋轉到候選人排序。

先核准一份需求說明，測試校準，再把人才搜尋和候選人排序用在經授權的工作上。