先看结论：先把交付用起来，再谈复购
收到尾款并不代表客户已经能顺利使用成果。小团队可以先建立一条简短的维护流程：交接清楚、确认使用、处理问题、核实结果，再在合适的场景下讨论新需求。复购取决于客户需求与交付体验，不能靠固定频次的问候来保证。
售后范围最好在方案与报价阶段就写清，交接时再逐项确认。
交付当天，至少留下这五项资料
- 最终成果的名称、版本与存放位置。
- 基本使用说明、已完成的培训或演示记录。
- 未完成事项、已知限制及双方确认的处理方式。
- 售后范围、联系入口、响应安排及紧急问题的处理渠道。
- 谁保管企业账号、谁负责后续维护，相关到期提醒由谁接收。
涉及账号时，通过约定的安全方式移交，客户应确认已取得必要权限；不要把账号密码混在普通回访表、群聊或公开文档里。
三次回访可以怎样安排？
以下是服务型项目的参考安排，具体时间按使用频率、约定服务和客户意愿调整：
- 交接后：确认是否收到成果、能否访问和使用，有没有阻断使用的问题。
- 经历一次实际使用后：询问在哪一步卡住，原先目标是否已有进展，还缺什么说明或支持。
- 问题处理后或下一业务节点前：确认问题是否真正解决，再问是否有新的、具体的使用需求。
适合直接问：“这次交付中最让你费力的一步是什么？”以及“如果只能改一件事，你希望改哪里？”GOV.UK 的服务测量指南建议在完整服务结束点收集反馈，并设置开放式改进问题；这里借鉴其反馈方法，不照搬政府服务的发布要求。[2]
收到不满时，按五步形成闭环
- 记录事实：问题出现在哪一步，影响什么，客户已经尝试过什么。
- 确认接收：告知负责人及下一次反馈时间；无法立即解决，也要说清下一步。
- 核对责任和范围：区分交付缺陷、使用说明不足与新增需求，按约定处理，不能未经核对就要求客户加钱。
- 处理并验证：记录做了什么，请客户在原使用场景中确认结果。
- 更新方法：反复发生的问题应进入交付模板、培训说明或产品改进清单。
ISO 10002 的公开介绍将接受反馈、处理投诉和改进产品服务联系起来。[1] 上述清单是日常执行建议，不表示企业已经取得某项认证。
一张轻量回访表够不够？
起步时可以记录：项目编号、交付日期、回访目的、客户反馈、问题负责人、约定时间、处理结果、客户是否确认，以及后续联系偏好。每周检查尚未解决的事项，比只记录“已联系”更有用。
常见问题
什么时候适合介绍新服务？
当当前问题已经处理、客户提出新目标，且你能说明新服务怎样解决该目标时再介绍。售后支持不要以接受营销或给好评为前提。
满意度高就代表一定会复购吗？
不是。满意度反馈、问题解决和再次购买是不同信息。要分别记录回复人数、反馈内容、服务类型与观察时间，不用单个好评推断全部客户。
资料来源与更新
编辑：生意妙招内容编辑部。资料核对日期：2026 年 11 月 4 日。文中的模板、安排与演算为编辑整理的执行建议，不是行业基准或效果保证。来源文档用于支持相应方法，产品功能和机构说明以最新官方资料为准。
