能不能推到第二个部门，不看第一个部门的满意度打分，看三件能核对的事：有人会自己教、产出被二次使用、权限与知识有可复用模板。三项缺一，先补再推；否则第二个部门要把从零摸索的路再走一遍，投入翻倍而采用率更低。
看三个能核对的信号，而不是满意度打分：首批用户里有 5 人以上每周主动使用 3 次以上；有产出物被部门二次使用，比如写进周报、方案或评审材料；部门内有人能独立回答新同事怎么用。第三个最关键，能力长在外部顾问身上的部门，复制一次就等于把服务再买一次。
这套信号只适用于已有稳定场景的部门。如果第一个部门还在试工具、没有固定交付物，三项都测不出来，此时复制等于把试验成本摊到两个部门，代价是两边都停在试用状态。
先选流程标准化程度高的，再考虑业务量和配合度。流程标准的部门任务边界清楚、输入输出稳定，配置一次就能被别人接手；流程靠个人经验、资料散在微信和纸面上的部门，做出来是一堆个人用法，换个人就失效。
| 维度 | 适合先做 | 不适合先做 |
|---|---|---|
| 流程标准化 | 有书面流程或系统单据 | 靠老员工经验，口头交接 |
| 数据位置 | 资料在文档库或业务系统里 | 资料在个人电脑、聊天记录里 |
| 负责人 | 部门负责人愿意签字验收 | 没人愿意对使用效果负责 |
| 使用频率 | 每天或每周重复的任务多 | 一年几次的临时任务 |
标准化程度高不等于价值大。如果这个部门任务本身低频、出错代价又小，做出来也无人关心，配置和培训投入收不回来；这类部门适合后期批量铺开，不适合当第二个样板。
把角色做成模板，把部门做成映射。先定 4 类角色：普通使用者、知识维护者、部门管理员、审计查看者，每类角色绑定可用能力和可访问的知识目录；新部门进来只做人员归类，不重建权限树。这样第三个、第四个部门的配置时间可以从两周压到两天。
角色模板适合组织架构相对稳定的企业。部门之间人员借调频繁、一人同时承担多个部门职责时，单主角色会挡住正常工作，需要补临时授权与到期回收，否则用户会绕开系统私下传文件，权限反而更失控。
不要。知识分三层：全公司共用层放制度、产品资料、通用话术；部门层放本部门流程和模板；项目层放临时资料并设过期时间。复制到新部门只新增部门层，共用层保持不动。共用层建两套，等于给同一件事留下两份互相矛盾的答案。
三层结构在部门之间口径差异大的企业里会不够用，比如法务与生产的合规要求完全不同，共用层只能放最基础的定义；把差异内容硬塞进共用层，两个部门都会拿到不适用的答案，返工成本高于各建一套。
能搬的是连接器、权限模板、培训课件骨架、评测问题集；必须重做的是场景清单、岗位任务拆解和验收基线。深云 FDE 页面把可复用的部分点明为连接器、知识规则与评测标准三类，其余按场景重写。把第一个部门的方案原样贴过去，常见结果是上线两周后没人打开。
| 资产 | 能否直接复用 | 原因 |
|---|---|---|
| 连接器与接口配置 | 可以 | 系统接口不变，改参数即可 |
| 权限角色模板 | 可以 | 角色逻辑与具体部门无关 |
| 培训课件骨架 | 部分可以 | 案例要换成本部门任务 |
| 场景清单 | 必须重做 | 流程和判断标准不同 |
| 验收基线数值 | 必须重做 | 业务量和使用频率不同 |
如果两个部门本来就同源，比如同一套订单流程拆成的两个小组，重做场景清单是浪费；此时应先比对流程文档，确认差异只在人而不在规则，再决定复用比例，避免为了流程完整再走一遍访谈。
经验值是单部门稳定使用 4 到 6 周后再开下一个，同时在推进的新部门不超过 2 个。每多一个部门，运营投入约为前一个的 0.6 到 0.7 倍，因为模板和课件能复用，答疑和场景调整不能复用。三个部门同时起，答疑量会压在同一批人身上。
上面的周次是经验区间，不是承诺。部门不足 10 人、任务极简单的场景，2 到 3 周就能稳定，压到 4 周反而拖慢；跨地域、多班次的部门则需要更长观察期，照搬周次会让判断失真。
设三个停手信号：第 8 周活跃人数不到首批的一半；内部答疑人离开后无人接手；新部门的场景仍全部由外部顾问代做。任一成立就暂停扩张，回到单部门打磨。继续加部门只会把没解决的问题复制更多份，还摊薄了本该用来修问题的人力。
停手信号不适用于刚做完组织调整的部门，比如刚合并或刚换负责人，活跃度下降属于过渡期现象；这种情况应先给 4 周观察窗口，再判断是复制失败还是组织波动，否则容易误停一个本可以成的项目。
本文的交付口径参考官网公开的 WorkBuddy 服务页与 FDE 页面，产品能力与授权范围以腾讯云当期文档为准。文中周次与倍数为经验区间，用于排期参考，不构成效果承诺。
深云做企业 AI 生产化交付，可以先给一版场景判断与实施路径，再决定要不要做。
了解深云的交付方式