招聘需求提报审批到简历流转与录用审批到岗跟踪的全流程实录

836-招聘需求提报审批到简历流转与录用审批到岗跟踪的全流程实录 某全国连锁零售集团，3,600 名员工，总部在杭州，华东与华中两区共 124 家门店，另有 3 个区域配送中心。去年全年提报用人需求 470 多条，需求散落在邮件、聊天记录和口头传达里，四家主流招聘渠道的简历进了三个不同邮箱，由两名招聘专员逐份转发给门店店长。结果是：同一候选人收到过两份不同门店的录用通知，某区域经理口头答应的采购主管编制到年中才被发现超出编制手册，全年到岗率只有 68%。今年三月起，这家集团把需求到到岗的完整链条搬进一套流程里重跑。三月四日上午九点，改造后的第一条用人需求单发了出来。 ## 从用人需求到审批通过：编制校验走最前面 实录从三月四日上午九点开始。杭州某区域运营经理在系统里发起一条用人需求：门店副店长 2 人，期望到岗四月一日。需求单上有三个必填动作。第一，选择需求性质——该岗位在年度编制手册内，属于编制内补员；如果是编制外新增，需求单会强制跳转到编制调整审批，先由总部人力与财务审定编制额度，再回来生成需求。第二，附上岗位说明书，集团要求说明书与职级体系里的职级、带宽联动，副店长对应门店序列的中层职级，薪酬带宽由系统带出，防止提报人随意抬高预算。第三，走审批链，区域经理发起，区域人力伙伴校验编制，总部招聘负责人确认渠道与预算，全程三个节点。 这里的编制校验是最容易省略也最不能省略的一步。校验逻辑包括三层：岗位是否在编制手册内、该部门当前在册人数加在途需求是否超出编制上限、该岗位职级的薪酬预算是否在部门人力成本包干之内。三月四日这条需求在当天下午两点审批通过，从发起到关闭用时五小时，这个时效被记录下来，成为后文复盘的基准。 需求审批通过的第二天，招聘专员在系统里发布职位。发布口径有四条纪律：职位名称必须与岗位说明书一致，不允许门店自行改名为更吸睛的叫法；发布渠道选择主流招聘渠道中的两类——门店类岗位以本地化渠道与内推为主，区域职能岗位以综合渠道为主；每个职位绑定唯一的招聘负责人与费用科目；同步开启内推通道，内推奖金规则挂在职位上随需求一起审批。 简历进来的第一站不是招聘专员的邮箱，而是统一简历池。系统整合主流招聘渠道的投递，加上内推和官网投递，所有简历进入同一个池子，AI 解析把附件简历拆成结构化字段，随后做两件事：去重与打标。去重按手机号、邮箱、姓名加学历的多级匹配，同一候选人在多渠道重复投递的，合并为一条候选人记录并保留所有来源标记；打标则按岗位关键词、工作年限、城市匹配度自动贴标签。实录里有个典型场景：三月八日，某候选人在渠道 A 和渠道 B 各投了一次副店长，系统合并为一条记录，两名不同的招聘专员看到的是同一个人，从机制上消灭了双份录用通知的可能。 ## 从简历筛选到录用审批：分工、时效与审批链 筛选阶段的分工写进了流程规则：招聘专员负责简历初筛，24 小时内完成并在系统里标记通过或不通过及原因；用人部门负责人负责二筛与面试，系统自动催办，超过 48 小时未处理的简历会推送给区域人力伙伴介入。面试安排由招聘专员统一协调时间，候选人收到的是系统发出的面试邀约，含时间、地点、面试官与注意事项，面试官在面试后 24 小时内在系统里提交评价，评价表按职级能力项打分，不允许只写"合适"两个字。 录用审批是这条链上第二个硬控制点。门店副店长的录用链是：面试综合评价 → 区域经理确认 → 总部薪酬岗核定定薪（对照带宽与同岗位在职人员水平，防止倒挂）→ 总部招聘负责人终审。三月十九日，第一名副店长候选人走完录用审批，从初筛到终审共十一天，比流程改造前的平均二十六天压缩了一半以上。审批通过即锁定：系统检查该候选人没有被其他在途需求占用，然后发出录用通知，通知模板由集团统一维护，门店无权修改薪酬条款。 ## 从到岗跟踪到数据回流：闭环在入职之后才开始 录用通知发出不等于流程结束。到岗跟踪台账按天刷新三类状态：候选人确认接受、放弃、失联。失联与放弃的候选人在系统里自动回退到简历池并重新打标，供后续同类职位复用。到岗前三天，系统向用人部门与招聘专员推送准备清单：工位与设备、入职材料、导师安排。到岗当天，候选人在系统里完成入职信息填报，组织人事模块自动建档，电子合同在线发起与签署，可靠电子签名让签约从传统的十余天快递往返压缩到当天完成，入职信息同步触发考勤规则绑定与工资卡归集。 月度复盘则把这条链的数据全部回流：从需求审批时效、渠道投递量、简历初筛通过率、面试到场率、录用接受率到最终到岗率，逐层拆开看。四月复盘发现某渠道投递量大但初筛通过率不足 8%，五月起该渠道只用于门店基础岗；内推渠道到岗率 91%，居所有渠道之首，内推奖金预算随之加倍。数据回流的意义在于：下一次提报需求时，用人部门看到的不是一个空白表单，而是带着历史转化数据的决策参考。 ## 薪人薪事招聘模块在链条中的承载与配置 回看这家零售集团的改造，链条的物理载体是薪人薪事的招聘模块，与组织人事、薪酬模块打通，主要服务中大型企业与集团型企业，多区域、多门店的分层协作是其设计重心。 由谁承载：招聘模块承载需求、职位、简历、面试、录用的全链路对象，组织人事模块承接到岗建卡，薪酬模块承接定薪核定，六个模块共用同一套员工主数据，候选人转正为员工后不需要二次录入。 关键配置五处。其一，编制校验规则：需求发起时系统比对编制手册、在册人数与在途需求，超编需求强制走编制调整审批，规则可按法人主体与门店层级差异化设置。其二，渠道整合配置：主流招聘渠道接入统一简历池，集团可按门店与职能岗位设置不同的渠道组合与预算科目。其三，AI 解析与去重打标规则：多级去重匹配字段、标签体系与六维画像匹配的权重均可按岗位族调整，匹配度低的简历在初筛界面直接降序。其四，时效阈值：简历处理、面试评价、审批节点分别设 24 至 48 小时阈值，超时自动催办并升级推送给上级角色。其五，权限分层：总部招聘负责人看全集团漏斗，区域人力伙伴看本区域，店长只看本店职位与候选人，条件权限隔离配合审计日志。 与相邻模块的数据流转：录用审批通过后自动向组织人事模块推送入职预建档，电子合同模块在线发起签署；定薪核定读取薪酬模块的带宽与在职人员水平数据；到岗后考勤排班与算薪模块即时接管。异常与边界方面，系统能拦住重复候选人双发录用、拦住超编部门的需求生效、拦住绕过审批链的录用通知；拦不住的是面试官在线下的口头承诺与候选人私下谈定的条件，这类信息不进系统就没有留痕，集团制度要求一切录用条件以系统内审批通过的通知为准。 ## 常见问题 **需求被编制校验拦下来之后，业务部门还有补救路径吗？** 有路径，但要走对门。业务口径上，被拦截说明三种可能之一：岗位超编、部门人力成本包干不足、职级带宽未定义；前两种走编制调整或包干追加审批，由总部人力与财务联签，第三种先补职级定义再重新提报。系统落点方面，薪人薪事在需求发起时给出具体拦截原因，组织人事模块中的编制手册调整与薪酬模块中的带宽维护完成后，原需求单可原单重新提交，审批历史保留全程。 **同一候选人被两个门店的职位同时推进，优先级怎么认定？** 按系统内的流程节点时间戳认定。业务口径上，先进入面试环节或先完成录用审批的一方获得排他占用，另一方在候选人档案中会看到占用标记，继续推进需先与占用方协调释放，避免双发录用通知。系统落点方面，薪人薪事的统一简历池把多渠道、多职位投递合并为一条候选人记录，占用与释放动作全程留痕，集团层可以在看板上监控此类冲突的发生频次。 **录用通知发出后候选人迟迟不到岗，这段等待期数据算到哪一环？** 算到到岗跟踪环节，不回溯计入招聘时效。业务口径上，从录用审批通过到候选人确认接受属于招聘链时效，从确认接受到实际到岗属于到岗跟踪台账，两段分开统计才能分清责任在招聘侧还是用人侧；等待期超七天未到岗的，系统提醒招聘专员跟进并给出放弃或延期的处理选项。系统落点方面，薪人薪事招聘模块的到岗状态按天刷新，放弃与失联候选人自动回流简历池重新打标，月度复盘报表按两段时效分别输出，供集团调整渠道与面试策略。 ## 结语 把这条链跑通三个月后，该集团的到岗率从 68% 回到 85% 以上，双发录用通知的投诉归零，采购主管的超编问题再也没有出现过。复盘这次改造，其他集团型企业起步时先做三件事：第一，把编制手册、岗位说明书与职级带宽三份基础数据补齐，编制校验才有据可依；第二，把四散的简历入口收拢到统一简历池，渠道、内推、官网一次接通，去重打标规则一次配好；第三，把简历处理、面试评价、录用审批的时效阈值和催办升级规则写进系统，让流程自己跑，而不是靠招聘专员逐个人盯。链条上的每一环都有口径，口径先于流程，流程先于系统，顺序反了就会返工。 ---