推广服务：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5a75115161ce.html
📄
推广服务：合同内任务和临时救火任务怎样分别排期
把两类任务排进同一张日历，是推广服务交付失控的常见起点。更稳的做法是：合同内任务按“交付批次”占位，临时救火任务按“响应窗口”插空，并且只有当临时任务影响已承诺批次时才触发重排。判断依据不是谁更急，而是它是否改变了已确认的交付边界。
先分清两类任务在排期上的不同性质
合同内任务的特征是范围、验收标准和交付时间在签约或批次确认时已经锁定，它的排期对象是“工作量加依赖关系”。临时救火任务的特征是发起时间不可预测、范围往往在沟通中才收敛，它的排期对象是“响应时限加可中断性”。
把两者混在一张按小时切分的表里，会出现一个典型现象：救火任务因为看起来只需半小时而被随手插入，但它带来的上下文切换会吃掉前后各一段恢复时间，最终挤压的是合同内任务的连续作业段。因此排期表至少要分成两层：一层是承诺给客户的批次节点，一层是内部预留的响应窗口。
保留、改写还是退出：三种处置的适用前提
当临时救火任务持续出现，先不要急着加人，而是判断它对合同内任务的影响属于哪一档。
- 保留原排期：适用前提是临时任务落在预留响应窗口内，且不需要合同外的新素材、新权限或新决策。此时只需记录消耗，不动批次节点。
- 改写排期：适用前提是临时任务占用了合同内任务的连续作业段，但总量仍可控。做法是把被影响的批次整体后移，而不是把每个子任务零散挪动，否则依赖关系会被打乱。
- 退出或重谈范围：适用前提是临时任务连续多个周期突破响应窗口，且合同内任务的验收节点已经无法靠内部调整保住。这时继续硬排只会同时牺牲两边，应当把新增工作量摆到桌面上重新确认范围或资源。
这三种处置没有优劣，只有前提是否成立。前提判断错了，后面所有排期动作都是白费。
一个可操作的排期动作及其后续影响
具体动作是：在每周排期时，先给合同内任务划出不可侵占的连续时段，再把临时救火任务集中到每天固定的响应窗口，窗口之外收到的救火请求进入次日队列，除非它满足事先约定的升级条件。
这个动作的结果会直接决定下一步：如果一周内响应窗口没有被击穿，说明当前预留量合适，维持原批次即可；如果窗口被击穿但合同内批次未受影响，说明需要扩大响应窗口或提高升级门槛；如果合同内批次已经受影响，说明问题不在排期技巧，而在范围或资源承诺本身，应当进入重谈而不是继续压缩。
假设例子：用一组数字说明判断方法
以下为假设情形，仅用于说明比较方法。假设某推广服务每周可用作业时间为40小时，合同内任务占30小时，预留响应窗口8小时，剩余2小时为缓冲。某一周临时救火任务实际消耗11小时，超出预留3小时，这3小时从合同内任务的连续作业段中扣除。
此时不应直接把合同内任务按比例削减，而应先看被扣除的是否为关键依赖段。若被扣除的恰好是等待外部确认前的准备段，后续批次可以顺延；若被扣除的是必须连续完成的产出段，则整批交付节点都要后移。两种情况的处置不同，证据就在于被占用时段是否位于依赖链的关键路径上。
判断依据：哪些信号说明该改规则而不是改日历
如果出现下面这些信号，说明问题已经超出单次排期调整的范围：临时任务连续多个周期超出响应窗口；救火请求的来源集中在同一类未约定事项；每次重排都需要重新确认验收标准。这些信号指向的是范围约定不清，而不是日历排得不够细。
反过来，如果临时任务只是偶发、且都能在响应窗口内消化，那么保留现有排期结构比频繁改规则更省成本。区分这两种情况，靠的是连续记录而不是单次感受。
把合同内任务和临时救火任务分开排期，本质上是把“承诺”和“响应”当成两种不同的资源来管理。先确认前提属于哪一档，再决定保留、改写还是退出，排期才不会变成每天重来一次的消耗战。
