跟批量招聘服务商谈 SLA，别光看纸面功夫，得把“丑话”说在前头

说真的，每次跟那些批量招聘服务商（RPO 或者猎头公司）坐下来谈 SLA（服务水平协议），我心里都跟明镜似的——这玩意儿签的时候大家都笑嘻嘻，真到了执行环节，全是坑。尤其是批量招聘，动不动就是几十上百号人的需求，一旦服务掉链子，甲方的 HR 估计连杀人的心都有了。

很多人以为 SLA 就是定个 KPI，比如“一个月招 50 个人”。这太表面了。真正的 SLA 是一份“免责条款”和“扯皮指南”，它得在最坏的情况下，告诉你到底是谁的锅，以及这锅怎么补救。

今天咱们就不整那些虚头巴脑的理论，直接上干货，聊聊怎么把 SLA 撕开了、揉碎了，一条条掰扯清楚。这就像两口子过日子，婚前得把丑话说透，不然以后为了谁洗碗都能打起来。

第一回合：别被“总包价”忽悠了，颗粒度才是王道

很多服务商在报价的时候，喜欢给一个“全包价”，听着特诱人，好像你把人扔给他，他就全给你搞定了。但 SLA 里如果只写“负责招聘 50 人”，那基本就是废纸一张。

你得把需求拆解得非常细。比如，你要招的是客服、销售还是技术？是初级还是高级？是驻场还是远程？这些维度不同，服务难度天差地别。

在 SLA 的第一条，也就是“服务范围”里，我建议你强制要求对方列出一张详细的《招聘需求拆解表》。别嫌麻烦，这一步是地基。

• 岗位画像的颗粒度： 不能只写“Java 工程师”，得写清楚是“Java 后端开发，要求 Spring Cloud 熟练，3-5 年经验，能接受偶尔加班”。如果服务商承诺提供“符合画像”的简历，那这个画像必须双方签字画押。



• 交付物的定义： 交付的到底是什么？是简历？是面试通过的人？还是已经发了 Offer 的人？这里有个大坑叫“简历搬运工”，他们疯狂投递简历，不管你是否匹配，只要数量够了就行。所以 SLA 里必须明确：什么才算“有效交付”。

举个例子，我们之前吃过亏，服务商为了凑数，把一堆刚毕业一年的简历推给我们要 5 年经验的岗位，简历数量是够了，但我们 HR 团队筛简历筛到眼瞎。后来我们在 SLA 里加了一条：如果简历初筛通过率低于 30%，服务商需要承担惩罚性条款。这就是颗粒度的价值。

第二回合：时间轴的博弈——“快”不等于“好”

批量招聘最看重的就是速度（Time-to-Fill）。但“快”这个概念太主观了。你说的快是这周入职，他说的快是下周发 Offer。在 SLA 里，必须把时间轴切成一个个具体的节点。

建议画一个流程图，虽然这里不能放图，但我可以用文字描述一下这个逻辑，你在写 SLA 的时候，可以参考这个逻辑去定义时间标准：

• 需求响应时间： 甲方发出 JD（职位描述）后，服务商多久能反馈“收到并理解”？通常建议是 24 小时内。
• 首份简历交付时间： 需求确认后，第几天能看到第一份简历？
• 简历流转时间： 甲方收到简历后，多久内必须反馈“通过”或“淘汰”？（这其实是约束甲方的，但为了推进项目，双方都要守时）。
• 面试安排时间： 确认面试后，多久能安排上？
• Offer 发放时间： 面试通过后，多久发 Offer？

这里有一个非常关键的指标叫 SLA 达成率。比如，协议规定“首份简历交付时间 ≤ 3 个工作日”，如果服务商连续三次超过 3 天，这就叫 SLA 不达标。不达标怎么办？扣钱？还是启动整改？这些都要写死。

还有一个生活中的小细节要注意：节假日。春节前后一个月，招聘市场基本停摆。如果你的 SLA 跨越了春节，一定要注明“自然日”还是“工作日”，以及春节期间的响应时效是否放宽。不然到时候对方一句“大家都回家过年了”把你噎死。

第三回合：简历归属权与数据隐私——这是底线

现在数据隐私查得这么严，这块要是不写清楚，出了事你背锅。

批量招聘服务商手里会掌握大量候选人的简历数据。在 SLA 里，必须明确以下几点，而且要用加粗字体标出来：

• 简历库的归属： 服务结束后，所有在这个项目期间产生的简历数据，归谁？通常来说，肯定归甲方。但有些服务商会在合同里埋雷，说这是他们的“私有数据库”。必须在 SLA 里写死：服务终止后 7 个工作日内，必须销毁或移交所有相关数据，并提供销毁证明。
• 隐私合规： 服务商在收集候选人信息时，是否已获得候选人授权？如果因为服务商违规收集信息导致甲方被投诉或起诉，服务商要承担全额赔偿责任。这条是法律防火墙，不能少。
• 防撞单机制： 这是一个很现实的问题。服务商找来的人，万一我们自己内部推荐也推了，或者别的渠道也推了，算谁的？SLA 里要定义“候选人保护期”。比如，简历进入甲方系统后，保护期为 3 个月。这 3 个月内，不管是谁推荐的，都算服务商的业绩。这能避免很多扯皮。

