WORKBUDDY · 服务商与采购

WorkBuddy 交付报价含实施费,怎么核实是谁在做

判断一家供应商是在做交付还是只做转手,看实施人员归属、交付物清单和验收起草权这三处,而不是看报价高低。深云官网把 WorkBuddy 服务范围拆成六项能力,可以逐项拿来对照。

WorkBuddy 交付服务商核实采购决策

WorkBuddy 只买账号和买交付,差别落在哪一步?

差别不在账号数量和单价,而在账号开通到团队真正用起来之间那几个环节由谁负责。账号买到的是产品能力,配置、知识接入、权限划分、培训与采用运营才是交付内容;只看报价单上的账号数,判断不了这些环节有没有人做。

开通只是起点,交付发生在开通之后

  • 先把团队要完成的 3 个具体任务写下来,再对照供应商方案里有没有对应的配置与培训安排
  • 把「谁负责让这 3 个任务跑通」写进合同附件,不要只写账号数量与到期时间
  • 查报价单是否把账号费、配置实施、培训、运营分成四项,只列一项的通常没有交付投入
边界与提醒

如果企业只有十几个人、任务集中在个人写作与查资料,产品自带能力可能已经够用,额外买交付反而是浪费;是否需要交付,取决于有没有跨部门流程、系统对接和权限分层。

报价单上有实施费,怎么判断这笔钱买的是谁的时间?

实施费只证明预算科目存在,不证明执行人是谁。要核三件事:实施人员的雇佣关系、在项目里的投入方式与时长、交付物是否与这笔费用对得上。三项里有两项说不清,这笔钱大概率是转手成本,而不是实施投入。

三处对不上,实施费就只是转手成本

核对项转手型常见说法交付型应有的说法
实施人员归属由合作方派单,人员不固定能给出姓名、角色和所在团队
投入方式远程开通加一次线上讲解现场或固定在线时段,按周排期
交付物账号清单和产品操作手册配置说明、权限矩阵、场景清单、培训材料
项目结束上线即结项,后续按次收费给采用报告和下一阶段优化计划
边界与提醒

人员归属只能靠合同附件与人员名册核对,凭名片和微信头像判断不了;如果供应商明确说明实施由腾讯云原厂或授权伙伴承接,这属于正常分工,关键是把承接方写进合同,而不是要求一家包完所有环节。

合同签的是 A 公司、干活的是 B 公司,这种结构能签吗?

能签,但必须把 B 写进合同。分包本身不违规,风险在责任断点:验收、故障处置、数据权限如果还挂在 A 身上,A 又约束不了 B,出问题时客户会被夹在中间,两边都说不归自己管。

分包可以,责任不能跟着分包走

  • 把实际实施方名称、承担角色和投入人月写进合同附件,删掉「由乙方自行安排」这类表述
  • 约定更换实施方需书面确认,并留出不超过 2 周的交接过渡期
  • 核对合同主体、开票主体、实施主体三者是否一致,不一致的要求书面说明原因
  • 查保密与数据处理条款是否覆盖实际接触数据的第三方人员,而不只覆盖签约方
边界与提醒

如果 B 只提供云资源或账号开通、不接触业务数据,把责任写清即可,不必强求三方合同;真正要盯的是接触生产配置和业务数据的那一方,责任链断在这里代价最大。

交付物清单里该出现哪几样东西,缺哪样说明只是转手?

五样东西能看出交付是否真实发生:场景清单、权限矩阵、评测或验收样例、岗位培训材料、采用报告。它们分别对应业务判断、边界配置、结果负责、用户上手和上线后跟踪,缺其中两样以上,通常说明这一单只完成了账号开通。

五样交付物,对应五个必须有人做的动作

交付物能证明什么缺失时的信号
场景清单与优先级有人做过业务判断只有通用功能介绍
权限矩阵有人配过组织与数据边界权限靠客户自己摸索
评测或验收样例有人对结果负责验收靠演示观感
岗位培训材料有人设计过上手路径培训只是产品宣讲
采用报告有人跟踪真实使用上线即结项,无人复盘
  • 拿深云官网 WorkBuddy 交付服务页的六项范围当对照表,缺「培训与采用运营」一项的要追问由谁补
  • 要求供应商在投标文件里逐项回应五样交付物,写成「按需提供」的按缺失处理
  • 把交付物验收与尾款绑定,例如最后 20% 在采用报告提交后支付
边界与提醒

