findscripter 招聘漏斗管理与候选人阶段跟踪
把招聘流程当作一条漏斗来管理：跟踪每位候选人处在 sourcing → offer accepted 的哪个阶段，并基于阶段流转计算转化、速度与渠道效率指标，回答「现在某岗位招到哪一步了 / 各阶段有几人 / 卡在哪 / 多久能填上」这类问题。
何时使用
- 招聘经理或 HR 问「这个岗位招聘进展如何 / 各阶段还有几个候选人 / 还要多久能 close」。
- 需要把一批候选人按阶段归位、做成漏斗看板，看清在哪一环掉得最多。
- 要算招聘漏斗指标（阶段转化率、各阶段停留天数、offer 接受率、time to fill、渠道产出）。
- 用户说「recruiting update」「candidate pipeline」「how many candidates」「hiring status」，或在谈 sourcing / screen / interview / offer。
不该用的边界：
- 设计面试题库、评分卡、面试官分工 → 用
interview-plan-builder（那是 interview 这一单个阶段内部的方法）。 - 起草 offer、拼薪酬包、谈薪话术 → 用
offer-letter-drafter。 - 设计公司薪酬带宽 / 做薪酬基准 → 用
compensation-analysis。 - 写 JD、招聘需求审批、入职手续——超出本条的漏斗跟踪范围。
漏斗阶段（固定六阶段）
| 阶段 | 含义 | 关键动作 |
|---|---|---|
| Sourced（已触达） | 已识别并发出触达 | 个性化 outreach |
| Screen（初筛） | 电话/视频初筛 | 评估基本匹配度 |
| Interview（面试） | 现场或专题/小组面试 | 结构化评估 |
| Debrief（复盘） | 团队做决策 | 校准反馈口径 |
| Offer（发 offer） | 发出录用通知 | 薪酬包、谈薪 |
| Accepted（已接受） | offer 被接受 | 交接到入职 |
每位候选人在任一时刻只处于一个阶段；阶段只向前推进或淘汰（reject），便于统计转化。
步骤
- 确定范围：先问清是看单个岗位（req）还是多个、时间窗多长。没有岗位/范围就先收敛，别全量铺开。
- 归位候选人到阶段：把每位候选人映射到上表六阶段之一；淘汰的标 rejected 并记录所在阶段（用于算各阶段 drop-off）。接入 ATS 时直接拉取候选人与状态，否则按用户提供的名单/表格录入。
- 出漏斗看板：按阶段聚合，给每阶段的候选人数（必要时列名单），形成从 Sourced 到 Accepted 的漏斗视图，让掉量环节一眼可见。
- 算指标（见下「监控指标」）：转化率、阶段速度、渠道效率、offer 接受率、time to fill。
- 给结论：指出瓶颈阶段（转化骤降或停留过久处）、与目标的差距、下一步动作（补 sourcing、催面试、调整 offer 等）。
监控指标
- Pipeline velocity（漏斗速度）：每个阶段平均停留天数。
- Conversion rate（转化率）：相邻阶段的通过/掉量比例（stage-to-stage drop-off）。
- Source effectiveness（渠道效率）：哪些来源渠道最终产出 hire。
- Offer acceptance rate（offer 接受率）：发出 offer 数 vs. 接受数。
- Time to fill（填补周期）：从 req 开启到 offer 被接受的天数。
指令
- 若接入了 ATS（招聘系统）：自动拉取候选人数据、更新候选人状态、实时跟踪漏斗指标，无需人工录入。
- 无 ATS 时：以用户提供的候选人名单/表格为准，缺阶段或日期就追问补齐，再做聚合与计算。
漏斗看板建议输出（Markdown）：
## 招聘漏斗：[岗位] — [时间窗]
| 阶段 | 在阶段人数 | 本阶段淘汰 | →下一阶段转化率 | 平均停留(天) |
|------|-----------|-----------|----------------|-------------|
| Sourced | X | X | X% | X |
| Screen | X | X | X% | X |
| Interview | X | X | X% | X |
| Debrief | X | X | X% | X |
| Offer | X | X | X% | X |
| Accepted | X | — | — | — |
汇总：time to fill ≈ X 天 · offer 接受率 X% · 最有效渠道：[来源]
瓶颈：[转化骤降/停留过久的阶段] → 建议：[下一步动作]
示例
用户：「Senior Backend 这个岗现在招到哪一步了？」
- 范围 = 单岗位 Senior Backend；接入 ATS 则直接拉取，否则要名单。
- 归位：Sourced 18、Screen 7、Interview 4、Debrief 2、Offer 1、Accepted 0。
- 算转化：Sourced→Screen 39%、Screen→Interview 57%、Interview→Debrief 50%……发现 Sourced→Screen 掉量最大。
- 结论：漏斗顶部触达回应率偏低是瓶颈，Offer 阶段尚无产出，time to fill 预计仍需补 sourcing；建议优化 outreach 文案并加大 sourcing 量。
注意事项
- 一人一阶段：同一候选人不要同时计入多个阶段，否则漏斗与转化率失真。
- 淘汰要记阶段：算 stage-to-stage drop-off 必须知道候选人在哪一阶段被 reject。
- 接受率看的是 total：offer 接受率分母是「发出的 offer」，不是「面到 Offer 阶段的人」。
- ATS 数据先核验：自动拉取的状态可能滞后，关键数字（尤其 offer 状态）发出前对照源系统确认，别用过期导出。
- 涉及候选人个人信息，遵守隐私/合规要求；候选人评估的具体口径属面试方法范畴，转
interview-plan-builder。
互见
- related：
interview-plan-builder—— Interview 这一阶段内部的结构化方法（题库、评分卡、复盘）。 - related：
offer-letter-drafter—— 推进到 Offer 阶段后的 offer 起草与谈薪。 - related：
sales-forecast-builder—— 同构的「分阶段漏斗 + 转化率 + 速度」建模思路，可类比迁移。 - related：
customer-health-scorer—— 另一类按阶段/状态跟踪与打分的近亲技能。 - combines_with：
interview-plan-builder、offer-letter-drafter—— 漏斗推进到对应阶段时联用，形成「跟踪→面试→发 offer」闭环。 - combines_with：
hr-partner-pro—— 接入更宽的招聘与人事流程（JD、入职、headcount）。
采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可证）。