先想清楚：交付说明到底给谁看
整理服务项目时，很多企业会把内部用的服务流程、岗位分工、验收标准直接搬到页面上。写的人觉得信息完整，客户看完却抓不到重点。问题往往不在内容多少，而在交付说明没有先回答客户关心的事。
交付说明的读者通常有两类：一类是正在比较服务、准备做决定的客户；另一类是已经接触过销售、需要确认细节的客户。前者关心这项服务解决什么问题、大致怎么交付；后者关心交付物是什么、自己要配合什么、什么时候能拿到结果。页面首屏如果先写内部流程，两类读者都会被劝退。
所以整理服务项目时，可以先把交付说明当成一份对外的服务说明书，而不是内部作业手册。判断标准很简单：客户看完这一段，能不能说出自己会得到什么、需要做什么。
把服务边界写清楚，页面重点才有落点
服务边界是交付说明里最容易被忽略、也最影响页面重点的部分。如果一项服务包含什么、不包含什么没有写清，客户就会按自己的理解去猜，后续沟通成本反而更高。
整理时可以按三个问题过一遍：
- 这项服务从哪一步开始，到哪一步结束？
- 哪些事项由服务方完成，哪些需要客户提供资料或做确认？
- 哪些情况属于额外需求，需要另行沟通？
这三个问题的答案，就是页面上需要突出的重点。比如服务方负责方案和执行，客户需要提供基础资料并在关键节点确认，那么页面重点就应该放在“交付物”和“客户配合事项”上，而不是把内部排期表整段贴出来。
边界写清楚之后，页面结构会变得简单：先讲服务能覆盖的范围，再讲交付物，最后讲客户要配合的动作。每一块只解决一个问题，读者不容易迷路。
交付物怎么列，客户才看得懂
交付物是交付说明的核心。很多页面把交付物写成一段话，客户读完还是不知道会拿到什么。更清楚的做法是逐项列出，每一项说明名称、形式和用途。
假设一家企业提供网站内容整理服务，交付物可能包括内容清单、栏目结构建议和页面文案初稿。页面上可以这样写：
- 内容清单：以表格形式整理现有页面和素材，便于后续筛选；
- 栏目结构建议：说明栏目层级和内容归属，供确认后使用；
- 页面文案初稿：按确认的结构编写，供客户内部审核。
这里的关键不是把交付物写得多，而是让客户能判断“我拿到这个东西之后能做什么”。如果交付物之间有关系，比如先有清单再有结构建议，可以在页面上按顺序排列，客户自然能理解交付节奏。
交付物名称也要避免内部叫法。内部叫“素材盘点表”，客户可能不理解；写成“现有内容和素材清单”，理解成本会低很多。
客户配合事项要放在显眼位置
交付说明只写服务方做什么，页面重点会偏。客户需要配合的事项同样重要，而且往往决定项目能不能顺利推进。
常见配合事项包括提供资料、确认内容、安排对接人、在约定节点反馈意见。这些内容如果藏在页面底部，客户容易忽略，后续再补沟通就会拖慢进度。更合理的做法是把配合事项放在交付物之后、流程说明之前，用简短条目列出。
写配合事项时，建议说明动作和判断标准，而不是只写“请客户配合”。比如“提供现有产品介绍资料，格式不限，但需要能看清服务范围和适用对象”，比“请提供相关资料”更可执行。
如果配合事项有时间要求，可以写成相对节点，例如“在结构确认后提供文案素材”，避免写死具体天数。这样页面既清楚，也不会因为个别项目变化而失效。
页面顺序按客户决策路径排，而不是按内部流程排
交付说明整理好之后，页面顺序决定重点是否清楚。一个常见的误区是按内部流程排：先讲团队分工，再讲作业步骤，最后才讲交付物。客户看到后面已经失去耐心。
更符合客户决策路径的顺序是：
- 这项服务解决什么问题、适合谁；
- 服务包含哪些内容、不包含哪些；
- 会交付什么、客户需要配合什么；
- 大致怎么推进、有哪些节点需要确认；
- 常见问题或补充说明。
这个顺序不是固定模板，但核心是先把客户最关心的判断依据放前面。内部流程可以作为补充，放在页面靠后位置，或者只保留客户需要知道的节点。
如果一项服务有多个版本，比如基础版和完整版，页面重点应该放在版本差异上，而不是把两个版本的流程各写一遍。可以用对照方式说明每个版本包含什么、适合什么情况，客户更容易做选择。
整理完之后，用检查清单复核页面重点
交付说明写完不等于页面重点就清楚了。发布前可以按下面几项做一次复核：
- 首屏是否能让客户看出这项服务解决什么问题；
- 服务边界是否写清包含和不包含；
- 交付物是否逐项列出，名称是否对外易懂；
- 客户配合事项是否放在显眼位置；
- 页面顺序是否按客户决策路径排列；
- 内部术语和岗位分工是否已经删减或改写。
复核时可以让不熟悉这项服务的同事读一遍，看能否说出服务内容和交付物。如果对方需要反复猜测，说明页面重点还不够清楚。
整理服务项目不是一次性的工作。服务内容调整、交付方式变化时，交付说明也要同步更新。把交付说明当成页面的一部分长期维护，比上线后再零散修改更省力。
