招聘人员
- 开头为
- 已分配的申请和候选人下一步行动
- 作用于
- 放映、舞台移动、沟通和例外情况
- 放手
- 向招聘经理提供证据准备的候选人
招聘管理系统
让责任清晰、进度可控的招聘管理系统
将人员需求、职位审批、招聘执行、用人团队决策和录用衔接起来，让招聘负责人在一个系统中掌握产能、延误与结果。
工作区把每项招聘职责拆分为可管理的独立记录，同时保留端到端管理所需的关联关系。
- 人员需求与已批准空缺
- 招聘专员与用人经理之间的交接
- 面试、录用与结案管控
管理候选阶段之前、期间和之后的工作
招聘系统应显示业务决策、下一步行动的负责人以及每次交接时所需的证据。
- 01
需求
- 所有者
- 部门领导
- 决定
- 该角色是否需要并得到资助？
- 信号
- 业务原因、空缺、预算和目标开始日期
- 02
已批准的招聘需求
- 所有者
- 招聘负责人
- 决定
- 谁拥有交付以及何时交付？
- 信号
- 招聘人员、优先级、服务目标和人才寻访计划
- 03
候选人评估
- 所有者
- 招聘人员 + 招聘经理
- 决定
- 谁进步了，为什么？
- 信号
- 资格证据、结案原因和下一步行动
- 04
采访
- 所有者
- 面试协调员
- 决定
- 面板完整吗？
- 信号
- 时间表、记分卡、逾期反馈和建议
- 05
录用和清仓
- 所有者
- 招聘者 + 审批者
- 决定
- 释放、接受并移交？
- 信号
- 批准、录用响应、开始日期和关闭角色原因
为每个参与者提供与其自己的决定相匹配的观点
当每个人都看到相同的长桌子但没有人看到集中的队列时，招募就会失败。
招聘经理
- 开头为
- 等待评估或最终决定的候选人
- 作用于
- 标准、小组选择和决策证据
- 放手
- 批准面试或录取决定
采访者
- 开头为
- 预定的面试和计分卡到期
- 作用于
- 结构化证据和建议
- 放手
- 决策会议前已完成反馈
招募领队
- 开头为
- 开放需求、老化、工作量和瓶颈
- 作用于
- 容量、优先级和升级
- 放手
- 企业领导层的决策
单独的需求、流量、质量和结果衡量
招聘仪表板应该揭示工作受阻的地方，而不是将每个问题都归结为招聘时间。
批准的空缺覆盖范围
指定招聘人员的空缺职位和人才寻访计划批准的空缺职位
在候选人延迟开始之前重新平衡责任归属阶段老化
超越阶段服务目标的应用在该阶段开放申请
打开停滞的记录并解决所有者或决定面板完成
包含所有记分卡的面试小组反馈截止日期已过的小组
在汇报之前升级缺失的证据满足需求
已接受开始队列中批准的空缺职位
评估剩余的角色和来源差距构建招聘团队可以吸收的三个版本的系统
每个版本都应以可用记录和管理决策结束，而不是更长的配置积压。
- 发布 1
控制开放需求
- 批准招聘需求
- 指定招聘人员和目标日期
- 发布开放角色视图
- 发布 2
控制候选人移动
- 定义阶段进入和退出
- 捕获结案原因和下一步行动
- 添加面试记分卡
- 发布 3
管理结果
- 添加录用决策
- 构建延迟和工作负载仪表板
- 评估来源和角色结果
保持招聘操作的互联，同时专业工具完成专业工作
招聘管理系统可以协调招聘，同时人才寻访、评估、背景调查或聘后人力资源保留在为这些工作构建的产品中。
可配置的招聘需求、路由、记分卡和仪表板
Jodoo 处理什么
围绕您的实际招聘政策构建运营层。
当其他产品可能更适合时
比较套件配置和服务依赖性。
内置人才寻访网络和简历情报
Jodoo 处理什么
仅在连接被证明的情况下进行集成。
当其他产品可能更适合时
保留专用人才寻访或 ATS 产品。
入职、工资单和员工主数据
Jodoo 处理什么
将接受的员工移交给单独的人力资源流程。
当其他产品可能更适合时
聘用后保持 HRIS 的权威。
定义系统边界的问题
招聘管理系统与 ATS 有何不同？
ATS 以申请人记录和招聘阶段为中心。招聘管理系统还协调角色需求、招聘人员能力、招聘团队工作、面试完成、录用和管理报告。
Jodoo 可以在不更换 HRIS 的情况下管理招聘吗？
是的。 Jodoo可以管理聘用前的操作流程，并通过定义的交接将已接受的聘用记录传递给权威的人力资源系统。
首先应该实施什么？
从批准的招聘需求和候选人责任归属开始。在一致使用这些源记录后添加面试、录用和投资组合衡量标准。
招聘团队可以改变流程本身吗？
经过培训的 Jodoo 管理员可以直观地更改字段、角色视图、流程条件、提醒和仪表板，然后使用复制的记录测试更改。
跑通一个完整招聘周期
使用招聘管理系统从已批准需求一直验证到候选人接受录用
使用有代表性的职位和候选人完成每次交接，并从延误、工作量和招聘结果指标下钻查看对应记录。