项目已经交付,却因为客户迟迟不验收、尾款没有明确日期,导致一人公司先垫人力和成本,现金流管理就会变成被动催款。解决方法不是单纯“催得更勤”,而是从报价和排期开始,把每个交付动作都对应到一个可确认的结果、一个付款节点和一条留痕记录,形成同一张项目交付与收款表。

先建立一张“交付—验收—收款”总表
这张表不只是项目进度表,也不是单独的应收账款表,而是把三件事放在同一行:
- 交付了什么;
- 客户如何确认;
- 什么时候形成收款动作。
可以使用下面的字段:
| 阶段 | 交付成果 | 客户确认标准 | 计划提交日 | 计划验收日 | 应收金额 | 收款节点 | 确认记录 | 异常动作 | 当前状态 |
|---|---|---|---|---|---|---|---|---|---|
| 需求确认 | 需求说明与范围清单 | 客户书面确认范围、优先级和不包含项 | 4月3日 | 4月4日 | 30% | 预付款 | 邮件或项目工具记录 | 未确认则不进入开发 | 待确认 |
| 初版交付 | 可运行初版或首轮方案 | 按约定检查项完成验证 | 4月12日 | 4月15日 | 40% | 中期款 | 验收清单 | 逾期未反馈则发提醒 | 进行中 |
| 最终交付 | 正式版本与交付文档 | 完成最终验收并列明遗留项 | 4月22日 | 4月25日 | 30% | 尾款 | 验收结论 | 逾期则暂停新增工作 | 未开始 |
表中的每一行,都应该能回答四个问题:
- 客户现在需要检查什么?
- 什么结果算完成?
- 哪个动作会触发收款?
- 如果客户不确认,下一步怎么处理?
如果一行只能写“继续跟进”“完成开发”或“客户满意”,说明这一阶段还不能用于项目管理和尾款管理。
把交付成果写成客户可以确认的结果
不要把工作量当作验收标准
“完成三天开发”“完成一轮设计”“投入十小时咨询”可以用于内部估算,但通常不能直接作为客户验收依据。客户要确认的是可观察的成果。
例如:
| 不够清晰的写法 | 更适合验收的写法 |
|---|---|
| 完成网站开发 | 完成首页、产品页和联系表单,测试环境链接可访问 |
| 完成内容策划 | 提交一个月选题表、每个选题的目标读者和内容提纲 |
| 完成数据分析 | 提交约定范围内的数据表、关键指标说明和结论页 |
| 完成品牌设计 | 提交确定数量的标志方案、选定版本及基础使用规范 |
验收标准至少应包含四类信息:
- 交付物:文件、页面、功能、报告或服务结果是什么;
- 范围:包含哪些内容,不包含哪些内容;
- 检查方式:客户通过什么页面、文件或测试步骤确认;
- 确认结果:通过、需要修改,还是存在不影响使用的遗留项。
每个阶段只保留一个主要确认结果
一人公司不适合把一个阶段拆成过多细碎的付款节点,否则沟通成本会上升。更实用的做法是:一个阶段对应一个主要结果,结果确认后再进入下一阶段。
例如,独立开发项目可以拆成:
- 需求与技术方案确认;
- 核心流程初版确认;
- 完整版本验收;
- 上线支持或维护期结束。
内容服务则可以拆成:
- 选题与内容方向确认;
- 首批样稿确认;
- 批量内容交付;
- 数据复盘或后续服务确认。
阶段数量取决于交付周期和客户风险。周期越长、前期成本越高,越需要提前设置中间确认点,而不是等到最终交付才收款。
让付款节点跟随可确认的里程碑
付款节点不应只写“项目结束后付款”。对一人公司来说,项目结束往往是最容易产生争议、也是现金压力最大的时候。
可以根据项目类型选择不同安排:
短项目:预付款加最终款
适合几天到数周内完成、交付物相对明确的项目。
| 节点 | 付款安排 | 适用目的 |
|---|---|---|
| 项目启动前 | 收取预付款 | 覆盖排期锁定和前期投入 |
| 初版或中期成果确认 | 收取中期款 | 避免大部分工作完成后才形成应收 |
| 最终交付或上线前 | 收取尾款 | 将最后交付动作与收款连接 |
短项目不一定需要很多节点,但至少要避免“全部做完后一次性收款”。如果项目金额较小、周期很短,可以采用启动前付款和交付前结清的方式,减少追踪成本。
长期服务:按周期或按阶段收款
适合持续运营、顾问服务、内容产出、维护和开发迭代等项目。
可选择:
- 按月预收,月末提交当月成果;
- 按月固定日期收款,配合月度服务清单;
- 按阶段收款,每个阶段包含明确成果;
- 设置基础服务费,再对额外需求单独报价。
长期服务不宜只依赖“月底汇总工时”。更稳妥的做法是,每个周期开始前明确本期范围,周期结束时提交成果清单,并把新增需求单独记录。这样,客户确认的是一组可核对的服务结果,而不是模糊的投入时间。
付款节点要与交付动作保持顺序
可以使用以下判断:
如果下一步交付会显著增加你的成本,就不要在上一笔款项尚未确认时自动进入下一步。
例如,客户尚未确认需求范围,却要求你开始完整开发;或者中期成果尚未确认,却要求继续增加功能。此时应先把未确认事项列入待办,并明确下一步工作的前提,而不是默认继续投入。
把客户确认设计成低成本动作
客户拖延验收,有时不是故意拖欠,而是不知道该检查什么,或者需要在团队内部反复转发。你需要把“请确认一下”改成客户容易执行的确认请求。
使用验收清单,而不是开放式提问
交付时可以发送类似信息:
本次提交的是“初版流程”,请在4月15日之前根据以下三项确认: 1. 用户是否可以完成注册、登录和提交表单; 2. 页面中的字段是否与已确认的需求清单一致; 3. 是否存在会阻止测试的错误。 请直接回复“通过”或按“页面—问题—期望结果”的格式列出修改项。未列入本次范围的新增功能,我会单独整理报价和排期。
这段信息包含了成果、检查方式、截止时间和反馈格式,客户更容易给出有效意见。
区分“修改意见”和“新增需求”
验收阶段最常见的现金流风险之一,是客户不断提出新要求,项目却一直无法结束。建议把反馈分成三类:
| 反馈类型 | 判断方式 | 处理方式 |
|---|---|---|
| 范围内问题 | 与已确认需求不一致,或无法按约定使用 | 纳入当前修正 |
| 表达或细节调整 | 不影响主要功能,但需要优化呈现 | 按约定修改轮次处理 |
| 新增需求 | 原范围没有约定,或改变原有方案 | 单独报价、排期并确认 |
发送反馈汇总时,不要只回复“可以修改”。应明确哪些属于当前阶段,哪些会影响费用和工期:
已将反馈分为两组:A组为原范围内问题,安排在本次修订中;B组涉及新增筛选条件和权限逻辑,不属于当前范围。我会在今天提交额外工期和报价,确认后再排入下一阶段。
这样既保持交付推进,也避免用无偿投入换取模糊的“客户满意”。
为每个确认动作留下可追踪记录
口头确认、聊天中的一句“没问题”,在项目进行中可能够用,但不适合作为长期的项目依据。至少要在一个固定位置记录以下内容:
- 提交了什么版本;
- 提交时间;
- 客户反馈截止时间;
- 客户确认的是哪些范围;
- 遗留问题是什么;
- 遗留问题是否影响下一阶段;
- 对应的付款金额和计划日期。
工具可以很简单,电子表格、项目管理软件或固定格式的邮件都可以。关键不是工具功能,而是所有确认信息不要散落在多个聊天窗口中。
建议文件或记录统一命名,例如:
项目名称_阶段名称_版本号_提交日期
每次修改后保留版本号,避免客户和你讨论的不是同一个文件或页面。
用异常分支处理延期和尾款风险
项目表除了记录正常流程,还应该提前写好异常动作。这样遇到客户延期时,不必临时决定是否继续投入。
分支一:客户未按时反馈
处理顺序可以是:
- 在截止日前发送一次提醒,附上验收清单;
- 截止日当天记录“待客户确认”;
- 下一工作日再次发送简短提醒,并说明对排期的影响;
- 超过预设宽限期后,暂停依赖该确认的后续工作;
- 重新排期时,把新增等待时间和资源占用单独记录。
提醒话术可以保持中性:
提醒一下,初版成果目前等待确认。请在4月15日18:00前回复验收结果。若未收到反馈,后续开发将暂缓,新的开始时间需要根据当前排期重新确认。
重点是说明“未确认会发生什么”,而不是只表达焦虑。
分支二:客户反馈不断增加
当反馈数量持续增加时,先暂停逐条答应,改为提交一份范围判断表:
| 反馈 | 是否属于当前阶段 | 对工期的影响 | 处理决定 |
|---|---|---|---|
| 修正已约定页面中的字段 | 是 | 0.5天 | 纳入当前修订 |
| 增加新的筛选条件 | 否 | 1—2天 | 另行报价 |
| 调整已确认的核心流程 | 需重新评估 | 待确认 | 暂停相关开发 |
只有完成范围判断,才能知道项目是否真的接近验收。否则,所谓“最后修改”可能不断扩大,尾款节点也会不断后移。
分支三:交付完成但尾款未支付
尾款管理要区分“未验收”和“已验收未付款”。
如果客户尚未验收,先确认客户是否有具体阻塞问题,并要求按清单反馈。如果客户已经明确确认成果,却没有按计划付款,则应发送包含金额、原定日期和下一步动作的提醒:
记录显示,项目最终成果已于4月25日确认通过,剩余款项为____元,原计划付款日期为4月30日。目前尚未收到到账信息,请于5月7日前确认付款安排。如需调整,请回复预计付款日期。
如果仍无明确回复,可以暂停新增工作、非必要支持或后续排期。涉及合同约定、违约责任或争议处理时,应结合正式合同和专业意见,不要仅凭通用话术作出法律判断。
同时管理多个项目时,按现金节点排优先级
一人公司容易陷入“谁催得急就先做谁”。这种安排可能让你持续投入,却不能改善现金流。多个项目并行时,可以给每个项目增加四个指标:
| 项目 | 下一收款节点 | 预计收款日 | 当前阻塞 | 未来7天所需投入 |
|---|---|---|---|---|
| A | 初版确认后收中期款 | 5月8日 | 等客户确认需求 | 1天 |
| B | 月度服务费 | 5月10日 | 正常推进 | 3天 |
| C | 尾款 | 已逾期 | 等付款安排 | 0.5天 |
每周至少检查一次:
- 未来两周有哪些收款节点;
- 哪些节点依赖客户确认;
- 哪些项目需要继续垫付外部成本;
- 哪些工作虽然紧急,但不会在近期形成收款;
- 是否应该暂停新增范围,先完成可收款的阶段。
排优先级时,不是完全按收款金额排序,还要考虑交付承诺、客户关系和切换成本。但如果一个项目长期占用时间,却没有清晰的确认和收款路径,就应重新评估投入,而不是无限追加工作。
每周复盘这五个指标
现金流管理不只看银行账户余额,还要看项目流程是否正在制造新的风险。
建议每周记录:
- 待验收金额:已经交付但尚未获得客户确认的金额;
- 逾期应收金额:已到付款日但尚未收回的金额;
- 客户等待天数:因客户反馈或确认造成的停滞时间;
- 范围变更次数:未重新报价的新增需求数量;
- 未收款投入:在未收到阶段款前继续投入的工作时间或成本。
这些指标可以帮助你识别问题来源:
- 待验收金额高,说明交付结果或验收方式不清晰;
- 逾期应收金额高,说明付款节点和跟进机制需要调整;
- 客户等待天数高,说明项目排期没有设置确认缓冲;
- 范围变更次数高,说明报价范围和变更流程不够明确;
- 未收款投入高,说明你在用自己的现金流承担客户项目风险。
一套可以直接使用的执行流程
你可以把新项目按以下顺序建立:
项目启动前
- 列出阶段成果;
- 为每个成果写验收标准;
- 设置对应付款节点;
- 标记预付款、中期款和尾款;
- 明确客户反馈渠道和确认截止时间;
- 将新增需求的处理方式写入项目说明或合同。
每个阶段开始前
- 确认本阶段输入是否齐全;
- 确认客户是否已经完成上一阶段验收;
- 检查本阶段预计投入是否与收款安排匹配;
- 将阶段成果、截止日期和付款节点更新到总表。
每次交付时
- 使用固定命名和版本号;
- 附上验收清单;
- 明确反馈截止时间;
- 写出通过、修改和新增需求的区分方式;
- 更新确认记录和下一步动作。
每周经营复盘时
- 检查未来两周的收款节点;
- 处理待验收和逾期项目;
- 暂停没有确认依据的新增投入;
- 重新安排多项目之间的时间;
- 统计实际交付、确认和收款之间的间隔。
项目交付的目标不只是“把东西做出来”,而是让成果、确认和现金回收按可预测的顺序发生。对一人公司而言,一张持续更新的交付与收款表,不能替代正式合同或专业审查,但可以让你更早发现延期、范围膨胀和尾款风险,在继续投入之前作出更清楚的经营判断。





















暂无评论内容