客户问“上周到底做了什么”，你翻聊天记录就输了

服务交付记录的核心目的，是让“做了什么、没做什么、结果在哪”三件事随时可查，而不是等客户追问时才去翻聊天记录。一套简单的记录结构，通常只需要边界说明、动作清单和结果归档三块，用表格或协作文档就能落地。

很多做外贸服务的人都有过这种时刻：客户在群里问“上周那个改动到底做了没有”，你翻了几十条消息，还是不确定当时有没有真正执行。问题不在记性，而在于交付过程没有被结构化地留下来。下面这套做法不依赖复杂工具，重点是把边界和证据固定下来。

先把项目边界写死，再谈执行

服务交付里最容易出问题的地方，往往不是做得不好，而是双方对“这次包含什么”理解不一致。客户以为改文案顺带调了落地页，你只改了文案。这种分歧一旦发生，再补记录就很被动。

比较稳妥的做法，是在项目启动时用一段简短文字锁定边界。不需要法律合同那么重，但要写清三件事：这次交付覆盖哪些页面或流程、哪些动作明确不在范围内、超出范围的需求走什么流程。

• 覆盖范围：具体到页面、模块或账号，比如“独立站产品详情页的英文文案”，而不是“网站优化”。
• 不包含项：把客户可能默认包含但实际不做的内容列出来，比如图片重拍、广告投放代运营。
• 变更方式：超出边界的需求怎么提、谁来确认、是否影响排期。

边界写完后，建议在首次沟通时让客户回复一句“确认”。这句确认比事后解释有用得多。平台和工具的协作规则会变，请以官方当前规则和实际后台为准。

动作清单要能回答“做到哪一步了”

边界定完，接下来是执行记录。动作清单不需要写成流水账，但每一条都要能对应到具体产出。判断标准很简单：如果客户拿着这条记录问“这个做完了吗”，你能不能立刻给出是或否。

实际操作中，可以按阶段列动作，每条动作后面挂一个状态和产出链接。状态不用太细，用“待开始 / 进行中 / 已完成 / 已确认”四档就够。产出链接指向具体文件、页面或后台截图位置，避免只写“已处理”。

1. 把本次交付拆成 5 到 10 条可验证动作，太多会变成负担。
2. 每条动作写清输入和输出，比如“输入：客户提供的产品卖点文档；输出：详情页英文文案 v1”。
3. 状态更新时只改状态和产出链接，不重写整条记录。
4. 客户确认后标记“已确认”，并记录确认时间和确认人。

有些团队会把动作清单放在协作工具里，有些直接用一个共享表格。工具不是关键，关键是更新频率。建议每周固定一次同步，而不是等到客户来问才补。

结果归档：让三个月后的人也能看懂

项目结束后，动作清单会变成历史数据。如果只是留在聊天记录或某个人的本地文件里，下次类似项目又要重新摸索。结果归档要解决的是“下一次能不能直接复用”。

归档内容可以包括：最终交付物链接、客户确认记录、执行中遇到的典型问题和处理方式、以及这次边界之外但客户提过的需求。最后一项容易被忽略，但它往往是下一轮合作的起点。

归档不是把文件堆在一起，而是让接手的人能在十分钟内搞清楚这个项目做了什么、结果在哪、哪些坑踩过。

命名规则也值得花两分钟定下来。比如“客户简称-项目类型-交付月份”，避免出现“最终版”“最终版2”“真的最终版”这类文件。规则简单、团队能坚持，比设计一套复杂体系更有效。

一个常见但容易忽略的检查清单

在把记录交给客户或归档之前，可以快速过一遍下面几项。它们不复杂，但能挡掉大部分后续扯皮。

• 边界说明里是否有明确的“不包含项”？
• 每条动作是否都有对应的产出链接或文件？
• 客户确认记录是否可查，确认人是否明确？
• 归档文件命名是否统一，是否放在团队可访问的位置？
• 超出边界的需求是否单独记录，而不是混在本次交付里？

这套结构对入门团队来说已经够用。真正难的不是设计模板，而是每次项目都按同一套方式记录。可以先从一个客户或一个项目试起，跑通之后再推广到其他项目。

常见问题

服务交付记录和日报有什么区别？日报偏向个人工作汇报，交付记录面向项目和客户，重点在边界、动作和结果是否可查。

客户不配合确认怎么办？至少把边界说明和动作清单发到双方都在的渠道，保留发送记录。确认不是唯一证据，持续同步也是一种留痕。

小项目也需要这么记吗？项目越小，记录可以越短，但边界和产出链接这两项建议保留，它们是最常被追问的部分。

归档放在哪里比较合适？放在团队都能访问的位置，命名统一即可。具体工具选择请以团队实际协作习惯和官方当前规则为准。