交付物的厚度不等于交付质量,一份 60 页的权限矩阵如果没人维护,三个月后就会失效;判断时看有没有对应的维护责任人和更新频率,而不是看文件页数。

验收标准该由谁起草,供应商自己写的那份能签吗?

供应商可以起草,但不能单方定稿。一份能用的验收标准要写清三件事:用哪些样例、达到什么结果、由谁判定。样例必须来自客户真实业务,判定人必须包含业务负责人;只有供应商签字的标准,实质是把验收变成一次演示。

把验收写成样例、结果和判定人

  • 从近 3 个月的真实单据里抽 20 条做样例,正常与异常各占一半
  • 约定通过线,例如 20 条里至少 16 条结果可直接使用,其余人工修改不超过 2 处
  • 指定业务负责人签字确认,技术方只做运行与性能确认
  • 把未通过时的返工范围和时间写进条款,例如 10 个工作日内补齐重测
边界与提醒

通过线不能照抄行业数字,财务、法务这类高风险场景必须保留人工复核,不能只看自动化率一个指标;上面给的条数只是经验值,要在第 1 周用真实样例校准后再写进合同,否则会把验收变成对赌。

上线后出故障,工单第一跳该落到谁手上?

落到能改配置的那一方。如果工单先到销售或客服、再转两三层才到实施,说明服务方没有一线处置能力。客户可接受的路径是:一个受理入口、一个责任方、一条写明的响应时限。

一个入口、一个责任方、一条时限

  • 问清故障受理入口是工单系统还是某个人的微信,后者在人员变动时会直接断掉
  • 约定响应时限分档,阻断业务的问题 2 小时内响应,影响体验的 1 个工作日内给方案
  • 要求每月出一份问题清单,含问题描述、处理人、关闭时间和根因归类
边界与提醒

如果根因在腾讯云产品侧,服务方的处置空间有限,这时看的是他能否代为提工单并跟进到底,而不是承诺修复时间;把原厂责任和服务方责任分开写,才不会在故障当天互相推。

什么情况下,只买账号不加交付反而是对的选择?

团队在 10 人以内、任务集中在文档与查资料、内部有人能自己配权限时,直接采购账号是成本最低的路径。转售本身不是问题,问题是在需要交付的场景里,用转售的价格预期去买交付的结果,最后两边都不满意。

先判断你要的是通道还是责任链

企业情况合理选择判断依据
10 人以内,个人写作与查资料直接采购账号没有跨系统与权限分层需求
单一部门,1-2 个固定任务账号加一次性配置服务需要权限与知识接入,但不持续运营
跨部门流程,接 ERP 或 CRM交付加采用运营有系统集成、验收和推广要求
金融、医疗等强合规场景交付加治理与审计需要评测集、人工复核与留痕
边界与提醒

这张表只是判断起点,实际采购还要看年度预算、内部 IT 人力和合规要求;如果公司已有 AI 平台团队,外部交付的边际价值会下降,此时更该买的是某个环节的支持,而不是整套服务。

事实来源

  • 官网 WorkBuddy 交付服务页把服务范围拆成六项能力,第六项是培训与采用运营,含试点推广、使用培训与效果复盘。 来源:https://www.shenyun.co/workbuddy-service/
  • 同一服务页给出四步采用路径:规划试点、完成配置、培训推广、持续运营,每一步都标注了对应输出物。 来源:https://www.shenyun.co/workbuddy-service/
  • 深云公开的 FDE 页面写明:判断是否属于 FDE,不看是否有人驻场,而看团队是否共同定义问题、完成生产闭环、对持续采用负责。 来源:https://www.shenyun.co/fde/
  • FDE 页面把「单纯产品销售」列为对照形态:交付平台或账号,客户自行设计和集成。 来源:https://www.shenyun.co/fde/
  • WorkBuddy 产品官网把自身描述为免部署、安装即用的智能 AI 工作台,支持桌面、主流 IM 与小程序多端。 来源:https://workbuddy.tencent.com/
  • 企业 AI 应用开发页把交付能力分成四层,第四层是评测上线与运营,含测试评测、生产部署与应用运营迭代。 来源:https://www.shenyun.co/enterprise-ai-development/

内容说明

内容说明:文中服务范围表述取自公开服务页面;合同条款、验收条数与响应时限需结合具体项目与合同确认,所列数字为经验区间,不构成效果承诺。

需要评估这类场景的落地路径?

深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。

了解深云的交付方式