巴中建站公司：客户资料迟迟不到位时怎样记录等待成本

📍 WDQWDWQD987AAAAA:18.97.9.171
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /f0c537daf10f.html
📄

等待成本不是一句“客户还没给资料”，而是可以按天记录、能换算成工期和现金的账。建议把等待拆成三条线：被占用的排期、被反复打断的人工、被推迟的收款节点。三条线都记，才能判断该继续等、加价插队，还是把项目挂起。

假设情境：一份拖了十九天的资料清单

以下为假设例子，用于说明记录方法，不代表任何真实项目。假设一家巴中建站公司接了一个企业站，合同约定客户在开工前提供营业执照、产品图、公司简介和备案主体信息。客户第三天给了营业执照，产品图和简介一直没给。到第十九天，设计已经做完首页，内页文案空着，程序员只能先做框架。

这十九天里，真正“什么都没干”的可能只有几天，其余时间是断断续续地催、等、再催。等待成本记录的关键，就是把这十九天里被占用的部分单独拎出来，而不是笼统记成“项目延期十九天”。

排期占用最容易被记错。项目挂了十九天，不等于损失了十九个工作日，因为设计师可能已经转去做别的项目，只是每天花十几分钟催一次。真正要记的是：这段时间里，哪个岗位因为等这份资料而无法满负荷安排。

这样记的好处是：如果被挡住的只是一个可以后置的岗位，等待成本就低，继续等是合理选择；如果被挡住的是唯一能出图的设计师，且后面已经排了两个项目，等待成本就会快速上升，此时应当考虑加价插队或书面挂起。

催资料看起来不费时间，但它打断了正在做的事。记录方法可以很简单：每次联系客户，记下日期、方式、耗时、结果。结果只分三类——有回复且给了部分资料、有回复但没给、没回复。

假设十九天里共联系客户十一次，每次平均十二分钟，合计约两小时十二分钟。这个数字本身不大，但如果这十一次都发生在设计或开发的关键节点上，实际损失的是切换状态的时间。可以进一步记录：有几次是在当天主要交付任务进行中被叫停去催的。

当打断次数超过某个内部约定值，比如一周超过三次，就说明靠零散催促已经无效，应该把沟通方式从“随时问”改成“固定节点集中确认”，并把这一变化写进下一次沟通记录。

等待最终会落到钱上，但不要直接说“损失了多少钱”，而是看它改变了哪个付款节点。常见做法是把付款拆成签约、资料齐备、初稿确认、上线四段。客户资料迟迟不到位，最直接的影响是“资料齐备”这一节点无法触发。

记录时可以写清三件事：原定触发日、实际触发日、因等待而需要重新确认的后续节点。如果等待超过合同约定的资料提交期限，下一步动作不是继续免费等，而是发一份书面确认，写明新的排期起点和付款条件。例如把“资料齐备后十五个工作日交付”改成“资料齐备后重新排期，具体交付日以确认单为准”。

这个动作的结果会直接影响下一步：如果客户在确认单上签字并给出明确日期，项目可以继续按原报价走；如果客户既不签字也不给日期，就应当把项目转入挂起状态，释放排期给其他项目，等待成本记录也随之从“进行中”改为“已挂起”。

不需要复杂工具，一张表加四列就够：日期、被挡岗位、联系方式与结果、触发的节点变化。每周看一次，重点不是算出一个精确金额，而是回答一个问题——继续等，是否比调整排期更划算。

判断条件可以设成两条。第一，如果被挡岗位可以替换或后置，且客户给出了明确的新日期，继续等成立。第二，如果被挡岗位不可替换，且一周内联系三次以上仍无明确日期，加价插队或书面挂起更合理。两条之间的情形，按被挡天数和打断次数逐周复核，不一次性下结论。

记录等待成本的最终目的，是让“客户还没给资料”从一句抱怨变成可比较的依据。有了依据，报价、排期和付款条件才能跟着调整，而不是一直用同一套条件去等一个不确定的日期。