返回项目列表

智能客服与 AI HR 助手矩阵

从十个场景试水,收敛到真正嵌进业务的工具。

角色
产品 + 项目负责人
阶段
2024.07—2025.12
项目
2 号人事部

项目介绍

AI HR 助手矩阵是 2 号人事部在 AI 转型初期的一次场景筛选:以智能客服起步,扩展到薪酬、考勤、绩效、招聘、行政,共 10 个助手。它要回答的不是「AI 能不能接进 HR 系统」,而是「哪些场景值得用 AI、哪些必须保持确定性规则」。

起因很具体:这套 HR 系统功能密集、规则复杂,客户一边有高频操作咨询,一边有公式配置、绩效发起这类专业事务,长期压给售后和 HR 人工处理。公司当时不知道哪些场景真的适合 AI,所以第一批的定位是低成本验证,不是做产品线。

我的判断有两条:

  • 先做能算清对错的问答场景,再碰执行类;答不准的助手没有第二次机会
  • AI 要嵌进业务流程里,独立入口的助手留存最低

问题在哪

一个 HR 系统上百个功能点,客户记不住规则,售后在重复回答同一批问题。但把问答交给 AI,门槛不在「能不能接」,在「能不能答对」:第一版用现成的 RAG 方案直接跑,出现幻觉、响应慢、Token 消耗高三个问题——答错一次的信任损失,远大于答对十次。

AI 助手面板:小2管家、人事锦囊、薪算师、考勤公式通、JD 速写、公告智笔、制度参谋、动态快写、试题智解、绩效快启
AI 助手面板:小2管家、人事锦囊、薪算师、考勤公式通、JD 速写、公告智笔、制度参谋、动态快写、试题智解、绩效快启点击查看原图

三件事

一、把问答拆成一条可兜底的工作流

把 RAG 从「问题进来、答案出去」拆成「问题解析 → 知识检索 → 结果精简 → 意图路由 → 分支应答」,并加入敏感数据拒答与无答案兜底。改完之后 Token 消耗降低 50% 以上,响应耗时缩短 30% 以上。

关键在「无答案兜底」这一支:宁可说不知道并转人工,也不要编一个像样的答案。

二、知识库质量比工作流更决定效果

只调工作流,召回上不去的根子在知识库本身。做法是用 AI 把原始产品文档加工成「关键词元数据 + QA 问答 + 原始内容」,再经人工校对入库。

三、用留存数据决定哪些场景继续做

2025 年全年,智能客服累计服务 2,312 位 HR、解决 11,292 次咨询,稳定运营期 30 日留存约 25%,替代了部分人工售后咨询。

但拆开看,留存差别很大:HR 策略咨询与内容生成类助手的使用频次和留存持续走低;嵌进业务工具的薪酬公式助手 30 日留存达到 58%。据此减少低频场景投入,把资源转向专业工具与任务执行——绩效快启助手就是这一轮判断的产物,它把 AI 从「回答问题」推进到「执行系统操作」,支持按周期筛选并批量发起未启动的考核计划。

绩效快启:按周期筛选未启动计划,核对后批量发起
绩效快启:按周期筛选未启动计划,核对后批量发起点击查看原图

一次主动退出

2025 年末复盘发现,知识切片、加工和维护每月产生大量重复人工,而这些原始产品文档本就放在钉钉,钉钉原生 RAG 能力也已相对成熟。

因此推动问答能力迁移到钉钉原生方案,不再自己建库和维护。这不是放弃,而是把维护成本还给本来就该承担它的平台。

结果

  • 10 个助手以全年共享 Coze 订阅成本 ¥2,297 运行
  • 智能客服 2025 全年服务 2,312 位 HR、解决 11,292 次咨询,稳定运营期 30 日留存约 25%
  • Token 消耗降低 50% 以上,响应耗时缩短 30% 以上
  • 薪酬公式助手 30 日留存 58%
  • 用「免费 + 限制每日使用次数」建立认知,由 AI 员工助手承接付费转化

可迁移的判断

  • AI 场景的推进顺序跟着难度走:先做能答对的问答、再做能办事的执行,和 AI 能力的发展同步,不是倒过来
  • 嵌进业务流程的 AI 才有留存,独立入口的助手留存最低——留存数据比需求访谈更可信
  • 维护成本要算进去:能交给平台原生能力的,不要自己建库
  • 免费加限次是建立认知的手段,不是商业模式;转化要由另一个产品承接
查看原始产品介绍