百度广告收费标准，报价按工时计费时怎样判断返工归属
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d0e4223ceb42.html
📄
百度广告收费标准，报价按工时计费时怎样判断返工归属
判断返工归属，核心不是看谁先提出修改，而是看这次返工是否推翻了已经书面确认的范围。若修改针对的是已确认的账户结构、关键词清单或创意版本，且改动由需求方新增要求引起，通常应由需求方承担；若返工源于服务方未按确认口径交付或交付物本身有错误，则应归服务方。把“确认”和“变更”分开记录，是把分歧转成可核对项目的起点。
先确认两种计费条件：封闭范围与开放范围
按工时计费时，报价通常落在两种条件里，判断返工归属的方式完全不同。
条件一：封闭范围。双方在开工前把交付物写清楚，例如账户搭建、投放计划、创意初稿和一次集中修改。此时工时报价对应的是一个确定边界。边界内的正常调整属于服务方成本，边界外新增的需求才另计。判断返工是否归属需求方，看它是否改变了已确认的交付物清单。
条件二：开放范围。只约定按小时单价结算，不锁定具体交付物，适合方向尚不明确、需要边做边调整的项目。此时返工是否计费，取决于改动是否由需求方主动改变方向引起。若是服务方自己理解偏差导致重做，即使范围开放也不应计入需求方工时。
两种条件的差别不在单价高低，而在“确认”这个动作发生在哪里。封闭范围靠交付清单确认，开放范围靠每次方向变更的书面确认。
把分歧转成可核对的项目：三个动作
当多个角色对同一笔返工有不同理解时，不要停留在“这算不算改需求”的争论上，而是把它拆成可以逐项核对的事实。
- 固定基线。把返工前最后一次确认的版本单独保存，标注确认时间和确认人。没有基线，就无法判断改动是修正还是新增。
- 记录变更来源。用一句话写明这次改动由谁提出、针对哪个已确认项、改动的理由。例如“需求方要求在已确认的关键词清单外增加一组新词”，这比“又改了一版”更能决定归属。
- 区分错误与变更。交付物不符合已确认标准，属于错误；交付物符合标准但需求方想换方向，属于变更。前者归服务方，后者归需求方，这是最容易被混为一谈的一步。
做完这三步后，再回看工时记录。如果返工对应的是“错误”，服务方应自行承担；如果对应的是“变更”，则按约定单价计入需求方。这个动作的结果会直接决定下一步是继续按原范围推进，还是先补一份变更确认再开工。
一个注明假设的短例子
假设某项目约定按工时计费，交付物包括账户结构、关键词清单和创意初稿，并含一次集中修改。初稿提交后，需求方认为某组关键词方向不对，要求整体替换。核对记录发现，原关键词清单已经确认，替换属于方向变更而非交付错误，因此这次返工应归需求方，按工时另计。反过来，如果初稿遗漏了已确认的关键词清单中的一部分，导致重做，则属于服务方错误，不应计入需求方工时。这个例子的关键不是金额，而是先判断改动是否推翻了已确认项。
例外情形：什么时候不能简单按上述规则分
有几种情况会让归属判断变复杂，需要单独处理。
- 确认本身含糊。如果确认时只写了“方向可以”，没有落到具体清单，后续任何改动都难以判断归属。此时应先补确认，再谈返工计费，否则双方各执一词。
- 返工由外部条件变化引起。例如投放目标或预算口径中途调整，既不是服务方错误，也不是需求方随意变更，而是前提变了。这类返工应按新增阶段处理，重新确认范围后计价。
- 工时记录不完整。如果只有总工时，没有按任务拆分，就无法把某次返工对应到具体事项。这种情况下，先补记录再结算，比直接争论归属更有效。
这些例外的共同点是：缺少可核对的项目。归属判断依赖的是记录，而不是印象。
把归属规则写进报价确认里
与其在返工发生后争论，不如在确认工时报价时就把归属规则写清楚：哪些属于已确认范围、变更如何提出、错误如何认定、变更后工时如何计入。这样做的结果不是消除所有分歧，而是让分歧有据可查，下一步该由谁承担、该不该继续开工，都能从记录里直接读出，而不是靠反复协商。
