先给结论:按工时计费的SEO服务里,返工归属不看谁改的,而看触发返工的原因落在谁的可控范围内。需求方改口、提供素材延迟或验收标准中途变化,通常算需求方责任;服务方遗漏已确认的检查项、写错实施对象或未按约定口径操作,才算服务方返工。判断的关键证据是变更发生的时间点和当时已确认的书面范围,而不是事后谁更着急。
假设某次SEO服务按工时计费,双方确认的范围是:服务方负责站内模板层的关键词布局与内链调整,需求方负责提供产品分类的最终命名。第一轮交付后,需求方发现分类命名与内部ERP不一致,要求整体重做内链。这里触发返工的原因是需求方未在约定时间前锁定命名,属于需求方责任,额外工时通常应单独计费或从预留缓冲中扣。
反过来,如果服务方在实施时把内链指向了错误模板,而该模板在确认范围里已明确列出,这就是服务方遗漏已确认检查项,返工工时应由服务方承担。两种情况的差别不在工作量大小,而在返工是否由已确认范围之外的变化引起。
把返工拆成触发原因,比争论“谁该付”更有效。可以按下面顺序核对:
这些证据里,时间点和书面范围最容易被忽略。很多争议之所以难判断,是因为双方只记得“改了很多次”,却没记录每次改动的触发点。
有一种常见误判:把“需求方没及时确认”当成服务方效率低。假设服务方按计划完成第一轮,等待需求方确认命名,需求方两周后才回复并同时提出新分类结构。此时服务方重新实施产生的工时,不应算作原报价内的自然延伸,因为原范围里的命名依赖已经变化。若服务方在等待期间没有记录等待状态,后续就容易把等待和重做混在一起,导致归属说不清。
另一种误判是:把“服务方主动优化”当成免费返工。假设服务方在已确认范围外自行调整了站点结构,后来需求方要求恢复。若该调整没有事先确认,恢复产生的工时通常应由服务方承担,因为触发原因是服务方单方面扩大操作范围,而不是需求方改口。
还有一类边界较模糊:需求方在验收时提出“顺便把另一批页面也按同样方式改一下”。如果这批页面不在原确认范围内,它属于新增工作,不是返工。把它计入返工还是新增,会直接影响报价是否追加。更稳妥的做法是把它单列为变更单,而不是混入原工时段。
具体动作是:每次返工前,用一行记录触发事件、发生时间、当时确认范围、责任判断和预计工时。记录格式可以简单到:
触发事件:分类命名变更 / 时间:第一轮交付后第3天 / 原范围:命名由需求方提供 / 判断:需求方责任 / 预计工时:4小时
这个动作的结果会直接影响下一步:如果记录显示多数返工由需求方变更触发,那么后续报价应把缓冲工时单独列出,或约定变更单价;如果记录显示返工集中在服务方遗漏已确认项,那么应先修正内部检查清单,而不是先调价。没有这行记录,双方只能凭印象谈判,按工时计费的报价也很难解释清楚。
按工时计费的SEO服务报价,不必把每种返工都写死,但至少要写清三件事:范围依赖、变更触发条件、返工计时规则。范围依赖包括哪些素材或决策由需求方提供,以及延迟提供时如何处理。变更触发条件指什么情况下算新增工作,例如超出已确认页面数量、更换实施对象或升级验收标准。返工计时规则则说明服务方责任返工不计费,需求方责任返工按实际工时追加或从缓冲中扣。
如果报价单只写“按工时结算”,没有写这些边界,后续每次返工都会回到同一个问题:这算谁的。把它写进报价附件,比事后争论更省时间。假设一个项目预留了10小时缓冲,其中6小时用于需求方变更导致的返工,剩余缓冲不足时再触发追加报价,这种安排能让双方提前知道什么时候需要重新确认预算。
最后提醒一点:返工归属判断不是一次性的。随着项目推进,依赖关系和确认范围会变化,建议在每个交付节点后更新一次记录。这样按工时计费的报价才有可追溯的依据,而不是等到结算时才回头找证据。