📍 WDQWDWQD987AAAAA:176.9.85.184
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /cd4a1084cf76.html
📄

网络推广报价：报价按工时计费时怎样判断返工归属

判断返工归属，先看触发原因属于哪一类：需求在开工前已经写清、执行方仍做错，通常算执行方返工；需求中途新增或口径改变，通常算需求方变更。旧内容或旧系统退出时，这个判断尤其容易模糊，因为很多改动是为了保留仍有价值的部分，而不是简单重做。

先给返工分类，再谈谁承担

按工时计费时，最容易出现的争议不是单价，而是同一件事被算了两次。可以把返工分成四类：

• 执行错误：已确认的页面结构、字段或文案被做错，需要重做。
• 需求变更：原本没要求，后来新增模块、改口径或换方向。
• 旧资产适配：旧内容或旧系统与新结构不兼容，需要额外处理。
• 验证不足：上线后才发现问题，但问题在开工前无法从现有资料判断。

执行错误一般由执行方承担；需求变更由提出方承担；旧资产适配和验证不足则要看资料交接是否充分，不能一概而论。

拿一个旧页面走一遍判断流程

假设你手里有一个旧产品页，需要迁移到新结构，同时保留其中仍然有效的案例和说明。执行方按工时报价，你可以这样处理：

1. 把旧页面拆成“保留、改写、删除”三份清单，并注明每部分的处理口径。
2. 要求报价单把工时拆成“结构迁移、内容改写、旧素材清理”三项，而不是一个总数。
3. 开工前确认哪些旧素材需要保留原样，哪些允许替换。
4. 第一轮交付后，只对清单内项目做验收；清单外的新要求记为变更。

这个动作的结果是：返工出现时，你能直接对照清单判断是执行错误还是需求变更，而不是靠感觉争论。下一步的付款节点也可以按“清单内完成”和“变更单确认”分开处理。

旧合作关系退出时，哪些部分值得保留

旧合作关系需要退出时，常见误区是把所有旧内容一起推翻。更稳妥的做法是保留三类资产：

• 仍然准确的说明性内容，避免重新编写。
• 已经验证过的页面结构或字段，减少适配工时。
• 可复用的素材和文件命名规则，降低交接成本。

如果执行方提出“旧系统不兼容，必须全部重做”，应要求对方指出具体不兼容的字段或模块，并说明保留部分需要多少额外工时。若无法指出具体位置，这项返工更接近执行方对旧资产适配估计不足，而不是需求方新增要求。

用变更单切断循环返工

按工时计费最怕无限循环：改一点、验一点、再改一点，工时不断累积。可以在合作开始时约定一个简单规则：

• 清单内的问题，执行方修正，不计新增工时。
• 清单外的要求，先写变更单，注明新增工时和影响范围，确认后再做。
• 同一问题第二次出现时，先判断是修正未完成还是新要求，再决定是否计费。

这个规则的实际作用是，把“返工归属”从口头争论变成可核对的记录。你下一步要做的，是在验收时只对照变更单和原始清单，而不是重新讨论整体方向。

哪些证据能支持你的判断

如果双方对返工归属有分歧，可以看这几类证据：开工前的需求文档或聊天记录、报价单里的工时拆分、变更单、验收记录。缺少这些记录时，旧资产适配和验证不足更容易被算成需求方变更。反过来，如果执行方无法说明返工对应的具体清单项，就更接近执行错误。

假设一个场景：旧页面迁移报价按 20 小时计，第一轮交付后你要求保留的案例区被删掉。若案例区在开工前已列入“保留”清单，这属于执行错误，修正不应新增工时；若案例区是交付后你才提出保留，则属于需求变更，应走变更单。这个比较方法只用于说明判断逻辑，不构成对任何具体报价的承诺。

把保留清单、变更单和验收记录放在同一处，返工归属就不再依赖事后回忆，而是可以在下一次报价前直接核对。