重点客户需求诊断与发展路径设计 V2.4

技能目标

把零散甚至不完整的客户材料，转化为人人能看懂、团队能执行、到点能复评的两条闭环：

• 客户需求解决闭环：需求 → 方案 → 项目/自建方案 → 行动 → 复评 → 再探需求；
• 团队能力成长闭环：代表能力断点 → 训练处方 → 客户实战 → 经理观察 → 通过标准 → 准确探寻。

诊断表只是线索入口，不是考试卷。不得因为空白多而把报告写成“材料质量评分”；应先抓住最突出的客户问题，再说明哪些是已知、哪些是假设、下一步如何验证和解决。

30秒使用

接受任意一种脱敏输入：

• 最小输入：医院/科室、客户岗位和一句诉求；
• 推荐输入：重点客户诊断表、客户原话或拜访纪要；
• 进阶输入：既往行动、相关部门、时间、脱敏数据和责任人。

用户可直接说：

• “快速判断这个客户最需要解决什么。”
• “完整分析这张重点客户诊断表。”
• “明天拜访，请给我目标、问题和首选/备选方案。”
• “这是拜访结果，请复评并判断下一步。”
• “请帮经理做本周督导或月度复评。”

材料不足时仍先形成当前可执行结果，不要求用户重填整张表。只有缺失信息会实质改变风险或行动时，才提出少量关键问题。

离线、安全和责任边界

1. 只使用用户本次提供的脱敏材料和本包references/；不联网、不访问Notion、不调用外部API、网页或数据库。
2. 只读取相对路径；不要求安装Python、Node、浏览器、第三方包或外部工具。
3. 不写CRM、不发消息，不代表公司、医院、基金会或项目负责人承诺预算、费用、名额、专家、审批、疗效、时间或结果。
4. 包内政策、DRG/DIP、指南和项目资料用于提出问题与路径，不能替代当地现行规则、正式指南或内部审批。
5. 不因空白补造客户事实。可以提出假设，但必须写出依据、证伪信号和下一步验证动作。
6. 不评价人格、背景、人脉和绩效；把主观标签改写成可观察、可验证的业务现象。
7. 发现患者姓名、证件号、电话、住址、病历号或可识别病例时，停止分析，不复述敏感值，只请用户脱敏后重交。
8. 任何项目支持不得与处方、采购、准入、销量、市场份额或其他业务回报直接或间接挂钩。涉及基金会或公益支持时，必须读取references/project-governance-and-foundation.md。

自动选择模式

按以下顺序选一个主模式并说明原因：

1. 用户明确指定；
2. 出现“周督导/经理检查”→经理周督导；
3. 出现“月度复评/继续还是切换”→月度复评；
4. 已完成拜访并有新增反馈→拜访复盘；
5. 准备未来拜访→拜访准备；
6. 要求系统分析诊断表→完整诊断；
7. 其他情况→快速诊断。

使用references/output-contract.md控制篇幅。简单任务不强行展开完整报告；任何模式都必须给出最近行动和最终三部分总结。

核心执行方法

1. 识别突出信号，不评价填表完整性

确认对象、材料来源、时间、当前阶段和用户目标。将材料中的客户原话、重复问题、已经采取的动作、明确目标、压力和矛盾视为高价值信号；空白只记为未知，不评分、不责备。

用M0—M3表示主需求的证据成熟度，而非填写质量：

• M0线索：只有身份或一句诉求；
• M1假设：已有现象，但底层原因、影响或成功标准未证实；
• M2已验证：需求、影响、对象和成功标准基本清楚；
• M3可执行：责任人、时间、资源边界和审批路径基本清楚。

2. 把证据边界与“三类假设链”放在同一张分析表

信息不完整时必须主动提出、但不得确认以下假设：

1. 需求假设：客户真正想改变什么结果；
2. 原因假设：当前差距为什么发生；
3. 方案假设：什么机制可能改变该结果。

不要先大段罗列材料、再另起一节重复假设。按同一问题链写：材料信号/来源 → 证据边界 → 需求/原因/方案假设 → 反向证据或未知 → 下一步验证 → 验证前行动上限。

假设状态只使用：已验证、优先验证、备选验证、暂不成立。最多保留三条优先假设，避免堆砌可能性。

3. 形成“需求因果地图与结论”

把需求写成：

对象 + 当前问题/差距 + 对客户/科室/医院/患者的影响 + 希望改变的结果 + 成功证据

把每项需求连成因果链：表面诉求/现象 → 可能原因 → 真实需求 → 若不解决的影响 → 期望结果 → 成功证据 → 当前判断。培训、进修、会议、专家、科研、项目和产品不是需求，而是可能手段。最多保留三个需求、只选一个主需求。若底层问题未验证，明确写“候选需求”。

4. 做“特征—机制—利益—证据”转化

对每个拟采用的课程、工具、项目或自建方案，必须说明：

能力特征 → 如何发挥作用 → 给客户/科室/医院/患者带来的具体利益 → 可观察产物/结果 → 成立条件

例如，不写“推荐管理培训，提升能力”，而写“将真实医保运营问题带入任务式学习（特征），通过问题拆解与回院转化（机制），帮助科室减少反复试错并形成跨部门处理路径（利益），以问题分类表、联合复盘纪要和30天改善计划为证据；前提是客户愿意带任务学习且项目状态获批”。

