多職缺人才地圖範本

一份可直接複製的範本,幫你同時整理多個開放職缺,而不必把候選人硬塞進同一個分數、同一位負責人或同一個下一步。

多職缺人才地圖範本

多職缺人才地圖能幫小型團隊同時處理好幾個已核准的招募問題,又不必假裝一個候選人分數能套用到每個職缺。這張地圖是規劃與審閱用的紀錄,不負責判斷一個人是否合適、有沒有興趣或是否有空。

每個職缺各用一條獨立的泳道。同一則來源觀察可能對好幾條泳道都有用,但解讀、負責人和下一個問題都屬於各自的泳道。這樣可以避免一個眼熟的職稱或亮眼的第一印象,變成跨職缺的定論。

加入人選之前,先把地圖設好

複製下面這張職缺泳道表。一張地圖應該涵蓋一段有明確範圍的招募期間,以及一組具名、已核准的職缺。

泳道 ID職缺成果必備條件的證據問題負責人下次審閱狀態
DATA-ENG負責一項界定清楚的正式環境資料系統成果有什麼證據支持此人能在所需範圍內負責?工程經理YYYY-MM-DD進行中/暫停/已結束
SOLUTIONS-LEAD主導一項界定清楚的客戶交付成果有什麼證據支持技術交付能力和利害關係人決策經驗?解決方案總監YYYY-MM-DD進行中/暫停/已結束
PRODUCT-ANALYST用分析支援產品或營運決策有什麼證據支持可比較的分析工作和決策情境?產品主管YYYY-MM-DD進行中/暫停/已結束

把範例換成你自己的職缺。每條泳道都要寫清楚哪些事不在範圍內、誰可以修改需求說明,以及什麼情況下停止新的搜尋。沒有審閱者或決策負責人的泳道,不要啟動。

把觀察和契合度分開

共用登記表記錄來源說了什麼,職缺泳道則記錄審閱時的解讀。保留來源網址或檔案、擷取日期,以及範圍明確的觀察,讓之後的審閱者知道當初看到的是什麼。

人員 ID共用來源觀察DATA-ENG 解讀SOLUTIONS-LEAD 解讀待查證的未知
P-001公開的專案紀錄提到一次 API 遷移和客戶上線相近:有可能負責過系統,但深度不明可能是相關的交付背景個人實際負責的部分、規模和時間遠近

絕對不要把個人檔案沒提到的事,記成未達條件。只能針對已核准的職缺問題,標記為有支持、相近、未知或有矛盾,並列出支持這個標記的來源。

指定主要泳道和下一個問題

一個人可能同時和好幾個職缺有關。先給他一條主要泳道,避免重複聯繫;只有在次要泳道的負責人有不同的證據問題時,才記錄次要泳道。

人員 ID主要泳道次要泳道下一個問題負責人下一步日期
P-001DATA-ENGSOLUTIONS-LEAD這次遷移中,此人負責的是哪一部分?工程經理YYYY-MM-DD

主要泳道是協調上的選擇,不是貼在這個人身上的標籤。當職缺負責人修改地圖,或證據回答了一個關鍵問題時,就重新指派。不要因為一筆紀錄出現在兩條泳道,就讓兩個團隊同時去聯繫。

複製這份營運紀錄

多職缺人才地圖
地圖期間/內容負責人/下次審閱日期:

職缺泳道
泳道 ID:
需求說明版本與職缺成果:
必備條件/偏好條件/不在範圍內的工作:
每項必備條件的證據問題:
決策負責人/搜尋負責人/審閱者:
搜尋範圍與停止條件:

人員紀錄
人員 ID:
來源或提供的資料/擷取日期:
共用觀察:
泳道解讀:有支持/相近/未知/有矛盾
主要泳道/次要泳道:
要查證的聚焦問題:
聯繫或下一步負責人:
處置結果/決定日期/理由:

每次審閱時,把已經沒有核准職缺問題的泳道關閉或暫停。保留決定的理由,日後重新啟動時,才不會把過去的工作當成現在的證據。

Talent Summoner 的定位

Talent Summoner 是我們的產品,提供 AI 人才搜尋、履歷排序,以及經你確認後才寄出的主動聯繫。於 2026 年 10 月 3 日查證,人才搜尋可以依一份職缺需求說明回傳公開來源的個人檔案,候選人排序則能依職缺說明整理你提供的履歷。這兩個流程都不會維護跨職缺的地圖,也不會替你決定泳道。請把這份範本當成團隊在負責人、問題和下一步上的唯一依據。

每個人都應該有一個總分嗎?

不應該。請用各職缺泳道的證據問題。同一個人在每個已核准的職缺上,可能各有不同、而且有限的證據。

一個人可能適合兩個職缺時,該怎麼處理?

指定一條主要泳道,寫明次要泳道另外要問的問題,並為下一步指定一位負責人。避免重複聯繫,也避免用互相衝突的標準評估。

職缺有變動時怎麼辦?

為泳道建立新版本,找出受影響的紀錄,先依變動後的條件重新檢查,再拿來和新的工作比較。

Talent Summoner 可以維護這張地圖嗎?

不行。它支援人才搜尋和履歷排序這兩項輸入。職缺、負責人、解讀和決定,都由團隊在自己的地圖中維護。

先建立職缺泳道,再只加入有可見來源、有泳道負責人、也有下一個問題的紀錄。

所有文章