软件工程师岗位
使用场景: 一位正在招资深工程师的科技招聘官
渠道——1200 份申请,以内推为主
简历筛选——720 份通过(60%)
面试——180 人(来自筛选 25%)
offer——54 个(占面试 30%)
入职——40 人(offer 接受率 74%)
这样组织的原因: 科技漏斗以内推为主,风险点在 offer 环节——发得慢就把候选人让给竞争对手,所以漏斗要盯紧面试到 offer 的转化。
使用场景: 一位正在招资深工程师的科技招聘官
这样组织的原因: 科技漏斗以内推为主,风险点在 offer 环节——发得慢就把候选人让给竞争对手,所以漏斗要盯紧面试到 offer 的转化。
使用场景: 一位在招小时工的店长
这样组织的原因: 零售量大、筛得快。漏斗顶部很宽、offer 接受率高,所以问题通常出在筛选环节,而不是 offer。
使用场景: 一位负责招持证护士的医院 HR
这样组织的原因: 医疗漏斗收得早,因为资质和背景核验在面试前就砍掉一批。漏斗显示是早期关卡而不是面试在做主要过滤。
使用场景: 一位在招第一位全职员工创始人
这样组织的原因: 创业公司第一个员工是低量、高投入的漏斗。漏斗显示池子小、面试环节精细,创始人在每个候选人身上花更多时间。
使用场景: 一位同时管多个客户岗位的猎头
这样组织的原因: 猎头同时跑好几条漏斗。每个岗位单独记一条,转化数学才干净,也能看出哪个客户的岗位最难招。
使用场景: 一位负责校招的招聘官
这样组织的原因: 校招在筛选和面试之间多一道测评。漏斗顶部量大、offer 接受率高,所以漏点主要在前期的筛选环节。
回到模板页,替换成你自己的内容,就可以继续使用这套结构。
使用这个模板: /editor/new?template=recruiting-pipeline
使用这个模板