桌面上同时躺着「花名册-最终版」「花名册-新版」「在职员工(1)」· 谁也说不清哪份是准的
员工关系与合同合规 · 真实业务触发
社保稽核通知或仲裁应诉要提交在职人员名册,HR 打开花名册才发现:三个版本人数对不上(158/156/153),身份证号缺了 21 个,用工形式一栏半数是空的。三天内要交一份能对上账的名册。
不是流程描述,是调研出来的真痛点 —— 每条可点开核对出处
变化不在「快」,在「参与的角色」和「覆盖的范围」
5 步 · 每一步的产出都是下一步的输入
痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.0
最大差异点 · 不要求客户先统一版本。三个 Excel、入离职记录、社保增减员表、合同台账全部扔进来交叉 —— 版本由数据说话不由人说话。
评分口径:痛感看「这事没做好谁会生气、生气到什么程度」; AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」; 落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。
判断标准只有一个:这份东西能不能直接进企业的流程
不做「用工形式该怎么定」的法律判断 —— 非全日制还是劳务派遣需要结合实际用工情况由人认定。本场景做的是栏位完整性与版本一致性。
Live Demo 里有一个完整案例的每一步,包括 Agent 在哪一步拦住了