客户方案协同改进提案

评审稿 V0.5

1. 为什么要改

客户希望先让约120人的售后团队试用AI知识助手，先选200—300份常用资料，六周左右看看试点效果。信息在纪要、方案任务和初稿之间传递后，却变成了全公司3000人、2000份资料、云端部署和95%准确率。

产品同事核对初稿时集中指出这些偏差。客户后来又明确：先做售后团队，资料约200份，项目文档暂不进入。销售负责人也要求删除没有依据的80%成交概率。

客户经理还要等待方案排期，反复补充背景、开会解释和改稿。即使只是在成熟方案上做小改，也走同一条专家制作队列。此次改进把材料、需求分流、制作和专业确认一起调整：客户经理直接推进复用小改，专家集中处理新需求；Agent负责核对与成稿。

2. 本次范围

起点：已经约好需求访谈，开始准备本次拜访。终点：客户收到当前方案和必要的演示，反馈与下一步经人确认并留有记录。

参与者：客户经理、方案专家、产品经理及交付专家、销售负责人；客户提供需求、条件和反馈。

正式报价、合同签署、客户生产部署与交付履约，另按既有流程办理。内部流程试点与客户希望的“六周产品试点”分别安排。

本次使用同一商机的材料01—07：客户资料、访谈、纪要、方案任务、方案V0.1、专业核对与客户反馈。还需补齐每次提交、退回、修改和接收的时间，才能比较实际投入。

3. 五个问题怎样接到改法

4. 现状流程

客户经理准备拜访 → 客户说明需求与条件 → 客户经理在电脑和系统登记，为方案、产品、老板、客户分别整理材料；方案任务仍引用摘要草稿 → 大小需求都排队等方案专家制作，来回补问后形成初稿 → 产品/交付核对条件并按需准备Demo → 客户查看并反馈 → 销售负责人评审投入 → 客户经理确认下一步并更新记录。

打开现状泳道图。每项活动下标了P1—P5，按同一编号阅读后面的改法。

5. 先改工作，再用AI

删：P1/P5：取消个人重复台账、重复改写同一事实；保留必填业务记录。删除没有依据的成交概率。

合：P1/P4：原话、核对结果、当前稿和修改放进同一项目，按权限生成各方汇报，交接不用重讲。

调：先分流，再制作。成熟方案内的小改由客户经理组织出稿、配置已有Demo；新需求由专家牵头，产品/交付核定新能力与实施条件，按需准备新Demo。两路都在对客发送前完成专业确认。

简：共同约定复用标准、哪些内容能改、演示能展示什么，以及何时评审。A路线重点核对本次差异，B路线完整评审；不让小改重走整套方案设计。不同客户的业务问题和论据仍逐页改写。

AI：已有Agent先读材料和查缺口；依据专业确认调用客户方案演示稿Skill，生成可编辑PPT与来源表，再接收评审反馈改稿。需求核对、版本对比、待办汇总可作为后续能力，分别试做和测试。

6. 未来流程

客户经理准备拜访 → 与客户对焦需求并同步录音，会后由Agent结合访前资料整理纪要，再逐项核对 → Agent对照有效方案、列出差异与缺口 → 客户经理按约定标准分A/B路线 → 按各自分工准备方案与演示，Agent调用方案演示稿Skill成稿 → 方案专家核准 → 客户经理确认并发送 → 客户试用反馈 → 销售负责人确定投入与下一步 → 客户经理确认同一项目记录，按权限生成各方汇报，再交接给下一位。

打开未来泳道图。未来图包含Agent泳道，活动下标明Skill、具体改法和所回应的P编号。

缺范围或专业依据，退回补问；客户提出新要求，先回到范围确认，再改方案；收到的意见必须绑定材料、页码和版本。确认状态不等于允许自动对外发送或写回所有系统，具体操作按既有授权执行。

两条路线怎样选

A｜1→N复用小改：有已验证的成熟方案；只改约定内容，没有新增接口、部署方式或交付承诺。客户经理与AI核对适用依据，直接组织客户版PPT、配置已有演示。方案专家重点核对变化与适用范围，再由客户经理确认并发送。

