常见问题：服务范围、合作方式与准备事项

服务方向集中在服务矩阵页，按业务条目逐条列出，每条都写明适用对象、典型场景与交付形式。判断方法很简单：先看适用对象一栏是否包含你的身份类型，再看典型场景是否和你当前的处境接近。两项都能对上，基本可以进入下一步；只对上一项，可以先把问题带进合作流程页确认。

可以合并，但要看两个方向之间是否存在先后依赖。存在依赖的，通常按顺序推进，前一段的产出是后一段的输入；彼此独立的，可以并行安排。服务矩阵页有专门的组合说明段落，列出了哪些方向经常一起出现、哪些不建议同时推进。

服务矩阵是当前完整的方向集合，不在其中的需求我们不会先答应再想办法。遇到这类情况，比较务实的做法是把你真正要解决的问题写清楚，对照矩阵里最接近的方向，看差距在哪。差距属于范围外的，我们会直接说明，而不是含糊接下。

范围以需求确认阶段谈定的内容为准。中途如果出现新的诉求，属于原范围之外的，走变更处理，具体步骤写在 交付标准 页的变更与异常部分。范围之内的工作内容不会临时增减。

分为需求确认、方案沟通、执行交付、验收反馈四个阶段。你不需要全程盯着，但有两个节点必须参与：需求确认阶段把目标和边界说清楚，验收反馈阶段确认结果是否符合预期。中间阶段按约定的节奏同步进展即可。

沟通节奏在方案沟通阶段就约定好，按阶段节点同步，而不是每天固定汇报。每个阶段结束时会给出一次明确反馈，说明已完成什么、下一步做什么。如果某个环节需要你提供材料才能继续，我们会提前说明，不会等到卡住才提。

先判断变化属于范围调整还是细节微调。细节微调在阶段内消化，不额外走流程；范围调整会影响时间安排和后续节点，需要重新确认一次。判断标准写在交付标准页的责任边界部分，避免双方理解不一致。

依据是需求确认阶段共同确认的交付标准，而不是临时感觉。可核对的质量要求逐条列在 交付标准 页，每条都写明检查方式。验收时按清单逐项过，有异议的当场记录，不留在事后讨论。

三样东西就够用：一是你希望达成的目标，用一两句话写清楚；二是目前的现状，包括已有的条件和已经做过的尝试；三是限制条件，比如时间上的要求或者不能触碰的边界。不需要写成正式文档，条理清楚就行。

可以。需求确认阶段本身就包含把模糊诉求梳理清楚的过程。但建议至少想明白一件事：你要解决的是什么问题，而不是你想要什么形式。问题清楚，形式可以一起讨论；只谈形式，往往会绕远路。

建议指定一个主要对接人，负责汇总内部意见并对外沟通。多方同时提需求容易造成信息冲突，反而拉长确认时间。如果确实需要多方参与，可以在方案沟通阶段安排一次集中说明，之后仍由主要对接人统一反馈。

需要。哪些内容可以提供、哪些需要脱敏，在需求确认阶段就讲明白，避免推进到一半才发现材料不能用。信息使用范围同样在这一阶段约定，超出约定范围的使用需要重新确认。