项目交付后，客户为什么还在找你？

网站上线了，尾款收到了，项目群却安静不下来。

今天有人问首页图片在哪里换，明天有人把文章存成草稿，以为已经发布。你发过录屏，也开过培训会，但客户还是习惯直接问你。每次只花几分钟，似乎不好意思计较；一周下来，正在做的新项目却被打断了十几次。

独立开发者、设计师和小工作室很容易遇到这种尾巴。合同写着“交付网站”，客户理解的却是“以后我们能自己使用这个网站”。两件事之间差的那一段，往往没有人在报价时认真计算。

把交接做好，首先能省下自己的时间。至于能否把它单独做成一门服务，要看客户究竟缺了什么，以及这部分工作原本由谁负责。

开发者眼里的后台有内容类型、组件、权限和发布状态。运营同事眼里可能只有一句话：明天的活动开始了，我要把首页那张图换掉。

如果说明书按照后台菜单逐项介绍，对方就得先理解系统结构，再把自己的需求翻译成操作路径。你觉得已经解释得很完整，他却仍然不知道从哪里开始。培训会里点头的人，回到电脑前也可能卡住：刚才那个按钮在哪里，点下去会不会直接改动线上内容？

最省事的检查方法，是请接手的人实际做一次。挑一项可以在测试环境完成的任务，让他自己操作，你先别接过鼠标。对方停顿的位置，会告诉你真正需要补充什么。

有人分不清保存和发布，就解释两者的结果；有人不知道图片为什么被裁掉，就给一张尺寸示例；有人根本看不到按钮，就检查权限。再多写五页通用教程，也解决不了账号权限的问题。

交接是否完成，可以看客户能不能独立做完一件日常工作。 签过验收单、看过视频，都替代不了这一步。

对于一个简单的展示网站，第一版交接资料可能只需要覆盖几件事：发文章、换图片、修改联系方式、检查发布结果，以及出问题时找谁。

每件事单独写，标题就用客户会说的话。例如“替换首页活动图”，下面说明从哪个页面进入、需要准备什么、操作之后在哪里检查。不要让接手人为了完成一个动作，来回翻三份文件。

录屏适合演示连续操作，图文适合快速查找。一次两小时的培训录像，日后很难被当作帮助文档使用。客户不一定记得你在哪一分钟讲过换图，也未必愿意再看一遍。

工具已经能减轻制作资料的工作。[Scribe](https://scribe.com/)提供操作过程的自动记录和文档生成能力，[Loom](https://www.loom.com/)可以录制并分享屏幕。但这些能力只解决了记录的问题。哪些步骤值得留下、客户能否看懂、界面更新后谁来修改，仍需要有人判断。

交付的位置也要顺着客户的习惯。小团队平时在微信或飞书里沟通，就给他们一个容易找到的目录入口。没有必要为了显得专业，要求客户再注册一个陌生平台。关键资料还应保留一份由客户自己掌握的副本；如果用 Notion，[官方导出说明](https://www.notion.com/help/export-your-content)列出了普通页面导出 Markdown、数据库导出 CSV 等方式，具体内容能保留到什么程度仍要逐项检查。

域名、托管和素材的归属也值得放进目录。记录负责人、续费时间、遇到问题联系谁即可，密码和密钥不要混在普通共享文档里。交接结束后，客户应该知道资产在哪里，而不只是知道你的微信号。

如果原合同已经承诺提供源文件、操作说明和培训，就应当把这些工作完成。把没做好的交付重新包装成收费项目，会伤害信任。

更适合单独报价的，是原范围之外的工作。例如客户更换了运营人员，需要重新梳理岗位操作；一个旧网站经历过几任供应商，资料散落，需要有人整理；或者客户准备把某项工作收回内部，希望安排一次完整的交接和演练。

这里有一个容易忽略的问题：付款的人和使用资料的人，可能不是同一个。老板同意做交接，运营却没空参加，最终很可能还是所有问题都回到你这里。接单前先确定谁来接手、他下个月要做哪些事、什么时候能一起走一遍，比先讨论文档有多精美更有用。

系统本身也必须处于可使用的状态。如果按钮失效、账号找不到、后台隔三差五报错，这已经超出整理说明的范围。先列出故障和责任人，单独讨论修复。否则你卖的是几份文档，最后承担的却是一个旧系统的全面维护。

制作交接资料的成本，常常被误算为写作和录屏时间。实际上，你还要理解客户的工作，试着完成操作，确认账户归属，等相关人员回复，再根据演练修改资料。

假如给一个熟悉的网站整理五项操作，报价 2400 元，花八小时完成，相当于每小时 300 元的服务收入。这只是报价算例，尚未扣除获客、工具、税费和空档成本。若调查旧系统多花了六小时，同样的报价就只剩每小时约 171 元。

这两个数字的差别，足以改变一单生意值不值得接。对于陌生系统，可以先约一次有明确范围的付费梳理：确认关键任务能否运行、缺哪些资料、后续需要谁配合。梳理完再报完整交接的价格。客户买到一份缺口清单，你也不用凭几张截图承担未知工作量。

报价最好同时写明覆盖的任务、参与的人、修改次数和答疑期限。不要轻易写“直到客户满意”或“终身维护”。例如本次包括一位接手人的演练和交付后一轮集中澄清；新增员工培训、功能变化引起的重写，再按实际工作评估。边界说清楚，双方才知道费用对应什么。

如果你正好在交付网站，可以先把这个方法用在本来就该完成的交接里。挑三到五个常见操作，找真实的接手人走一遍，记录他在哪一步求助，以及你为整理资料多花了多少时间。两周后再看，群里的重复问题有没有减少。

这样得到的判断，比先搭一个“客户交接平台”扎实得多。如果客户根本不会日常使用后台，一套完整资料可能没有多少价值；如果所有问题都来自故障，你需要改善的就是产品和维护方式。

有了一个经得起使用的样例，再向熟悉的建站团队或设计工作室介绍这项服务。他们能看到你具体补上了哪一段工作，也能判断是否适合放进自己的项目报价。第一次独立接单，尽量选技术栈熟悉、接手人明确、范围小的项目，别同时承担陌生系统和陌生客户两种不确定性。

后续是否值得做成长期业务，要看付费和工时，而不只看别人说“这个想法不错”。客户愿意为整理和演练付款，实际交付也能控制在预估范围内，才有继续做的基础。如果每单都在救火，或者客户只想买无限答疑，就应该重新调整服务范围。

对一人工作室来说，一个项目真正结束的时刻，未必是网站上线那天。可能是几周后，你看到客户自己发出了新文章，换好了活动图，整个过程不再需要来问你。