百度推广服务：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3d3aa4202246.html
📄
百度推广服务：合同内任务和临时救火任务怎样分别排期
把两类任务放进同一张排期表，通常不是效率问题，而是判断标准缺位：合同内任务按交付节点倒排，临时救火任务按影响面和恢复条件插队，两者用不同的优先级口径，而不是谁催得急谁先做。下面以你手里那份正在执行的推广服务排期表为对象，说明怎么改。
先给两类任务各定一条准入线
合同内任务指服务范围、交付物和验收标准已经写进合同或确认单的工作，比如账户结构梳理、计划与单元搭建、落地页承接检查、阶段性数据复盘。临时救火任务指合同未列明、但当下影响投放连续性或数据可读性的突发事项，比如预算突然被异常消耗、转化回传中断、落地页无法打开。
准入线要写成一个可判断的句子，而不是感觉。合同内任务问：这件事是否对应合同里的某个交付物或验收项？临时任务问：如果今天不处理，是否会直接造成花费浪费、数据断档或无法归因？两条都答不上来的，进待办池，不占排期。
排期表要拆成两条泳道，而不是一张长清单
常见做法是把所有事按日期排成一条线，结果救火任务一插进来，合同内任务整体后移，月底交付集中爆掉。更稳的做法是两条泳道并行：
- 合同内泳道：按交付节点倒排，每个节点前留出内部检查时间，节点之间允许整体平移，但不允许单个节点被无限压缩。
- 救火泳道：只放当期确认的突发事项，每条标注影响面、临时处置动作、恢复确认方式，处理完当天或次日回填到复盘记录。
两条泳道共用同一批人力时，必须明确一条规则：救火任务占用的是预留缓冲，而不是直接挪合同内任务的工时。缓冲用完了，就要在两条泳道之间做显式取舍，而不是默认合同内任务继续让路。
用可核对的证据区分“真救火”和“看起来像救火”
这里最容易出现与直觉相反的结果：临时任务数量突然上升，排期被打乱，第一反应往往是“需求变多了，得加人”。但这个现象至少还有另外几种合理解释，需要先分辨：
- 合同内任务的验收标准没写清，导致反复返工，被当成了新增救火。
- 数据回传或落地页问题一直存在，只是最近才被注意到，属于补课而非新增。
- 对接人换人后口径变化，旧任务被重新提了一遍。
可核对的证据包括：任务提出时间与合同交付节点的对应关系、同类问题在过去几周是否重复出现、每次处理前后的数据是否可对比。如果同类问题反复出现且都能追溯到同一个未验收项，那它应该回到合同内泳道解决，而不是长期占用救火通道。
一个注明假设的短例子
假设某次推广服务排期表里，本周原定完成两个单元的落地页承接检查，同时出现一条“预算消耗异常”的临时任务。若直接让合同内任务整体后移，检查被推到下周，而下周又可能叠加新的临时事项，节点就会持续顺延。
按两条泳道处理：先确认预算异常的影响面（是否集中在某个计划、是否伴随点击或转化数据异常），用预留缓冲做临时处置，记录处置时间和恢复确认方式；合同内检查按原节点保留，只在缓冲耗尽时才做显式取舍。这样做的结果是，救火任务有明确收口，合同内任务的节点不被静默吞掉，下一步排期依据的是记录而不是印象。
每周固定一次核对，决定下周怎么排
排期不是排一次就固定。建议每周用同一份表做一次核对：合同内任务看节点是否仍可达成，救火任务看是否有重复项可以归并回合同范围。核对时只问三件事：本周救火占用了多少缓冲、合同内节点是否有被压缩、重复出现的救火是否该转为合同内交付项。
这三个答案会直接改变下周的排法：缓冲充足就按原节点推进；重复项多就把它们写进合同内泳道并明确验收标准；缓冲耗尽且合同节点不可让，就要在两条泳道之间做一次明确的取舍决定，并把决定写进记录，而不是等到月底再解释为什么没交付。
