您的招聘与人才获取数据模板
您的招聘与人才获取数据模板
- 建议收集的属性
- 流程分析中需追踪的关键活动
- 适用于您 iCIMS 系统的提取指南
招聘与人才获取属性
| 名称 | 描述 | ||
|---|---|---|---|
|
活动名称
ActivityName
|
招聘流程中发生的特定步骤或里程碑的名称。 | ||
|
描述
活动名称描述了在职位申请过程中的特定时间点发生的事件。例如“收到申请”、“完成初试”和“发出 Offer”。这些活动构成了招聘流程的各个环节。 此属性是 Process Mining 的基础,因为它定义了流程图中的节点。通过分析这些活动的顺序和频率,可以揭示真实的招聘工作流,发现常用路径和备选路径,并识别瓶颈或重复执行的环节。
为何重要
此属性定义了流程的步骤,从而可以构建流程图、分析流向并识别偏离标准招聘程序的情况。
获取方式
通常源自 iCIMS 招聘工作流概况中的状态变更。具体的各种状态和分类通常可由企业自定义。
示例
申请已筛选初面已进行已接受 Offer候选人已入职
|
|||
|
活动开始时间
ActivityStartTime
|
指示特定招聘活动开始或被记录的时间戳。 | ||
|
描述
此属性提供每个活动的日期和时间,例如筛选申请或安排面试的时间。时间戳对于理解流程步骤的时机和持续时长至关重要。 在 Process Mining 中,此时间戳用于按时间顺序排列事件,从而发现真实的流程流向。它是所有基于时间的分析的基础,包括计算活动间的周期时长、识别延迟以及根据服务水平协议 (SLA) 监控绩效。
为何重要
它按时间顺序排列事件,这对于计算流程时长、识别瓶颈以及掌握招聘流程的时间轴至关重要。
获取方式
此信息通常可以在 iCIMS 中与招聘工作流概况关联的审计轨迹或历史日志中找到。
示例
2023-10-26T10:00:00Z2023-11-05T14:30:00Z2023-11-15T09:15:00Z
|
|||
|
职位申请
JobApplicationId
|
候选人申请特定职位时的唯一标识符。 | ||
|
描述
职位申请 ID 是招聘流程分析的基石,充当了 case 标识符。每个 ID 代表一名候选人在特定职位空缺下的历程,从最初提交申请到随后的筛选、面试和 Offer 管理等所有阶段。 在 Process Mining 中,该属性用于将所有相关活动链接在一起,形成一个完整的端到端流程。基于职位申请 ID 分析流程,可以清晰地呈现招聘漏斗,准确计算周期时间,并识别不同候选人招聘路径中的差异。
为何重要
这是追踪单次申请全生命周期的关键,支持分析每位候选人的入职时长、流失率以及流程合规性。
获取方式
这通常是 iCIMS 中申请记录的主键。请查阅个人 (Person) 或招聘工作流概况 (Recruiting Workflow Profile) API。
示例
APP-2023-001234APP-2023-005678APP-2024-009101
|
|||
|
Recruiter
Recruiter
|
负责管理该职位申请的招聘官姓名或 ID。 | ||
|
描述
此属性标识了分配给该申请的主招聘官。此人通常负责筛选候选人、协调面试和管理流程。 按招聘官分析数据对于“招聘官绩效总览”仪表板至关重要。通过追踪筛选时长、面试完成率和成功入职人数等指标,有助于评估个人和团队绩效,从而识别最佳实践和需要额外培训的领域。
为何重要
此属性是评估招聘官工作量和绩效的关键,有助于进行针对性的改进和资源分配。
获取方式
此信息通常存储在 iCIMS 的招聘工作流概况或关联的职位概况中,并链接到执行特定操作的用户。
示例
约翰·史密斯Jane DoeEmily Jones
|
|||
|
应用源
ApplicationSource
|
候选人提交申请的渠道或方式。 | ||
|
描述
此属性指示申请的来源,例如“公司官网”、“LinkedIn”、“员工推荐”或“招聘网站”。它追踪候选人是如何获知并申请空缺职位的。 此信息对于“申请渠道 ROI”仪表板至关重要。通过分析各渠道的申请量以及(更重要的)入职人数,企业可以确定哪些渠道的投资回报率最高。这有助于优化招聘营销支出,并将精力集中在最有效的来源上。
为何重要
它有助于衡量不同招聘渠道的效果,从而优化人才搜寻策略和预算分配。
获取方式
此数据在 iCIMS 的候选人申请概况中捕获,通常由候选人选择或通过 URL 参数追踪。
示例
LinkedIn员工推荐公司招聘页面Indeed
|
|||
|
招聘经理
HiringManager
|
该职位申请对应的招聘经理姓名或 ID。 | ||
|
描述
招聘经理是该职位所属部门的负责人。他们是流程中的关键利益相关者,负责审查候选人、进行面试并做出最终录用决策。 此属性对于“招聘经理反馈周期”仪表板至关重要。通过追踪每位招聘经理在面试与提交反馈之间的时间,企业可以识别决策过程中的延迟并努力缩短这一时间,从而加速整体招聘进度。
为何重要
它有助于分析招聘经理的参与度和效率,尤其是反馈的及时性,这是导致招聘延误的常见原因。
获取方式
通常存储在 iCIMS 中与该职位申请关联的职位概况 (Job Profile) 上。
示例
Robert BrownSusan WhiteMichael Green
|
|||
|
招聘需求ID
JobRequisitionId
|
该职位空缺或岗位的唯一标识符。 | ||
|
描述
职位申请 ID (Job Requisition ID) 将多个申请链接到同一个职位发布。它代表了候选人申请的具体角色,包含职位名称、部门和地点等详细信息。 在分析中,此 ID 用于对同一职位的所有申请进行分组和比较。它让您能够查看单个职位的整个候选人才库,有助于了解不同类型职位的招聘效率。
为何重要
它可以将同一职位的申请进行归类,从而分析特定职位的整个招聘漏斗。
获取方式
此 ID 是 iCIMS 中职位概况 (Job Profile) 的基础部分,并链接到为该角色提交的每一份申请。
示例
REQ-2023-105REQ-2024-012REQ-2024-301
|
|||
|
申请状态
ApplicationStatus
|
职位申请的最终结果或当前处理状态。 | ||
|
描述
此属性代表申请的最终状态,指示候选人是被录用、被公司拒绝还是撤回了申请。它为招聘流程提供了结束事件。 这是基于结果进行分析的关键属性。它用于计算转化率、Offer 接受率和流失率。了解申请的最终处理结果是衡量整个招聘漏斗成功与否及效率高低的基础。
为何重要
它定义了流程的结果,这对于计算录用率和拒绝率等关键指标至关重要。
获取方式
这是 iCIMS 招聘工作流概况中的最终状态。通常在申请被移入最终“处理”分类时设置。
示例
已录用被公司拒绝候选人撤回申请
|
|||
|
部门
Department
|
招聘该职位的业务部门或职能部门。 | ||
|
描述
此属性指定了空缺职位所属的部门(如“工程部”、“市场部”或“销售部”),为职位申请提供组织背景。 部门信息是一个强大的分析维度。它支持按部门细分“入职时长”和“Offer 接受率”等 KPI,从而揭示全公司范围内招聘流程和效率的显著差异。这有助于识别哪些部门拥有优化流程,哪些部门可能需要支持。
为何重要
它允许在不同业务部门之间进行绩效比较,突出招聘效率的差异和瓶颈。
获取方式
这通常是 iCIMS 中与职位申请 ID (Job Requisition ID) 关联的职位概况信息的一部分,也可能链接到组织结构数据。
示例
工程部销售市场营销人力资源
|
|||
|
候选人ID
CandidateId
|
单个候选人在其所有申请中的唯一标识符。 | ||
|
描述
候选人 ID 是人才池中个人的唯一标识符,与职位申请 ID 不同。一位候选人可以有多次申请,但他们的候选人 ID 始终相同。 该属性对于“重复筛选检测”分析特别有用。通过按候选人 ID 对活动进行分组,可以识别同一人员被不必要地多次筛选不同职位的情况。它还能让您更全面地了解候选人与公司的互动历史。
为何重要
它能唯一识别一个人,从而分析候选人在多次申请中的历程,并检测是否存在重复活动。
获取方式
这是 iCIMS 中个人概况 (Person Profile) 的主要标识符。
示例
CAND-9876CAND-5432CAND-1001
|
|||
|
最后数据更新
LastDataUpdate
|
指示数据上次从源系统提取或刷新的时间戳。 | ||
|
描述
此属性记录了最近一次从 iCIMS 提取数据的日期和时间。它反映的不是事件发生的时间,而是记录最后一次与 Process Mining 工具同步的时间。 此信息对于了解所分析数据的时效性至关重要。它让用户知道他们看到的是实时信息还是特定时间点的快照,这对分析的相关性和准确性非常重要。
为何重要
它会提示用户数据的及时性,确保分析和决策都基于最新信息。
获取方式
该时间戳应由数据提取、转换和加载 (ETL) 流水线在每次运行时生成并记录。
示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
国家/地区
Country
|
职位所在国家。 | ||
|
描述
此属性指定与职位申请关联的国家。它为招聘流程提供了地理背景。 对于全球性组织,按国家分析招聘流程至关重要。它能突出招聘时间轴、渠道有效性和流程合规性方面的地区差异。这种分析有助于制定针对特定地点的招聘策略,并设定切合实际的区域绩效目标。
为何重要
它能够对招聘流程进行地域细分,揭示区域绩效差异,并支持全球流程标准化工作。
获取方式
这是 iCIMS 职位概况中地点信息的一部分。
示例
美国德国英国加拿大
|
|||
|
工作地点
JobLocation
|
该职位空缺所属的具体城市或办事处地点。 | ||
|
描述
工作地点提供了比国家更细致的地理信息,通常指城市、州或具体的办事处。 此属性支持更详细的区域分析。例如,可以跨不同城市比较“入职时长”,以了解当地市场状况和招聘挑战,这也有助于区域招聘团队的资源规划。
为何重要
它提供细分到地理位置的洞察,帮助分析不同办事处或城市之间的绩效差异。
获取方式
这存储在 iCIMS 职位概况的地点字段中。
示例
美国纽约加州旧金山英国伦敦
|
|||
|
总周期时间
CycleTime
|
职位申请从第一个活动到最后一个活动所经过的总时长。 | ||
|
描述
Cycle Time(循环耗时)衡量单个申请从开始到结束的招聘流程总时长。计算方法是第一个事件(如“收到申请”)的时间戳与最后一个事件(如“候选人已入职”或“申请被拒绝”)的时间戳之差。 这是衡量整体流程效率的主要 KPI。它被用于“招聘周期绩效”仪表板,以跟踪填补职位空缺所需的时间。分析 Cycle Time 有助于识别耗时较长的流程,并为流程改进计划设定基准。
为何重要
这一计算得出的指标是衡量整体流程效率的关键绩效指标,对于追踪入职时长的仪表板至关重要。
获取方式
此属性在 iCIMS 中无法直接获取。它是在 Process Mining 工具中通过计算每个 JobApplicationId 的最大和最小 ActivityStartTime 之差来得出的。
示例
45 天 10 小时62 天 4 小时30 天 0 小时
|
|||
|
拒绝原因
RejectionReason
|
公司拒绝候选人申请的原因。 | ||
|
描述
当申请被拒绝时,此属性提供具体原因,例如“不符合企业文化”、“缺乏所需技能”或“职位已由其他候选人填补”。这些数据通常由招聘官或招聘经理从预定义的列表中选择。 分析拒绝原因可为招聘流程提供宝贵的反馈。它可以突出显示诸如职位描述不匹配、某些渠道的候选人质量问题或筛选流程有待改进的环节。这有助于完善招聘策略并提高候选人才储备的质量。
为何重要
它能提供关于候选人未被录用原因的关键反馈,有助于完善职位描述、搜寻渠道和筛选标准。
获取方式
这通常在 iCIMS 招聘工作流中将候选人移至拒绝状态时记录。
示例
不符合最低资历要求薪资预期过高已选择更合适的候选人
|
|||
|
是否返工
IsRework
|
标识同一职位申请是否正在重复执行某项活动的标记。 | ||
|
描述
“Is Rework”属性是一个布尔标记,如果特定活动在同一个 case 中发生多次,则设置为 true。例如,如果候选人必须经历两次“初试”阶段,则第二次将被标记为 rework(重复劳动)。 这是“流程合规性与变体”分析中的一个强大属性。它能迅速揭示低效、冗余以及偏离标准流程的情况。识别并量化重复劳动有助于简化流程、减少无用功并改善候选人体验。
为何重要
它通过识别重复步骤来量化流程中的低效环节,这些重复步骤通常预示着问题或非标准流程。
获取方式
此属性是在 Process Mining 工具中通过检查给定的 JobApplicationId 是否已发生过同名活动来计算的。
示例
truefalse
|
|||
|
活动处理时间
ProcessingTime
|
主动处理单个招聘活动所花费的时间。 | ||
|
描述
执行时间是指特定活动的持续时长,计算方式为结束时间与开始时间之差。对于许多招聘事件,此数值可能为零或极短。但对于“进行面试”等任务,它代表了在该任务上花费的实际时间。 此指标有助于区分活动工作时间和等待时间。虽然“安排面试”与“完成面试”之间的时间可能很长(等待时间),但面试本身的执行时间要短得多。分析执行时间有助于优化单个任务的执行。
为何重要
它能测量活动的实际持续时间,帮助区分实际工作时间和空闲时间,并识别出执行起来最耗时的任务。
获取方式
这是在 Process Mining 工具中通过计算每个事件的 ActivityEndTime 减去 ActivityStartTime 得出的。
示例
1 小时 0 分钟0 小时 30 分钟0 小时 5 分钟
|
|||
|
活动结束时间
ActivityEndTime
|
指示招聘活动完成的时间戳。 | ||
|
描述
活动结束时间标志着一个事件的终结。在许多情况下,尤其是对于“发出 Offer”等离散事件,结束时间可能与开始时间相同。但对于有持续时间的活动(如面试环节),两者则会有所不同。 此属性用于计算单个活动的精确持续时长(即执行时间)。分析执行时间有助于识别哪些具体任务最耗时,而不仅仅是查看任务之间的等待时间。
为何重要
它能够计算某项活动的执行时间,有助于区分实际工作时间和空闲等待时间。
获取方式
与开始时间类似,这可以在 iCIMS 的审计轨迹或历史日志中找到。如果只有一个事件时间戳可用,则可能需要进行推断。
示例
2023-10-26T10:05:00Z2023-11-05T15:30:00Z2023-11-15T09:15:00Z
|
|||
|
源系统
SourceSystem
|
数据来源系统,在本案例中为 iCIMS。 | ||
|
描述
此属性标识了生成并存储招聘数据的源应用程序。对于此流程,该值始终为“iCIMS”或 iCIMS 实例的更具体标识符。 虽然在单系统分析中它看起来是静态的,但在合并多个系统的数据时(例如将 iCIMS 的招聘数据与另一个系统的 HRIS 数据结合),它就变得至关重要。它能确保数据血缘并有助于解决数据集成问题。
为何重要
它提供了数据来源的上下文信息,这对于数据治理以及集成多个 HR 系统的数据至关重要。
获取方式
这是一个静态值(“iCIMS”),应在数据提取和转换过程中添加。
示例
iCIMS Talent CloudiCIMS
|
|||
|
职位名称
JobTitle
|
候选人申请的职位名称。 | ||
|
描述
职位名称是空缺角色的正式名称,如“软件工程师”或“产品经理”。它提供了除部门或职系之外的职位具体细节。 此属性是过滤和细分招聘数据的常用维度。例如,按职位名称分析“入职时长”可能会发现某些角色(尤其是高级或专业职位)需要更长的时间才能填补。这一洞察有助于为不同类型的职位制定量身定制的招聘策略。
为何重要
它能够对特定职位进行详细分析和绩效比较,这些职位可能面临独特的招聘挑战和时间线。
获取方式
这是 iCIMS 职位概况 (Job Profile) 中的一个主要字段。
示例
高级软件工程师市场经理数据分析师
|
|||
|
薪资待遇
OfferAmount
|
职位 Offer 中给予候选人的薪资或薪酬总额。 | ||
|
描述
此属性包含向候选人提供的薪酬方案的货币价值。通常在“发出 Offer”活动发生时记录。 这些数据对于“Offer 接受率趋势”仪表板非常有价值。通过分析接受率与 Offer 金额的关系,并按职位名称或部门等因素进行细分,企业可以深入了解其薪酬竞争力。这有助于识别 Offer 是否因薪酬原因被拒绝,并为调整薪酬等级提供参考。
为何重要
它为分析 Offer 接受率以及理解薪酬对招聘成功率的影响提供了关键背景。
获取方式
此信息通常存储在 iCIMS 招聘工作流概况 (Recruiting Workflow Profile) 的“Offer”选项卡或相关字段中。
示例
8500012000095500.50
|
|||
招聘与人才获取活动
| 活动 | 描述 | ||
|---|---|---|---|
|
候选人已入职
|
代表招聘流程成功的最终活动。当候选人进入最终的“已录用”状态时,系统会记录此事件,正式结束申请流程并通常会触发入职工作流。 | ||
|
为何重要
这是流程的主要成功终点。它对于计算整体招聘周期时长和招聘漏斗转化率至关重要。
获取方式
根据申请工作流中最终状态更改为“已入职 (Hired)”或“已入职 (Started)”的时间戳来推断。这是一个终点状态。
捕获
捕获状态更改为最终“已入职 (Hired)”状态的时间戳。
事件类型
inferred
|
|||
|
候选人已提交至招聘经理
|
招聘人员正式将合格候选人的档案提交给招聘经理进行审核。这通常在招聘人员将候选人移动到 iCIMS 工作流中特定的“招聘经理审核 (Hiring Manager Review)”步骤时捕获。 | ||
|
为何重要
这是一个关键的交接点。测量从该步骤到经理反馈的时间,是识别招聘经理环节延迟的关键。
获取方式
根据申请状态更改为“已提交至招聘经理”、“招聘经理审核”或表示经理参与的类似状态时的时间戳来推断。
捕获
捕获状态更改为“招聘经理审核 (Hiring Manager Review)”或等效状态的时间戳。
事件类型
inferred
|
|||
|
初面已进行
|
此活动表示已完成与候选人的第一轮面试。通常在面试结束后,由招聘官或招聘经理更新候选人状态时记录。 | ||
|
为何重要
这是评估过程中的一个重要里程碑。该事件与反馈提交之间的时间对于“招聘经理反馈周期”分析至关重要。
获取方式
根据申请工作流中的状态更新(如“面试已完成”、“等待反馈”或“初面已完成”)来推断。
捕获
在预定面试日期后,检测状态是否更改为“面试完成 (Interview Complete)”或相关状态。
事件类型
inferred
|
|||
|
已发出 Offer
|
已创建正式录用通知并向候选人发放。这是一个关键里程碑,通常通过将申请状态更改为专门的“录用 (Offer)”阶段来捕获。 | ||
|
为何重要
此活动是“Offer 接受率”KPI 的分子。它标志着招聘流程最终决策阶段的开始。
获取方式
根据申请工作流中状态更改为“录用通知已发放 (Offer Extended)”、“录用通知已给出 (Offer Made)”或“口头录用 (Verbal Offer)”等状态来推断。
捕获
捕获状态更改为任何与“录用 (Offer)”相关状态的时间戳。
事件类型
inferred
|
|||
|
已接受 Offer
|
候选人已正式接受职位 Offer。这是一个关键的成功里程碑,在招聘官根据候选人的答复更新其状态时记录。 | ||
|
为何重要
此活动对于计算 Offer 接受率至关重要,并标志着向入职前检查和正式入职的过渡。
获取方式
根据申请工作流中带有时间戳的状态更改(如“录用通知已接受”或“待入职”)来推断。
捕获
识别状态更改为“录用通知已接受 (Offer Accepted)”的时间戳。
事件类型
inferred
|
|||
|
已收到申请
|
标志着特定职位申请招聘流程的开始。当候选人通过门户网站成功提交申请或手动录入 iCIMS 时,系统会记录此事件。 | ||
|
为何重要
这是流程的主要开始事件。分析从该活动到后续里程碑的时间,对于了解整体补缺时长以及识别前端瓶颈至关重要。
获取方式
通常根据申请记录的创建日期,或候选人工作流历史中与“已提交”或“新申请”等初始状态关联的时间戳推断得出。
捕获
使用职位申请记录的创建时间戳或第一次状态变更的时间戳。
事件类型
inferred
|
|||
|
申请被公司拒绝
|
公司已决定在流程的某个阶段不再继续考虑该候选人。这是由招聘官或招聘经理将申请状态更新为最终的“已拒绝”或“未入选”状态来捕获的。 | ||
|
为何重要
这是最常见的终点。分析大多数拒绝发生在哪个阶段,是了解招聘漏斗有效性并识别瓶颈的基础。
获取方式
根据状态更改为终点拒绝状态(如“已拒绝”、“未选中”或“职位已填补”)来推断。iCIMS 通常要求提供处理原因。
捕获
检测状态是否更改为任何“未入职”且“未撤回”的终点状态。
事件类型
inferred
|
|||
|
Offer 被拒绝
|
候选人已正式拒绝职位 Offer。这是一个不成功的结果,在招聘官将候选人状态更新为“Offer 已回绝”或“Offer 被拒绝”时捕获。 | ||
|
为何重要
这是一个主要的失败终点。分析 Offer 被拒绝的时间和原因,可以深入了解薪酬竞争力和候选人体验。
获取方式
根据申请工作流中状态更改为终点状态(如“录用通知已拒绝 (Offer Rejected)”或“录用通知已谢绝 (Offer Declined)”)来推断。
捕获
识别状态更改为“录用通知已拒绝 (Offer Rejected)”或等效状态的时间戳。
事件类型
inferred
|
|||
|
候选人已电面
|
表示招聘人员已对候选人进行了初步电话面试。此事件通常在通话完成后,招聘人员更新工作流中的候选人状态时捕获。 | ||
|
为何重要
这是招聘漏斗中的关键筛选阶段。分析其持续时间和转化率有助于评估初始筛选和渠道搜寻的质量。
获取方式
根据候选人工作流中状态更改为“电话面试已完成 (Phone Screen Completed)”、“进入下一步”或类似的自定义状态来推断。
捕获
在申请工作流中,检测状态是否更改为“电话面试 (Phone Screen)”或类似的已配置状态。
事件类型
inferred
|
|||
|
候选人撤回申请
|
候选人自愿退出该职位的考虑。这在候选人通知招聘官后记录,随后招聘官将申请状态更新为“已撤回”。 | ||
|
为何重要
这是一个关键的失败终点。某些阶段的高撤回率可能预示着流程过于冗长、沟通不畅或候选人体验不佳。
获取方式
根据 iCIMS 工作流中带有时间戳的状态更改(如“候选人已撤回”、“已撤回”或类似的终点状态)来推断。
捕获
捕获状态更改为“撤回 (Withdrawn)”或等效状态的时间戳。
事件类型
inferred
|
|||
|
初面已安排
|
代表已安排候选人与招聘团队进行面试。iCIMS 具备日程安排功能,当创建面试事件并将其与申请关联时,系统会记录此点。 | ||
|
为何重要
标志着从筛选到正式评估的过渡。追踪此项有助于分析安排面试的效率以及接触合格候选人所需的时间。
获取方式
可以是来自 iCIMS 面试安排模块的显式事件,也可以根据状态更改为“面试已安排 (Interview Scheduled)”或类似状态来推断。
捕获
使用面试记录的创建日期或状态变更为“面试中”的时间戳。
事件类型
inferred
|
|||
|
已发起背景调查
|
代表 Offer 被接受后入职前筛选流程的开始。通常通过将候选人移动到“背景调查”状态来追踪,这可能会触发与第三方供应商的集成。 | ||
|
为何重要
分析从“录用通知已接受”到此活动的时间,有助于识别入职前流程中的延迟,这些延迟会影响候选人的入职日期。
获取方式
根据状态更改为“背景调查进行中 (Background Check in Progress)”或类似状态来推断。某些 iCIMS 集成可能会将其记录为显式事件。
捕获
检测状态是否更改为“背景调查 (Background Check)”状态。
事件类型
inferred
|
|||
|
已提交反馈
|
当招聘团队成员(通常是招聘经理)在面试后提交评估时发生。iCIMS 支持结构化反馈采集,此事件可根据反馈记录的创建时间推断得出。 | ||
|
为何重要
对于衡量“招聘经理平均反馈时长”这一 KPI 至关重要。反馈提交的延迟是减慢整个招聘流程的常见瓶颈。
获取方式
根据与申请关联的面试反馈记录的创建时间戳来推断。也可能是特定的状态更改,如“已收到反馈”。
捕获
使用系统中面试反馈条目的创建时间戳。
事件类型
inferred
|
|||
|
申请已筛选
|
代表招聘官完成了对申请的初步审查。当申请状态从“新建”更改为表示正在审查的状态(如“正在审查”或“筛选中”)时,通常会推断出此活动。 | ||
|
为何重要
追踪此活动有助于衡量招聘官效率和“筛选时长”KPI。此环节的延误会导致候选人流失并延长整体招聘进度。
获取方式
根据申请档案中的状态变更来推断。查看从初始状态更改为“已查看 (Reviewed)”、“已筛选 (Screened)”或“正在考虑”等状态。
捕获
识别状态更改为“已查看 (reviewed)”或“已筛选 (screened)”状态的时间戳。
事件类型
inferred
|
|||
|
第二次面试已安排
|
表示候选人已通过初选,正在安排后续面试。这在安排新的面试事件或候选人被移动到“第二次面试 (Second Interview)”阶段时捕获。 | ||
|
为何重要
分析第二次面试的频率和准备时间,有助于了解流程深度,并识别某些职位是否需要过多的面试轮次。
获取方式
根据状态更改为“第二次面试已安排 (Second Interview Scheduled)”或为已面试过的候选人创建新面试记录来推断。
捕获
识别同一申请的状态变更或新面试记录的创建。
事件类型
inferred
|
|||