B｜0→1或超出复用范围：新场景、新能力、复杂组合、未确认条件均先请专家处理。方案专家澄清并设计，产品/交付确认能力与条件、按需准备新Demo；Agent按确认内容成稿，随后完整评审。无法确认的内容保留为待办，只演示已经说清的概念范围。

问答要带着材料进行：“这次需求能否使用现有方案？哪些依据支持？改动是否超出可改范围？缺什么条件？”AI给出核对建议，客户经理按约定标准选路；拿不准就请专家确认。

本例接口与部署尚未确认，当前走B路线；不是因为客户规模小就当作可复用。未来专业条件明确后，落在既有范围内的后续小改才可以转A。复用目录、可改字段和评审时段由方案、产品与客户经理共同约定，纳入试点评审。

P编号图例：P1 多头登记、反复汇报，原话仍丢失；P2 没问清的条件写进方案；P3 等方案、补信息、反复改稿；P4 客户要求没跟进到最新稿；P5 把客户兴趣当成采购进展。

7. 人和Agent分别负责什么

8. 怎样组织多人协作

未来流程统一在人机协同平台中推进。需求、材料、讨论、方案版本、处理状态和评审意见都保留在同一项共享任务中。下一位接手人能看到前面怎样处理、改过什么、哪些已经确认、还缺什么，接着往下做，上下文不随岗位交接而中断。

由销售负责人牵头，指定一位协调人，客户经理、方案和产品各有明确接收人。人的确认和Agent的执行结果都回到这项任务，连同负责人、期限与下一步一起保留。

待接收 → 处理中 → 待评审 → 已完成。缺项退回并说明需要谁补什么；阻塞要写原因和协调人。每天查看临期任务和阻塞，按约定时间集中评审方案。

各自Agent可以使用不同的Skill与个人记忆；协作所需的背景和产出写入共享任务，供相关参与人和Agent接续使用。优先用现有平台承载共享任务，再逐步连接所需业务系统；本次New Qoder示例先展示方案核对、制作与评审这一段。

9. 依赖和运行安排

内部平台支持方确认Skill加载、文件读写、PPT导出和定时/事件能力；业务系统负责人确认接口、字段与权限。接口没接通时先使用获准导出文件，不把缺接口的问题藏进演示。

手动先跑通。做法稳定后，新材料准备好可触发待审稿；每天汇总待评审与临期任务。配置中写明输入目录、材料版本、输出位置、重复事件处理、失败日志、接管人和暂停方法。

客户侧旧知识库接口、部署与权限仍由客户IT和信息安全确认，列入方案条件，不当作内部协作工具已经解决的问题。

10. 十日试点计划

组织一支小队，推进“客户需求确认→方案制作与评审→客户反馈确认”的改进。先用Demo让相关岗位确认未来工作方式，再按实际工作量开发与试用。

分别记录A/B路线从需求确认到客户反馈确认的全程、人工投入、等待和返工，使用相同口径比较。个人月度投入与单件流程周期分开记录，均不能当作已实现节省。专业确认、客户反馈P4和商机判断P5仍由对应岗位跟进。

内部方案评审Demo、客户知识助手Demo是两个不同的演示对象。当前内部Demo尚未实现自动分流；新功能按确认后的开发计划推进，不能当成已经上线。客户知识助手的六周业务试点也不等于这份十日试点计划。

11. 请评审决定

一项可以拍板的试点决定：先试客户需求核对。若连续试用仍把未确认条件写成承诺，暂停扩大范围，由方案和产品负责人修订规则；重试通过后再决定是否放量。把决定人、停用条件和复查日期记在共享任务中。

是否同意先试A/B分流？哪些方案、可改字段和Demo允许客户经理复用，哪些条件必须转专家？谁维护标准、谁提供有效材料、谁确认差异与对客表达，评审按什么节奏接收？

允许使用哪些样本，哪些接口由谁协调？先采用什么人工确认和运行方式？

Demo汇报由谁确认投入，开发后由谁比较业务效果、决定继续改进或扩大试用？将决定、负责人、首个时间点与复核安排写进共享任务。