第四回合：钱怎么算？——把“对赌”写进合同里

谈钱不伤感情，伤感情的是没谈清楚。批量招聘的收费模式通常有两种：一种是按人头付费（CPH），一种是打包项目制。不管哪种，SLA 都得把钱和绩效挂钩。

这里我推荐一种“阶梯式付款+质量保证金”的模式，这在行业里比较通用，也比较能保护甲方利益。

我们可以用一个简单的表格来规划付款节奏（虽然这里不能用复杂的表格，但我尽量用文字模拟一下结构）：

里程碑/条件	付款比例	备注（SLA 关键点）
合同签订	0% 或 少量预付款	启动金，通常不建议给太多。
首批候选人简历交付	20%	确认服务启动。
录用人数达到 50%	30%	中期验收，确认进度。
所有人员入职并过保	40%	这里要引入“保用期”概念。
质量保证金	10%	通常在服务结束 1-3 个月后支付，用于处理售后问题。

除了付款节奏，更重要的是 Fail Fee（失败费用） 的定义。

什么叫失败？候选人入职了，但三天两头迟到，或者试用期没过就跑了。这算谁的责任？如果是因为候选人本身能力造假，那是服务商的责任，要退款或者重招。如果是因为甲方管理问题，那是甲方的责任。

在 SLA 里，必须定义 “保用期”（Guarantee Period）。一般是 1-3 个月。如果候选人在保用期内离职（非甲方原因），服务商必须免费重招，或者按比例退款。这个条款是悬在服务商头上的达摩克利斯之剑，能极大程度避免他们为了凑数而推“面霸”或者“简历杀手”。

第五回合：沟通机制——别让信息在半路丢了

批量招聘最怕什么？怕的是“我以为你知道”。服务商觉得这个人不行，没通知甲方就默默淘汰了；甲方觉得简历不行，也没反馈，服务商还在傻傻地推人。这种信息不对称最致命。

SLA 不只是冷冰冰的数字，还得包含“软性”的协作规范。我管这个叫 “沟通日历”。

• 日报/周报： 不是形式主义的流水账，而是要包含：今日推荐简历数、面试安排数、Offer 情况、遇到的阻碍（比如某个岗位特别难招，原因是什么）。这个频率要根据项目紧急程度定。
• 紧急响应通道： 如果突然来了个急单，或者某个大客户急需 20 人，有没有 24 小时响应机制？SLA 里要指定双方的接口人（Key Person），并要求提供手机号、微信等联系方式。如果接口人休假，谁来顶替？
• 复盘会议： 建议每周一次。这不仅是汇报，更是校准。比如这周推的简历质量为什么下降了？是不是 JD 描述有问题？还是市场行情变了？SLA 里写上“每周三下午 3 点召开项目复盘会”，强制双方坐下来对齐颗粒度。

还有一个很具体的细节：面试反馈的时效。面试完之后，甲方多久给反馈？如果 48 小时不给反馈，候选人可能就接了别家的 Offer 了。所以 SLA 里要双向约束：甲方需在面试后 24 小时内反馈，服务商需在收到反馈后 2 小时内通知候选人。这种细节，决定了招聘的效率。

第六回合：违约与退出机制——好聚好散的预案

虽然我们希望合作愉快，但现实中翻车的也不少。如果服务商就是烂泥扶不上墙，或者甲方业务突然调整不需要这么多人了，怎么体面地结束？

SLA 里必须包含“熔断机制”和“退出条款”。

• SLA 红线： 设定一个底线。比如：连续两周推荐简历数量低于约定值的 50%，或者简历初筛通过率低于 20%。一旦触碰红线，甲方有权无条件终止合同，且不承担后续费用。
• 甲方业务变更： 如果甲方因为自身原因（如业务线裁撤）需要终止合作，需要提前多久通知（通常为 30 天），并支付多少“遣散费”给服务商（用于补偿他们已经投入的人力成本）。这体现了契约精神。
• 竞业限制： 服务结束后，服务商在多长时间内（比如 6 个月）不得挖走甲方的在职员工，也不得向甲方的竞争对手推荐本次项目中接触到的甲方内部员工。

写在最后：SLA 是活的，不是死的

聊了这么多，其实 SLA 最核心的不是条款本身，而是背后的 信任与透明。

在实际操作中，你会发现没有任何一份 SLA 能覆盖所有突发情况。市场在变，人在变，业务也在变。所以，最好的 SLA 是那种写得既严谨，又留有余地的。

建议在签署 SLA 之前，先搞个 “试运行期”（Pilot Period），比如一个月。这一个月里，大家先不急着扣钱，而是先跑流程，看看到底哪里卡壳。是简历推得慢？还是面试反馈不及时？把试运行中发现的问题，全部修正后，再固化到正式的 SLA 里。

跟服务商打交道，本质上是人与人的博弈。把规则定得越细，其实越是对双方的保护。对于甲方，是花钱买到了确定性；对于乙方，是付出了劳动拿到了明确的回报。这就跟过日子一样，账算明白了，心就不累了。

下次你再面对服务商那张笑眯眯的脸时，记得把这份 SLA 清单拿出来，一条条过。别怕麻烦，现在麻烦一点，以后就能省下无数个加班改简历的夜晚。

社保薪税服务