seo工作室：合同内任务和临时救火任务怎样分别排期，假设情境：旧站改版未收尾，又来了三个救火需求
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /68051f7d801d.html
📄
seo工作室：合同内任务和临时救火任务怎样分别排期，假设情境：旧站改版未收尾，又来了三个救火需求
合同内任务按交付节奏排，临时救火任务按影响面排，两者不放在同一张优先级表里。一个可行做法是：合同任务占用固定产能，救火任务只占用预留缓冲，超出缓冲的救火需求必须回到合同变更或明确拒绝。下面用一个假设情境说明怎么落地。
假设情境：旧站改版未收尾，又来了三个救火需求
假设一家seo工作室与客户签了季度合同，约定每月完成一批栏目页优化和旧内容清理，旧站改版上线后部分页面收录异常，客户同时提出三个临时需求：修复跳转、重写被删掉的旧文、加一批新词落地页。合同任务有验收节点，救火任务没有明确截止。此时如果按“谁催得急谁先做”排期，合同节点必然被挤压，救火也会变成无限追加。
这里的关键不是判断哪个更重要，而是先确认两类任务的性质不同：合同内任务是已承诺的交付，救火任务是未承诺的额外投入。把两者混排，等于用合同产能补贴临时需求。
第一步：把合同任务拆成可占用的产能块
不要按“本周做A、下周做B”排，而是按人天或半天块划分。假设合同约定每月二十个工作日中投入十二个用于合同任务，那就把这十二个拆成固定块，例如：
- 四个半天用于旧内容清理与重写
- 三个半天用于栏目页优化
- 两个半天用于数据复查与验收准备
- 剩余半天作为合同内的机动
这些块在排期表里是锁定的，临时需求不能直接占用。动作是先把合同产能写死，结果是救火需求只能从缓冲里出，排期冲突立刻可见，而不是等到交付前才发现做不完。
第二步：给救火任务设缓冲，而不是设优先级
救火任务最大的问题是每一条都显得紧急。更稳的做法是预留固定缓冲，例如每周留出两个半天专门处理临时问题，并按影响面排序：
- 影响收录或可访问性的问题，优先于内容质量类问题
- 影响范围覆盖多个页面的问题，优先于单页问题
- 有明确截止且与合同验收直接相关的问题，优先于口头催促
缓冲用完后，新的救火需求只有两个出口：一是转入合同变更，重新约定交付内容和时间；二是明确拒绝或延后。动作是公开缓冲余量，结果是客户能看见救火不是无限供给，后续沟通会从“催”转向“换”。
第三步：用一条判断规则区分插单和改范围
临时救火任务不一定都要接。可以用一条规则区分：如果任务属于合同已约定交付的修复义务，走合同内排期；如果任务超出合同范围，走变更流程。假设合同只约定内容优化，没有约定跳转修复，那么跳转修复就是额外任务，需要单独确认投入和交付时间。
这条规则的作用是防止救火任务悄悄变成合同内任务。动作是每次接到临时需求先问一句：这是合同里已经承诺的吗？结果是排期表不会因为口头承诺而不断膨胀。
第四步：旧内容退出时，保留可复用部分再排期
旧内容清理常被当成一次性删除，但更稳的做法是先判断哪些部分仍然有价值。假设旧栏目里有一批页面流量低但外链多，直接删除会损失已有引用，这时可以保留URL并做内容更新，而不是全部退出。动作是先标记“保留、合并、退出”三类，结果是合同任务里的清理工作量会下降，腾出的产能可以吸收一部分救火需求。
这一步也影响排期：如果旧内容需要合并，合同任务会增加重定向和内容整合的工作；如果直接退出，救火任务可能增加，因为客户会追问丢失的页面。两种选择成立的条件不同，取决于旧内容是否还有外链、是否有转化路径、是否与当前业务相关。
第五步：每周复查一次，按证据调整下一轮排期
排期不是一次定死。每周复查时看三个信号：合同任务是否按块完成、救火缓冲是否被耗尽、旧内容退出后是否出现新的异常。如果合同任务连续两周未完成，说明合同产能被高估，需要重新协商交付节奏；如果救火缓冲连续两周未用完，说明缓冲可以缩减，把产能还给合同任务。
复查的依据是实际完成情况，不是感觉。动作是记录每类任务的实际耗时，结果是下一轮排期可以用真实数据调整，而不是继续拍脑袋。需要说明的是，收录量或抓取量下降可能有多种解释，不能单独证明某次排期调整正确，仍需结合日志、页面状态和合同交付记录一起判断。
