百度推广托管合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9df7ec616efc.html
📄
百度推广托管合同内任务和临时救火任务怎样分别排期
把合同内任务和临时救火任务放在同一张排期表里，通常会导致两种结果：要么救火任务挤掉合同交付，要么合同任务占满工时后救火被无限延后。更可操作的做法是给两类任务设不同的进入通道：合同内任务按交付周期排入固定档期，临时救火任务只走当日响应池，并且用“是否影响账户当日可投放状态”作为分流依据。前提是双方已经明确合同内任务的验收标准和临时任务的计费或次数上限，否则分流规则无法执行。
先判断这次变化属于哪一类：交付节奏变了，还是故障性质变了
排期冲突往往不是任务变多，而是任务性质变了。需要先区分两种变化：
- 交付节奏变化：合同约定的账户搭建、结构优化、素材更新、数据报告等任务，因为业务活动、产品上新或预算调整，需要在更短时间内完成。这类任务仍然属于合同范围，只是时间被压缩。
- 故障性质变化：账户突然出现消费异常、落地页无法访问、审核被拒导致计划停投、转化数据断档等，需要当天甚至数小时内处理。这类任务不属于原定交付节奏，属于救火。
判断依据不是任务大小，而是不处理会不会导致当天投放无法正常进行。会，就是救火；不会，就回到合同排期里重新分配优先级。这个判断要在接需求时完成，而不是等到排期表已经排满再讨论。
条件一：合同内任务占主导时，用固定档期加缓冲位
当一段时间内临时救火很少，主要矛盾是合同任务按时交付，排期应偏向固定档期。具体动作：
- 把合同内任务拆成以周为单位的交付项，每项写明交付物、验收人和最晚确认时间。
- 每周预留一个缓冲位，不安排具体交付内容，只用于吸收临时插入的小任务。缓冲位被占用后，当周不再接受新的非故障需求。
- 临时救火任务进入当日响应池，处理完成后记录耗时。如果连续两周救火耗时超过缓冲位，说明合同排期本身留白不足，需要重谈交付节奏，而不是继续压缩合同任务。
这个动作的结果会直接影响下一步：缓冲位够用，说明当前排期结构成立；缓冲位持续被击穿，说明需要调整合同内的交付周期或增加人力，而不是靠加班消化。
条件二：临时救火频繁时，先隔离响应池再谈合同排期
当救火任务每天或隔天出现，固定档期会被反复打断，此时继续按原合同排期推进，合同任务的实际完成时间会不断后移，且双方对“为什么没交付”的判断不一致。应先把救火任务隔离出来：
- 设定当日响应池的容量，例如每天最多处理两个救火任务，超出部分按紧急程度排序，并明确告知哪些要顺延到次日。
- 救火任务不占用合同任务的验收时间点，但占用缓冲位；缓冲位耗尽后，合同任务的交付时间顺延，顺延规则提前写进协作约定。
- 每周统计救火任务的来源：是账户本身不稳定、落地页或技术问题，还是业务方临时新增投放需求。来源不同，处理方式不同——技术类问题要找根因，需求类问题应回到合同变更流程。
这里有一个容易误判的地方：救火任务减少，不一定说明排期变好了。也可能是业务方因为响应慢而不再提需求，或者把需求转到了其他渠道。要看的是救火任务的处理时长和合同任务的按期交付率是否同时改善，而不是只看数量。
两种排期方式的分界线和例外
分界线可以概括为：合同内任务按交付周期排，临时救火任务按响应时限排，两者共用缓冲位但不共用优先级。合同任务不能因为救火多就默认无限顺延，救火任务也不能因为合同排期满就默认不处理。
例外情况需要提前约定：
- 涉及账户安全、资金异常或合规风险的临时任务，优先级高于所有合同任务，处理完后当天重新评估合同排期。
- 合同内任务如果本身包含紧急支持条款，按条款执行，不重复计入救火响应池。
- 业务方临时新增的投放需求，如果不属于故障，应走合同变更或单独计费，不默认塞进救火通道，否则救火通道会被日常需求占满，真正的故障反而排不进去。
一个假设例子：某账户合同约定每周完成一次结构优化和一次数据报告。某周业务方临时要求增加一组新计划，同时账户出现审核被拒导致停投。按上述规则，审核被拒进入当日响应池，当天处理；新增计划属于合同外需求，要么排入下周缓冲位，要么单独确认工作量。如果两者都塞进当周，结构优化和数据报告必然顺延，而顺延原因在事后很难说清。把分流规则写在排期表最上方，每次接需求时先归类，再决定进哪个通道，后续的交付争议会明显减少。
