点击付费：内部工时怎样计入自建方案的真实成本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4e8ece9f9992.html
📄
点击付费：内部工时怎样计入自建方案的真实成本
结论先说：内部工时能不能计入自建方案，取决于你打算用它回答哪一个问题。如果只是比较“这个月现金流出多少”，内部工时不该算进去；如果要决定“这条自建路线值不值得长期走下去”，就必须算，而且要用可核对的口径算，否则你比较的其实是两种不同的东西。下面给出一个可落地的折算方法，再说明什么情况下这套方法会失效。
先分清你要回答的是现金流问题还是取舍问题
自建点击付费投放系统或自建落地页、自建报表，都会消耗内部人力。争议往往出在同一个事实上：财务看到的是没有现金支出，业务负责人看到的是团队被占满。两者都没错，只是口径不同。
- 现金流口径：只统计实际对外支付的费用，例如服务器、第三方数据接口、外部开发外包。内部工时按零计入。
- 取舍口径：把内部工时按一个明确的小时成本折算，与外部方案的总支出放在同一张表上比较。
如果你要做的是一次预算审批，用现金流口径更合适；如果你要决定是否长期保留自建能力，用取舍口径。混用会导致结论反复摇摆——同一件事在两次会上得出相反的答案。
把工时转成可核对数字的三个动作
折算不需要精确到分钟，但必须让不同角色能核对。建议按下面三步走。
- 先记录角色和任务，不记录感受。把投入拆成“谁在做什么”，例如投放人员每周调账户结构、开发人员改一次数据回传、运营人员核对一次对账。只写任务名和承担角色。
- 给每个角色一个内部小时成本。可以用该角色月人力成本除以当月可用工时，得到一个注明假设的数字。这个数字是内部约定，不是市场报价，写清假设即可。
- 把一次性投入和持续投入分开列。搭建期的工时是一次性的，之后每周的盯盘、修数据、处理异常是持续的。持续部分乘以你打算运行的时间长度，才是可比的总量。
做完这三步，你会得到一张能被人反驳的表。可被反驳是关键：有人不同意小时成本假设，可以改数字重算，而不是笼统地说“这个方案更省”。
一个注明假设的短例子
假设某团队要自建一套点击付费的数据汇总流程，搭建期投入开发 40 小时、运营 10 小时；上线后每周维护 3 小时，计划运行一年。再假设内部小时成本统一按 100 元折算。
那么一次性部分为 50 小时，持续部分为 3×52=156 小时，合计 206 小时，折算约 20600 元。这个数字再与外部方案的对外支出相加后比较。注意：这里的 100 元和运行一年都是假设，换掉任何一个，结论都可能变化。如果只运行三个月，持续部分只有 39 小时，一次性投入的权重就会明显上升，自建反而更不划算。
什么情况下这套折算会失效
反例很明确：当内部人力本来就有大量闲置，且这些闲置时间无法转作他用时，把工时按小时成本计入会高估自建的真实代价。此时团队投入的是“反正也空着的”时间，机会成本接近零。反过来，如果这些人本来在做能直接带来收入的工作，被抽调去做自建，那部分被放弃的产出才是真正的成本，而且往往比小时成本更高。
所以判断标准不是“有没有花时间”，而是“这些时间有没有更好的去处”。没有更好去处时，工时折算会让自建显得比实际更贵；有更好去处时，只算现金支出会让自建显得比实际更便宜。
下一步动作：把分歧变成一张待确认清单
不要试图在会上说服对方接受某一种口径。改为输出一张清单，列出所有存在分歧的假设：小时成本取多少、运行周期多长、哪些任务算一次性、哪些算持续、闲置人力是否计入。每个假设后面写清由谁确认。
只要这些假设被逐条确认，工时折算就不再是立场之争，而是一组可以重算的参数。之后每次结论变化，都能追溯到是哪个假设变了，而不是重新吵一遍。这也是把内部工时计入自建成本时，唯一能长期用下去的做法。
