公司网络推广：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f4b2cd4189b8.html
📄
公司网络推广：合同内任务和临时救火任务怎样分别排期
结论先说：把合同内任务按“交付节点”排进固定档期，把临时救火任务按“影响面”排进浮动档期，两者共用同一份周排期表但走不同通道。这样做的条件是你能说清每项合同任务的验收物和截止点，且救火任务有明确发起人。如果合同任务本身没有可交付物、只有“持续优化”这类描述，分通道排期会失效，因为没有任何一方能判断谁该让路。
先分清两类任务的不同排期依据
合同内任务的排期依据是验收节点：合同或需求单里写明的页面、内容、账户配置、报告等，有明确的交付时间和验收人。临时救火任务的排期依据是影响面：它影响的是已交付成果、正在进行的交付，还是只是某个人的临时想法。
两类任务不能按同一优先级排队。合同任务延期会触发违约或验收争议，救火任务延期通常只是某个人不满意。把两者混在一张优先级列表里，结果往往是声音大的人赢，而不是节点近的人赢。
固定档期与浮动档期怎么切分时间
一种可操作的做法是按周切分：每周预留固定比例的工时给合同任务，剩余部分作为浮动档期接收救火任务。假设一周可投入的推广执行工时为40小时，合同任务占28小时，浮动档期12小时。数字只是说明切分方法，实际比例按合同任务密度调整。
当浮动档期被救火任务占满后，新进来的救火任务只有两个选择：顺延到下周，或者由发起人书面确认“替换掉某一项合同任务”。这个动作会直接影响下一步——被替换的合同任务必须同步通知验收人并调整节点，否则延期责任会落到执行方。
一个反例：救火任务其实来自合同任务本身
分通道排期有一个常见失效场景：所谓救火任务，其实是合同任务前期埋下的问题。例如合同约定“完成账户结构搭建”，执行时只搭了框架没做否定词和分组，上线后出现大量无效消耗，于是被当成临时救火来处理。
判断方法是对比证据：如果救火任务指向的对象在合同交付清单里能找到对应条目，它就不是临时任务，而是合同任务的返工。返工应占用合同任务的档期，而不是浮动档期。把它放进浮动档期，会让合同任务的真实成本被低估，下一轮报价和排期都会失真。
另一个合理解释也要排除：如果救火任务集中出现在某个渠道，而合同任务里根本没有覆盖该渠道，那它属于范围外新增，应走变更确认，而不是直接塞进浮动档期。
用一张表把判断和动作固定下来
排期前对每项任务做三个判断，判断结果决定它进哪条通道：
- 能否在合同或需求单里找到对应交付物？能找到，进合同固定档期；找不到，进浮动档期。
- 不处理的后果是验收失败还是体验受损？验收失败优先占用合同档期；体验受损可排入浮动档期。
- 发起人是否愿意为“替换合同任务”签字确认？愿意，可插队；不愿意，顺延。
这张表的价值在于把口头优先级变成可核对的依据。当有人质疑排期时，你拿出的不是“我很忙”，而是“这项任务在合同清单第几项、验收人是谁、替换它需要谁确认”。
下一步动作：先补验收物，再谈分通道
如果现在合同任务还停留在“持续做推广”这种描述上，先别急着分通道。第一步是把合同内任务逐条补上验收物和截止时间，哪怕只是内部确认的清单。补完之后再按上面的方法切分固定档期和浮动档期，救火任务才有明确的让路对象。
补不齐验收物的部分，就统一归入浮动档期，并向发起人说明：这部分没有合同节点约束，排期只能按影响面排队。这个动作的结果会直接决定下一轮合同谈判时，你是否需要把“临时响应次数”写成单独条款。
