判断一家 WorkBuddy 服务商,先看哪三件事?
看三件事:能不能把使用范围落到部门与角色、有没有可验收的交付物、试点结束后有没有人持续跟。只讲产品功能的通常只是转售;能说清「谁在什么时候做什么、交付什么东西」的才是做交付的。三件事缺一件,问题都会在推广阶段集中暴露。
先看交付动作,不看产品介绍
- 使用范围:能否给出部门、角色、场景的对应清单,而不是笼统说全公司都能用。
- 交付物:权限配置表、知识接入清单、培训材料、运营周报,这些是能拿去验收的东西。
- 持续机制:试点结束后谁负责答疑、谁维护知识库、多久复盘一次、复盘结果给谁看。
- 需求边界:明确哪些需求属于 WorkBuddy 的配置范围,哪些要转 ADP 或另行开发。
- 风险提示:能否说清你们这类规模的企业,通常在第几周、因为什么原因用不起来。
边界与提醒这三件事要在第一次沟通就问,不要等到签合同。如果对方只能做产品演示、无法描述交付动作,后续落地工作大概率全部落到你们 IT 部门身上,这部分隐性人力往往超过服务费本身。反过来,如果对方主动提出先做一次范围评估再报价,说明其交付是有方法的。
只做开通和培训的服务商,问题出在哪?
问题出在使用率。开通只是把入口打开,培训只解决「知道有这个工具」,真正决定用不用的是三件事:权限是否合理、知识能不能接进来、任务有没有嵌进原有流程。缺这三样,通常在第 3 到 6 周出现使用率下滑,之后再拉回来要花几倍力气。
搁浅大多发生在第二个月
- 第 1 到 2 周:新鲜感驱动,使用率通常较高,看不出真实问题。
- 第 3 到 6 周:遇到权限不足、查不到内部资料、输出格式要手动调整,使用频次开始下降。
- 第 7 周之后:员工回到原流程,只在偶尔需要写材料时打开一次,进入低频状态。
- 转折点判断:如果第 4 周时人均周使用次数低于 3 次,说明任务没有嵌进流程,需要重新设计场景。
- 补救成本:从低频拉回高频,通常比一开始就做对多花 1 倍以上的推广投入。
- 成本对比:只做开通培训的报价通常低三到五成,但把内部人力按人天折算进去,三个月后总成本多数不低于完整交付。
边界与提醒也有企业只做开通培训就用起来了,前提是任务本身简单、员工接受度高、且不涉及跨系统取数。判断标准很直接:如果你们的日常任务需要跨系统查数据、需要按部门隔离信息、或者必须引用内部文档才能完成,那基本不能只做开通。
组织与权限配置该做到什么程度?
要做到三层都明确:哪些部门先开、每个角色能用哪些能力、哪些知识只对特定人群可见。只做一层(全公司统一开启)会在试点期就遇到信息越界和权限争议,之后每增加一个部门都要重新梳理一遍,返工量随部门数增加而放大。
权限不是开关,是边界
| 配置层级 | 要决定的事 | 常见错误 |
|---|
| 部门层 | 先开哪些部门、按什么顺序扩 | 一次全开,问题同时涌来无法定位 |
| 角色层 | 每个角色可用能力与操作范围 | 按职级一刀切,忽略岗位差异 |
| 数据层 | 哪些知识对哪些人可见 | 默认全员可见,敏感文档未单独隔离 |
| 审计层 | 谁在什么时候访问了什么 | 无日志,出问题无法回溯责任 |
边界与提醒权限配置过细也会带来成本:每新增一个部门都要走一遍审批,推广节奏会被拖慢。常见的做法是先按部门粗分,第二批推广时再细化到角色,避免第一版就设计过度。另外,权限一旦上线就不要频繁改动,变动前应通知到具体使用者。
企业知识接入,服务商该交付什么?
交付三样东西:一份接入清单(哪些系统、哪些目录、由谁授权)、一套更新规则(文档改了怎么同步、过期内容怎么下线)、一份效果记录(哪些问题能答准、哪些答不准、原因是什么)。只把文件批量上传不算接入,那只是搬了一次数据,两周后就会过期。
知识接入的核心是更新机制,不是上传量
- 接入清单:逐条列明来源系统、目录路径、责任人、授权方式与接入时间。
- 切片规则:长文档怎么分段、表格怎么处理、附件是否纳入,规则要写下来可复用。
- 更新机制:文档修订后多久同步一次,是定时同步还是手动触发。
- 下线机制:过期文档怎么标记、由谁确认、确认后多久从检索范围移除。
- 效果记录:抽样 50 个真实问题做对照,记录答准、答偏、拒答的分布。
- 责任人机制:每类知识指定一名业务责任人,负责内容准确性,服务商只对同步机制负责,不对业务内容对错负责。
边界与提醒如果内部文档本身版本混乱、多人同时维护同一份文件,接入后会出现同一问题两个答案的情况。这类问题不能靠服务商解决,需要先指定每类文档的单一责任人并完成一次清理。跳过这一步直接接入,后面排查成本会远高于收益。
数字员工与 Skills 搭建,怎么判断服务商是不是真做过?
让对方完整讲一个任务:输入是什么、拆成几步、哪一步必须人工确认、失败怎么回退、最终交付成什么格式。真做过的人能说到字段级和异常分支,只做过演示的人会停在「这个可以实现」这一层,再往下问就开始讲产品能力而不是任务细节。
追问细节比看演示更有效
- 问输入:数据从哪个系统来,字段名是什么,格式不统一时怎么处理。
- 问步骤:拆成几步,每步的产出是什么,步与步之间靠什么传递。
- 问人工:哪一步必须人确认,确认界面长什么样,拒绝后流程怎么走。
- 问异常:接口超时、字段缺失、权限不足三种情况分别怎么处理。
- 问交付:结果是文件、消息还是回写到业务系统,格式由谁定。
- 验证方式:让对方在你们的环境里现场改一处配置,看是否熟悉路径与字段,比看录制好的演示更可靠。
边界与提醒能讲清细节不等于适配你们的场景。同一个任务在不同系统里的字段定义、审批环节、权限规则都不一样,建议用你们自己的一个真实任务做小范围验证,跑通后再决定是否推广。另外,复杂任务不要一次全自动化,先做半自动、保留人工确认,出错时可回退。
怎么用一次试点验证服务商的真实水平?
选一条高频、输入输出清晰、失败不影响核心业务的流程做试点,周期 4 到 6 周,参与人数 15 到 30 人。验收只看三个数:任务完成率、人工介入次数、平均耗时。这三个数在试点期连续两周稳定,才具备推广条件,否则说明效果依赖个别人或特定数据。
试点要能算出三个数
| 指标 | 定义 | 判断参考 |
|---|
| 任务完成率 | 成功交付且无需重做的任务占比 | 连续两周波动小于 10 个百分点才算稳定 |
| 人工介入次数 | 单个任务平均需要人工修改的次数 | 超过 2 次说明流程设计有问题 |
| 平均耗时 | 从发起到交付的平均时长 | 与人工基线相比应有明确改善 |
| 覆盖率 | 实际使用人数占开放人数的比例 | 低于 60% 说明场景选择或推广有问题 |
边界与提醒试点人数少于 10 人统计不出有效结论,超过 50 人则问题同时涌来难以定位。另外,试点期由服务商全程陪跑,成功率天然偏高,推广期应按 20% 到 30% 的回落预留预期,避免目标定得过高导致后期失信。
合同和验收怎么写才不扯皮?
写清四件事:范围(覆盖几个部门、几个场景、多少用户)、交付物清单(配置表、知识清单、培训材料、运营报告)、验收口径(指标定义与目标值)、退出条款(未达标怎么处理、资料归谁)。只写「提供 WorkBuddy 相关服务」这类表述,等于没有约定,后期分歧无从裁决。
把服务拆成可验收的条目
- 范围条款:部门数、场景数、用户数写具体数字,超出部分按什么单价另计。
- 交付物条款:每项交付物的名称、格式、交付时间,缺一项扣多少款项。
- 验收条款:三个指标的定义、统计方式、目标值,以及由谁统计。
- 运维条款:质保期多长、响应时限多久、超出范围的问题如何计费。
- 退出条款:未达标时的处理方式、资料与配置的归属、数据如何完整导出。
边界与提醒验收目标值不要定成单一百分比。任务完成率受任务难度影响很大,同一套配置在不同流程上的表现可能差一倍。建议分场景定目标,并约定未达标时的补救方式(延长交付期或按比例调整费用),比只写「达标后付款」更可执行。
内容说明
产品定位以腾讯云官方产品页表述为准;交付环节与边界划分以深云官网 WorkBuddy 服务页公开内容为准。文中指标区间来自企业 AI 项目的通行实施经验,不指向任何具体客户。