很多一人公司在报价前只估算“制作需要几个小时”，却没有计算沟通、修改、项目切换和等待回款占用的时间。结果是订单越多越忙，现金流却没有同步改善。更稳妥的做法是先完成一次容量核算：确认自己每周能稳定交付多少工作，再根据交付容量决定报价、排期和接单上限。

先区分三个数字：可用时间、交付时间和现金回款

容量核算不是简单地把一个月的日历时间全部卖出去。至少要区分以下三个数字：

例如，你每周理论上能工作 40 小时，但其中有客户沟通、销售、行政、开票、学习和突发事项。真正用于项目交付的时间可能只有 24 至 28 小时。

因此，报价前要问的不是“这个项目制作要几小时”，而是：

这个项目会占用我多少总工作容量？它什么时候能转化为现金？如果出现返工，我是否还有余量稳定交付？

第一步：计算每周有效工作时长

先用一个相对保守的公式计算：

有效工作时长
= 理论工作时长
- 沟通与会议
- 销售与获客
- 行政与财务
- 学习与维护
- 预留缓冲

假设一周安排 40 小时，可以这样拆分：

这 18 小时才是本周可以承诺给客户的交付容量。

如果你刚开始接单，还没有稳定数据，可以先连续记录两到四周。不要凭感觉填写，而是记录每项工作实际花费的时间。特别要把以下事项单独记出来：

• 需求沟通和会议；
• 阅读资料、整理素材和确认权限；
• 报价、合同、收款跟进；
• 项目管理、排期和状态同步；
• 交付后的修改；
• 因客户延迟反馈造成的等待和重新进入项目状态的时间。

记录的目的不是把每分钟都管理起来，而是避免把隐形工作误认为“免费时间”。

第二步：把制作工时改成项目总工时

项目制作工时只是成本的一部分。报价前可以使用下面的估算方式：

项目总工时
= 制作工时
+ 沟通工时
+ 项目管理工时
+ 返工工时
+ 切换与等待损耗

例如，一个网页开发项目预计需要 20 小时编码，实际可能还包括：

• 需求确认：3 小时；
• 页面和素材沟通：2 小时；
• 测试与上线准备：4 小时；
• 项目管理：2 小时；
• 修改和返工：5 小时；
• 项目切换与等待损耗：2 小时。

那么项目总工时是：

20 + 3 + 2 + 4 + 2 + 5 + 2 = 38 小时

如果你只按 20 小时报价，相当于主动承担了近一半未计价工作。项目看起来成交了，实际却可能挤占了其他订单和获客时间。

用历史数据修正，而不是一开始追求精确

前几次估算不可能完全准确。你可以在每个项目结束后记录：

实际总工时 ÷ 原计划总工时 = 工时偏差系数

如果连续三个项目的系数分别为 1.3、1.5 和 1.4，可以暂时用 1.4 作为同类项目的估算系数：

预计项目总工时
= 初步制作工时 × 工时偏差系数

这里的系数不是永远固定的。项目类型、客户熟悉程度、需求清晰度和交付标准发生变化时，应重新观察。

第三步：用返工率设置交付缓冲

返工率不能只理解为“客户要求修改了几次”，更重要的是返工占用了多少额外工时。

可以这样计算：

返工率
= 返工工时 ÷ 首次交付前的计划工时 × 100%

例如，某类项目前三次交付数据如下：

返工率约为：

12 ÷ 54 ≈ 22%

如果你还没有足够历史数据，可以暂时按照项目复杂度设置内部缓冲：

• 需求清晰、交付标准固定的项目：预留较小缓冲；
• 客户参与度高、反馈轮次多的项目：预留中等缓冲；
• 需求容易变化、涉及多人决策的项目：预留更大缓冲。

缓冲不一定全部写成“额外收费”。它至少要体现在排期和接单上限中。否则，一次返工就可能让下一个项目延期。

报价时要先定义返工边界

返工率高，往往不只是执行效率问题，也可能是交付边界不清。报价单或项目说明中，至少要写清：

1. 交付物包含什么；
2. 不包含什么；
3. 客户可以提出几轮集中反馈；
4. 每轮反馈的提交方式和时间；
5. 需求变化如何重新估算；
6. 客户延迟反馈是否影响原定排期。

这样做的目的不是拒绝合理修改，而是把“原范围内的返工”和“新增需求”区分开。

第四步：计算并行项目上限

一人公司不适合只看项目数量。两个小项目可能比一个大项目更消耗精力，因为每个项目都有独立的沟通、等待和切换成本。

可以采用“容量点”而不是只计算项目个数。

项目容量点
= 预计项目总工时 ÷ 每周有效交付时长

假设你每周有 18 小时有效交付时长：

• 项目 A 预计需要 18 小时，占 1 个容量点；
• 项目 B 预计需要 9 小时，占 0.5 个容量点；
• 项目 C 预计需要 27 小时，占 1.5 个容量点。

如果你同时接下 A、B、C，总需求是 3 个容量点。即使项目可以并行，也需要至少三周的有效交付时间，还要考虑客户反馈是否重叠。

给并行项目留出上限

并行项目数量可以从三个维度判断：

