交期要晚了，该在哪个节点说

结论先行：交付延误带来的损失，很大一部分不是延误本身造成的，而是「客户从别人嘴里知道」造成的。同一个坏消息，在进度还没完全失控时说出来，客户有时间调整上线计划、错开业务高峰、或者先启用备用方案；等到交付日当天才说，客户能做的只剩追责。可行的做法是把告知拆成三个节点——进度异常的预警节点、无法挽回的确认节点、延误结束后的复盘节点，每个节点说不同的话，写不同的材料。

本文只谈交期出问题时什么时候告知、告知什么内容，不谈延误的违约金与赔偿标准怎么定，也不谈投诉受理之后头几个小时该做哪些即时动作。

为什么晚说是常态

延误被瞒到交付日，通常不是有人故意隐瞒，而是三个很自然的心态叠在一起。

其一，还抱着能追回来的侥幸。项目里的延误很少一次跳出一大截，多是每天落后一点点。落后一天的时候，团队的本能反应是「明天加个班就补回来了」，这个判断在头几次往往是对的。等到确认补不回来，已经落后一两周。

其二，说不出口的成本被高估了。项目负责人担心一开口就被扣分、被追责、被换掉，于是倾向于再等等。这个判断忽略了一件事：早说时，责任还在「进度管理」这一层；晚说时，性质变成「隐瞒」，两者的后果完全不同。

其三，客户侧没有一个明确的收报文节点。合同里通常写的是交付日期，而不是「每周同步一次进度」。没有约定的同步节奏，就没有必须开口的时刻。

第三条是少数能靠机制解决的，也是本文的重点。

三个节点，各自说不同的话

把告知拆成三个节点，每个节点有独立的触发条件和材料形态。

三个节点里，预警节点最容易被跳过，因为它看起来「还没到要说的时候」。而它恰恰是客户最需要的那个——客户在预警阶段还能改主意，在确认阶段只能接受。

预警节点的判断标准要写清楚，否则每个人对「该不该说」的理解都不一样。一条可用的口径是：关键路径上的任务落后，且在现有资源投入下算不出追回方案。这句话有两个限定，都不难判定：关键路径可以看甘特图，算得出算不出可以问执行人。只要这两条同时成立，就该发预警，不必等到「确定要延误」。

预警要说到什么程度

预警阶段的常见错误，是把话说得太满——「我们正在全力推进，预计影响不大」。这句话有两个问题：一是它给出了一个乐观结论，而这个结论很快就可能被推翻；二是它没有提供任何可执行信息。

预警阶段该说三样东西。

慢在哪个环节。不是「整体进度有点慢」，而是「某类设备的到货比计划晚了若干天」「某个环境的联调还没开始」。具体到环节，客户才知道会不会影响自己的哪一项工作。

现有补救方案及其结果。补救方案一般不止一个，每个方案对应一个结果。比如：方案一按原范围交付，交期顺延若干天；方案二缩小首期范围先上线核心部分，剩余部分后补；方案三客户侧配合调整某个前置条件，可以压缩一部分时间。三个方案摆出来，客户就从「被告知」变成「一起选」。

需要客户做什么决策、什么时候之前定。这一句最容易被漏。客户不知道要在什么时候之前拍板，方案就摆在那里等，时间又过去了。

确认阶段：新交期必须带前提

到了确认阶段，真正有意义的输出是一个带前提的新交期。

不带前提的新交期等于第二次失约。行业里比较稳妥的写法是三段：新的完成日期、这个日期成立需要满足的前置条件（几条，逐条可判定）、以及条件不满足时的顺延规则。

前置条件要写得能被判定。比如「原厂工程师在某日前完成现场支持」是可判定的，「各方配合到位」不是。顺延规则也要写：某个前置条件晚了一天，新交期跟着顺延几天，还是不受影响——这一条如果提前写清，后面就不会有第二次争执。

确认阶段还要附一份影响清单：哪些业务动作会受影响、影响多长时间、有没有临时替代方案。这份清单是给客户内部用的——他需要向上解释，而解释需要材料。服务方替客户准备好这份材料，比自己解释十遍都有用。

这个阶段最容易说错的三句话

三句话在任何阶段都不该出现。

「应该下周就能好。」「应该」加一个时间点，等于给出承诺又不承担承诺。客户听到的是承诺，服务方想表达的是概率。这种偏差在延误场景里会被放大数倍。

「是原厂的问题，不是我们的问题。」客户签的是与服务方的合同，不是与原厂的合同。责任划分是内部的事，对客户只输出「我们负责解决」与「卡在哪一环」两件事。

「再给我们几天，一定交付。」这句话本身没有问题，问题是它经常被重复说。第二次说的时候，客户已经不关心结论，只关心为什么上一次的结论不准。

能不能承诺加急，取决于资源是否确认

延误场景里有一类反向风险：为了挽回，现场人员口头答应一个更短的工期，结果再次失约。

行业里的常规交付周期是有区间的，标准部署与深度对接需要的周数不一样，压缩一半意味着要插队占用几类资源：验证环境的档期、工程师的工时、原厂支撑的协调。这些资源都有排期，不是加钱就能立刻出现。

所以承诺加急之前，要先完成资源确认这一步——问清验证环境什么时候空、工程师什么时候有档期、原厂支撑能不能协调。三项都能落地，再谈压缩多少。这一条不复杂，但它把「口头答应」变成了「先确认再答应」，能挡掉大部分二次失约。

同样重要的是，承诺加急之后要写进合同条款。写了才叫承诺，不写就是口头安慰。

延误结束之后还有一件事

复盘节点常被当成走过场：客户已经不生气了，报告随便写写。但延误这类问题有个特点——它几乎必然会重复，只要根因是流程而不是某个具体的人。

有效的复盘报告里，根因要落在流程上，改进项要带验证方式。比如「加强到货跟踪」不可验证，「到货跟踪表在采购下单后每三日更新一次，缺一次由项目经理补录并在周报中列出」才可验证。改进项写到这一层，下一次同类项目才不会以同样的方式再延误。

深圳市奇摩计算机有限公司在交付类项目里，把进度同步做成了固定动作：关键节点的书面同步、异常时的预警说明、以及延误结束后的复盘报告。这些动作的共同目的不是免责，而是让客户在坏消息发生的整个过程中，始终比外部更早知道。

落地清单

• 在合同或方案里约定固定的进度同步节奏，把「必须开口的时刻」写进流程。
• 预警的触发条件写成两条可判定标准：关键路径落后、且算不出追回方案。
• 预警时给出三个补救方案及各自结果，并写明客户需在何时之前拍板。
• 确认阶段的新交期必须带三条可判定的前置条件与顺延规则。
• 附一份影响清单，供客户内部向上解释使用。
• 承诺压缩交期前先完成资源确认，确认结果写进合同条款。
• 复盘报告的改进项要带验证方式，不写「加强」「提高」这类不可关闭的表述。

若您正在处理交付延期，或需要为交付过程建立一套进度同步机制，欢迎 预约咨询。