场景一：事情卡在半途，接手方需要先看清全貌
出现背景：前期已经推进过一段，中间因为人员变动或方向调整停下来了，现在想继续但没人能说清之前做到哪一步、哪些结论还有效。
涉及分组：服务矩阵中的需求梳理与方案对齐相关分组。
场景摘要：从你的处境找到对应服务
服务分组是按能力划分的，而多数人来的时候手里只有一件事、一个时间点和一个说不太清的需求。这一页反过来组织：先描述处境，再指向分组与进入方式。
场景分类说明
这里的场景按“需求是怎么被提出来的”分类，而不是按服务分组分类。常见的情况大致落在三类：一是事情已经卡住，需要有人接手推进；二是方向有了但还没拆成可执行的动作；三是手上有一批长期没整理的东西，需要一个稳定的处理方式。每一类下面各列两个典型场景，共六条。
用法很简单：从上往下读，找到最接近你现在处境的那一条，看它标注的涉及分组和进入方式。如果六条都对不上，直接看本节末尾“场景之外的需求如何提出”，那里说明了该怎么描述一件没被覆盖的事。
典型场景逐条说明
每条场景按“出现背景、涉及分组、建议进入方式”三段说明，读完后可以直接跳转，不需要回到顶部重新找入口。
场景二：方向已经定了，需要拆成可执行的动作
出现背景：目标与大致路径已经明确，但停留在口头或一页纸的层面，缺少分步骤的排期、责任划分和阶段检查点。
涉及分组：服务矩阵中的执行推进相关分组。
场景三：多个零散需求同时出现，需要先排序
出现背景：不同部门或不同时间点陆续提出了若干诉求，彼此有重叠也有冲突，直接同时开工容易互相拖累。
涉及分组：服务矩阵中的需求梳理分组，配合方案对齐。
场景四：交付标准说不清，验收时容易起争议
出现背景：合作进行到一半才发现双方对“做到什么程度算完成”的理解不一致，返工成本高，但又不想推翻重来。
涉及分组：服务矩阵中的交付物与核对要点相关分组。
建议进入方式：直接看 服务矩阵 中交付物与核对要点一节，把可核对的质量要求逐条对照，再回到 合作流程 的验收交付阶段确认口径。
场景五：长期积压的内容需要稳定处理方式
出现背景：不是一次性的项目，而是持续产生、持续需要整理的常态工作，靠临时找人补位始终不稳定。
涉及分组：服务矩阵中的执行推进与交付标准相关分组。
场景六：第一次接触，想先判断值不值得谈
出现背景：需求轮廓还在，不确定需要哪一类服务，也不确定是否要正式启动，只想先确认方向对不对。
涉及分组：服务矩阵全部分组，重点看适用对象一列。
建议进入方式：先通读 服务矩阵 的适用对象说明，再浏览 常见问题 里的服务范围与边界说明，判断清楚后再决定是否进入 合作流程 。
场景与服务分组的对应关系
下表把六条场景与它们主要涉及的服务分组并列，方便一次性对照；分组的具体工作内容与交付物，以服务矩阵页为准。
| 场景 | 主要涉及分组 | 分组入口 |
|---|---|---|
| 场景一：事情卡在半途 | 需求梳理与方案对齐 | 查看分组说明 |
| 场景二：方向已定待拆解 | 执行推进 | 查看分组说明 |
| 场景三：零散需求需排序 | 需求梳理 | 查看分组说明 |
| 场景四：交付标准说不清 | 交付物与核对要点 | 查看分组说明 |
| 场景五：长期积压需常态处理 | 执行推进与交付标准 | 查看分组说明 |
| 场景六：首次接触先判断方向 | 全部分组 | 查看分组总览 |
场景之外的需求如何提出
六条场景是归纳，不是清单。如果对不上，按下面三点把情况说清楚，比套用最接近的场景更有效。
-
说清当前状态，而不是想要的方案
先讲事情现在到哪一步、卡在什么位置、已经试过哪些做法。方案层面的判断留到方案对齐阶段，前期讲太多设想反而会盖住真实问题。
-
给出时间点和硬约束
比如某个节点之前必须有可用的阶段结果，或者参与方只在特定时段能配合。约束越具体，越容易判断是否落在服务矩阵的覆盖范围内。
-
说明谁能拍板、谁只是提意见
合作流程的每个阶段都需要有人确认，如果确认人还没确定，先把这个理清楚再进入流程，能省掉后面反复对齐的时间。
从场景到合作流程的下一步
找到对应场景之后，两条路可走。想先确认能力边界，去 服务矩阵 逐条对照适用对象与交付物；想直接开始推进，去 合作流程 看四阶段的工作内容与准备清单。两条路最后都会汇到需求确认这一步，先走哪条取决于你手上的信息够不够。
如果读完仍不确定，可以回 首页 看四条线索的整体说明，或者翻 常见问题 里的边界与不适用情况，那里列出了明确不在服务范围内的事项。