FDE 项目的 KPI 该什么时候定,谁来定?
KPI 要在问题定义阶段定下来,而不是验收前再补。深云公开的 FDE 页面把场景优先级、业务指标、数据和接口清单列为找准问题阶段的输出,说明效果口径本来就该在动工前成形。分工上:业务负责人定什么算有价值,实施方定怎么测得出来,双方一起把口径写成一句话,再拆成可统计的指标。验收前才补 KPI,通常只能补到使用量这类活动指标,证明不了业务价值。
问题定义阶段就把 KPI 写成一句话
- 把 KPI 口径先写成一句话,例如客服问答平均处理时长从 8 分钟降到 5 分钟以内,再拆成可统计字段
- 让业务负责人在立项会上逐字确认这句话,实施方只负责让这个数能被稳定测出,不替业务定价值
- 把这句话原样抄进立项文件和合同附件,后续任何 KPI 调整都走书面变更,不做口头改口
边界与提醒如果场景还在探索期、连业务流程都没走查完,强行定数值目标容易变成拍脑袋:可以先定方向性口径(降低耗时、减少差错),数值目标等试点第 1 周真实数据出来再填,代价是预算审批多一轮,换来的是目标有依据。
KPI 分几层,哪一层才该当主指标?
分三层:过程 KPI(里程碑达成、评测通过率)、使用 KPI(活跃人数、任务完成量)、业务效果 KPI(耗时、成本、差错率的变化)。主指标只留给第三层,前两层是路标,不能当向管理层汇报的主结果。官网公开的 FDE 页面把评测治理的范围写成准确性、稳定性、安全、成本和业务效果,其中成本和业务效果就属于第三层,实施方的交付里本就包含这部分评测。
过程、使用、效果三层各管一件事
| 指标层级 | 典型指标 | 该拿来做什么 | 常见误用 |
|---|
| 过程层 | 里程碑达成率、评测通过率 | 管项目节奏,提前发现延期和质量倒退 | 拿评测通过率当业务价值去汇报 |
| 使用层 | 周活跃人数、任务完成量 | 判断用户是否真的在用,定位推广堵点 | 拿打开次数证明省了多少钱 |
| 效果层 | 单件耗时、外包成本、差错率 | 立项汇报、验收和续约评估的主依据 | 只看平均值不看分布,掩盖长尾问题 |
边界与提醒纯个人效率类场景(如日程整理、文档摘要)可能测不出效果层的硬数字,此时以使用层为主指标并写明是代理口径,不要硬编一个省了多少小时的成本故事,编出来的数字经不起财务追问。
没有改造前的基线,效果 KPI 还能定吗?
能定,但要先补基线。上线前抽 2 到 4 周把现状测清楚:同类任务人工耗时、外包费用、差错与返工率,取真实记录而不是估算。已经来不及测的,用相邻口径替代,例如按历史工单量折算人工成本。没有基线的效果 KPI 只是愿望,验收时双方各说各话,谁也说服不了谁。
先测改造前,再谈提升多少
- 抽 20 到 50 件近期同类任务,逐件记录人工处理时长和结果质量,形成基线表
- 把基线数据让业务和财务各确认一次口径,避免验收时对分母起争议
- 测不到硬数据的场景改用可统计的代理指标,例如人工复核比例从多少降到多少
边界与提醒业务量季节性强的行业(如电商大促前后、零售节假日)单月基线不可靠,基线期要覆盖一个完整业务周期,否则淡旺季差异会被误读成 AI 带来的变化,验收结论整体失真。
哪些 KPI 最容易失真,怎么防?
最容易失真的是活跃和调用次数:打开不等于完成任务,更不等于省了钱。防失真有三个做法:把口径绑到任务完成层、抽样人工核对结果质量、立项时约定数据出口。腾讯云 ADP 的 AgentOps 支持观察准确率、任务完成质量、调用成本、失败原因等指标,工程层数据有平台出口,业务效果数据仍要从企业自己的业务系统出。
三类易失真指标与对应防法
| 易失真指标 | 失真原因 | 防失真做法 |
|---|
| 登录与打开次数 | 打开不等于使用,推送通知也会带来打开 | 只统计到任务动作层,例如完成一次完整问答闭环 |
| 会话量与会话时长 | 时长变长可能是变慢而不是变有效 | 按任务完成口径重新归类,每月抽 10 到 20 条人工核对 |
| 满意度打分 | 样本少且偏两极,代填普遍 | 固定抽样比例,写清打分时间点、对象和回收方式 |
边界与提醒指标口径在项目中途更换是最常见的失真来源:上线前用一套口径、汇报时换成另一套更好看的口径,任何一方发现都会推翻全部结论。口径变更必须书面留痕并说明原因,旧口径数据至少保留一个季度备查。
KPI 数据从哪里出,谁来认这个数?
立项时就定数据出口:工程层数据从腾讯云 ADP 的运营评测能力出,业务效果数据从企业自己的业务系统出,双方共同认可,不让服务方单方面自证。每项 KPI 写清三件事:从哪个系统取数、谁负责出数、有争议时以哪份原始记录为准。数据出口没有约定,验收阶段扯皮最多的就是数。
数据出口与认数规则四条
- 逐项列出每条 KPI 的数据来源:ADP 运营看板、业务系统报表、人工抽样记录各对应哪些指标
- 指定每项指标的出数人和复核人,双方各一人,按月各出一次书面数据
- 约定争议处理顺序:先对原始记录,再对统计口径,最后才谈数值调整
- 把数据出口写进合同附件,项目中途换人时口径不变,接手方按同一套规则出数
边界与提醒业务系统改造困难的场景,前期可先用人工周报方式出数,但要写明这是过渡方案并约定切换时间点,例如上线后 3 个月内完成系统出数;长期靠人工手抄汇总的数据经不起审计,也不适合做续约依据。
试点期和推广期的 KPI 要不要分开定?
要分开。试点期回答闭环成不成立,看单场景任务完成率和相对基线的效果变化;推广期回答复制稳不稳,看新场景复用、新部门采用和效果是否保持在同一水平。深云的 WorkBuddy 服务页把持续运营阶段的输出写成采用报告与优化计划,官网 FDE 页面把采用复制阶段的输出写成运营报告、优化计划、复用资产,这两份报告正是分期考核的现成载体。
两个阶段各答一个不同的问题
| 阶段 | 核心问题 | KPI 侧重 | 典型误判 |
|---|
| 试点期(约 4 到 8 周) | 闭环能不能跑通 | 任务完成率、单场景效果对比基线 | 用试点部门的活跃率预测全员采用 |
| 推广期(约 1 到 2 个季度) | 复制会不会走样 | 新场景复用数、新部门效果保持度 | 场景一多就只看总量不看单场景 |
| 运营期(长期) | 价值能不能守住 | 效果指标月度走势、成本占比 | 没有指标裸奔,靠印象谈续约 |
边界与提醒试点成绩不能直接当推广目标:试点部门通常是配合度最高的部门。推广期目标应写成缓冲区间,例如效果保持基线改善幅度的八成以上,并且先在第二个部门复跑一次冻结评测集、核对一次基线,再排期全员推广,直接照搬试点目标会造成大面积不达标。
KPI 写进哪些文件,续约时怎么用?
四个落点:立项文件写口径与基线,合同附件写出数规则与口径变更流程,验收单附逐项实测数据,续约评估用冻结评测集和运营报告对比历史走势。KPI 不达标也要写处置条款:调整场景、调整范围或停止投入。让不达标有明确出口,双方才敢签真实目标,而不是签一个谁都不当真的数。
从立项到续约的四个落点
- 立项文件:写清 KPI 口径、基线数据和目标值,附基线测量记录
- 合同附件:写明数据出口、出数频率,约定口径变更须书面确认
- 验收单:逐项列出指标实测值与基线对比,只给总分和截图的验收单不签
- 续约评估:重跑冻结评测集,对照运营报告里 3 个月以上的效果走势再谈投入
边界与提醒KPI 写得过紧(逐项都设罚则)会促使实施方只挑容易测的指标做,反而偏离业务价值;更稳的写法是主指标带处置条款、辅助指标只做复盘参考。签约前逐条让实施方确认数据可得性,测不出来的指标不要写进去。
内容说明
事实来源含官网 FDE 服务页与 WorkBuddy 服务页、腾讯云官方页面;文中周数、条数、比例均为经验值,不是效果承诺。
需要评估这类场景的落地路径?
深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。
了解深云的交付方式