对一人公司来说，项目管理的风险通常不是“没有事情做”，而是同时承诺了太多不同阶段的事情。可以把项目分为以下状态：

• 待启动：已成交但资料或预付款未齐；
• 进行中：当前正在消耗交付容量；
• 待反馈：等待客户确认，但仍可能需要后续处理；
• 待验收：主要工作完成，尚未正式结束；
• 已完成待回款：交付完成但现金尚未到账。

只有“待启动”和“进行中”的项目，才适合纳入近期排期；“待反馈”和“待验收”则要保留缓冲，不要把相关时间再次承诺给新客户。

第五步：把报价和最低可接受时薪连接起来

报价不应只由市场行情或竞争对手决定，还要覆盖你的有效工作时间、经营成本和风险。

可以先计算内部最低可接受时薪：

最低可接受时薪
= 目标经营收入 ÷ 可售有效工时

其中，可售有效工时不是全部有效工作时长。假设每月有 80 小时可以用于交付，但为了应对淡旺季、取消、返工和空档，只计划售出其中 60 小时，那么就应使用 60 小时计算，而不是 80 小时。

项目报价可以这样核算：

项目报价底线
= 项目总工时 × 最低可接受时薪
+ 项目直接成本
+ 风险缓冲

这里的项目直接成本可以包括外包、素材、软件增购或其他为该项目专门发生的支出。本文不展开税率和地区财税政策，但你仍然应把经营中必然发生的成本纳入自己的内部模型。

一个简化示例

假设：

• 项目初步制作工时：24 小时；
• 沟通和项目管理：6 小时；
• 返工缓冲：6 小时；
• 切换损耗：2 小时；
• 最低可接受时薪：300 元；
• 项目直接成本：800 元。

那么：

项目总工时 = 24 + 6 + 6 + 2 = 38 小时
报价底线 = 38 × 300 + 800 = 12,200 元

如果客户预算只有 7,000 元，不要立刻用“压缩制作时间”的方式迁就。你可以重新拆分范围：

• 减少交付页面或功能；
• 减少反馈轮次；
• 延长交付周期；
• 改为分阶段交付；
• 将部分服务改成客户自助完成。

如果范围无法减少，报价低于底线就意味着你需要主动承担差额。这个决定可以做，但要明确它是一次性的战略选择，而不是把亏损误判为正常报价。

第六步：把回款周期纳入接单判断

利润不等于现金流。一个项目即使账面上有利润，如果回款时间过长，也可能让一人公司在下个项目开始前缺少现金。

报价前至少记录四个时间点：

1. 签约或确认时间；
2. 开始投入工作的时间；
3. 完成交付的时间；
4. 实际收到款项的时间。

然后计算：

现金占用周期
= 实际回款日 - 开始投入工作的日期

如果一个项目需要你先投入 40 小时，客户在交付后 60 天才付款，那么你不仅承担了交付风险，也承担了这段时间的现金占用。

用回款结构降低风险

可以根据项目规模和客户合作记录，设计不同的回款节点，例如：

• 启动前支付一部分，确认资源和排期；
• 阶段性交付时收取阶段款；
• 最终交付或验收时收取尾款；
• 长期服务按月或按阶段结算。

具体比例应结合你的业务模式、合同安排和客户关系确定。核心原则是：不要让自己在尚未收到任何款项的情况下，先投入全部交付容量。

接单前可以检查：

用一张表完成报价前容量核算

你可以在报价前填写下面这张表：

最后给项目做一个简单判断：

如果剩余容量足够
且返工后仍有缓冲
且回款周期可承受
且报价不低于内部底线
→ 可以接单

如果只有一个条件不满足
→ 调整范围、价格、排期或回款节点

如果多个条件不满足
→ 暂不接单，或重新设计项目

每周复盘一次，持续修正容量模型

容量核算不是一次性的报价工具，而是项目管理的基础数据。每周可以用 20 分钟复盘：

• 本周实际交付了多少小时？
• 哪类沟通最容易超时？
• 哪类项目返工率最高？
• 哪些项目占用时间长但回款慢？
• 哪些工作可以模板化或交给工具辅助？
• 下周是否有足够缓冲处理延期和突发事项？

当你连续几周发现有效交付时长被高估，就降低接单上限；当你发现大量时间被重复沟通占用，就优化需求表、交付模板和反馈流程；当某类项目反复返工，就重新定义服务范围和验收标准。

接单上限不是收入上限，而是稳定交付的边界

一人公司的报价，最终卖出的不只是制作成果，还包括你的判断、沟通、排期、责任和交付确定性。只按制作工时报价，会把这些工作隐藏起来；只看合同金额，则会忽略现金回款的时间差。

更可靠的顺序是：

1. 先算每周有效交付容量；
2. 再估算项目总工时和返工缓冲；
3. 检查并行项目是否超过注意力上限；
4. 把回款周期纳入现金流判断；
5. 最后决定报价、排期和是否接单。

当你能稳定交付多少已经清楚，报价就不再只是“客户愿意付多少”的猜测，而会变成一个同时考虑时间、风险、现金流和经营边界的决策。忙碌本身不是经营成果，能够在可承受的容量内持续交付，才是更值得追求的接单上限。