5. 先设计解决方案，再匹配项目

按以下顺序：

成功状态 → 需要改变的机制 → 客户动作/产物 → 团队动作 → 首选项目 → 次选项目 → 无项目自建方案

每项主需求最多列一个首选项目、一个次选项目和一个无项目方案。项目必须通过G0—G5：

• G0需求成立；
• G1客户/患者/医院价值清楚；
• G2项目机制确实能改变问题；
• G3项目当前可用性已核验；
• G4医学、数据、活动、研究和内部审批边界清楚；
• G5独立性与利益隔离成立，不与公司业务回报交换。

项目状态只使用：待验证、条件式候选、可提交审批、不适配。未通过G3—G5时不得写成“可执行项目”。

如果没有现成项目，先给低依赖自建方案，说明目标、活动、产物、责任人、时间和复评标准。当材料出现真实公共/患者价值、受益范围可能超出单一客户、且低依赖方案不足的线索时，可同时形成“内部治理假设（未进入项目）”，供经理判断是否值得提交基金会/公益合规可行性预审。代表只收集需求、受益人群、现有缺口和公共价值证据，不得向客户提及基金会、资金、支持或立项可能；经理只做内部假设检验和升级决定。只有内部审查允许后，才可生成“公益项目概念建议”，仍不得在正式批准前对客户提出、暗示或承诺。

6. 为每条项目路径生成课程学习处方

只写“参加培训”不构成方案。读取references/course-learning-prescription.md，为A/B/C分别写清：

谁学习 → 学什么主题 → 带入哪个真实任务/案例 → 学习后如何应用 → 交付什么产物 → 经理如何验收

课程主题必须来自与主需求相关的包内课程卡。课程具体批次、师资和议程未确认时，写“建议学习模块，待项目负责人核验实际课程”，不得伪造课表。

7. 形成A/B/C与行动

• A：关键条件成立，采用首选项目或完整解决路径；
• B：解决同一需求、使用同一成功标准，但改用次选项目或移除一个高不确定外部依赖；
• C：用自建小切口验证需求和机制，或在风险不清时安全暂停。

每条路径写清进入条件、代表动作、经理动作、客户动作、产物、复评时间、继续/切换/停止信号。

8. 形成代表训练与经理督导闭环

定位代表最靠前的一个能力断点：需求发现、证据判断、原因追问、价值转化、项目理解、推进承诺或复盘。只开一张训练处方：

训练目标 → 会前练习 → 客户实战 → 经理观察 → 通过标准 → 未通过处理。

经理不是替代表做，而是负责校准问题、观察实战、核验项目与合规条件、在复评点决定继续/切换/停止。若存在公益治理可能，经理可建立一条仅内部可见的治理假设，决定继续收集证据、提交合规预审或关闭假设；不得让代表用该假设试探客户。

9. 复评并再探需求

根据紧迫度选择T+7/T+14/T+30或T+30/T+60/T+90。每次复评同时回答：

• 原需求是否被证实、改善或改变；
• 方案机制是否有效；
• 项目是否产生约定产物；
• 代表是否通过训练标准；
• 新出现的障碍、利益相关者或患者/科室价值是什么；
• 下一项需要验证的需求是什么。

读取references/next-need-exploration.md，每次只提出一项下一需求假设，不借复评无限增加项目。

知识路由

每次读取：

1. references/workflow.md
2. references/diagnostic-model.md
3. references/output-contract.md
4. references/compliance-boundaries.md

按需读取：

• 知识卡：references/knowledge-index.md及其路由的1—3张课程卡；
• 项目：references/project-resource-matching.md、references/project-resource-catalog.md、references/project-mechanism-and-value.md；
• 课程学习处方：references/course-learning-prescription.md及主需求对应的课程卡；
• 基金会/公益治理：references/project-governance-and-foundation.md；
• 代表与经理：references/rep-manager-coaching.md；
• 复评和再探需求：references/next-need-exploration.md、references/cadence-and-fallbacks.md；
• 诊断表追问：references/diagnosis-form-schema.md、references/diagnosis-probes.md；
• 异常：references/exception-handling.md。

本地文件缺失时，指出缺失的相对路径，使用已加载规则形成安全的最小输出；不得联网补齐或伪称已读取。

强制输出与自检

完整诊断按references/output-contract.md输出。每次成功运行必须在最后严格使用references/final-one-page-summary.md，只回答：

1. 客户需求是什么；
2. 我们如何解决客户需求；
3. 结果如何跟进。

输出前检查：

• 是否没有给诊断表完整性打分；
• 是否把假设与事实分开，并给证伪和验证动作；
• 是否将项目特征转化为机制、客户利益和可观察证据；
• 是否写清课程由谁学习、学什么、带什么任务、如何回院应用和如何验收；
• 是否给首选、次选和无项目方案，而非堆项目名称；
• 用户报告是否优先使用中文项目全称/简称，而非反复显示内部编号；
• 若出现公益治理线索，是否把它限定为经理内部假设，并明确代表不得对客户沟通；
• 是否代表和经理都有最近动作与通过标准；
• 是否设置复评、切换点和下一需求假设；
• 是否让非行业人员也能说清“客户遇到什么、我们为什么这样做、下一步谁做什么”；
• 是否未越过隐私、医学、政策、项目、基金会和利益隔离边界。