客户在电话里一急，销售当场答应加急，单子插到排程前面。结果是别的客户交付顺延了三天，那边的销售一头雾水，客户投诉打到了老板那里；更要命的是，自从这次白加急成功之后，这位客户每单都要加急，排程月月被打乱。加急本身不是错，客户真有急事，能救急的厂商才有黏性。错的是加急由一通电话决定，没有代价、没有审批、没有记录。
一、加急申请过三道关
- 理由可验证：写具体事由，客户的项目节点、违约风险、返工窗口，不收「客户很急」这种空话
- 代价可接受：加急占用了谁的产能，受影响的订单有哪些，客户愿意用什么交换
- 审批留痕：按影响面分级，只影响自己一家的主管批，要挤占其他客户的到老板批
二、加急要有代价，白用的加急一定会被滥用
代价不是罚款，是让加急成为一次慎重选择。常见形式：客户承担运费上浮、下一单预付比例提高、加急费抵扣后续订单、或者放弃某项服务承诺。代价谈得下来，说明客户的急是真急；谈不下来，多半是销售自己想图省事。规则提前讲清楚，销售在客户面前反而有底气：加急可以，这是流程，我帮您走。
三、举例说：一次加急申请的完整过程
假设客户甲要求把四百台的交付从十五天压到七天。产能口径：每提前一天要挤占约三十台的既有排程，压八天意味着二百四十台既有订单要顺延。销售提交加急申请：事由是客户下游项目节点在即，逾期违约金每天两万；代价方案是客户承担运费上浮，并把下一单预付比例从三成提到五成；影响面是两家既有客户的交付各顺延三天，销售须在当天电话告知并留记录。主管批注同意后，系统给两家受影响的客户各生成一条延期说明与对应跟进待办。结果：甲的承诺兑现，两家被告知的客户没有人投诉，因为提前三天就知道了，而不是货没到才发现。
四、受影响的客户必须被告知，而不是事后道歉
加急挤占的是别人的交期，告知不是礼貌，是流程的必要动作。谁打的电话、何时打的、客户什么反应，记进跟进记录。提前告知的延期，多数客户能接受，甚至会主动调整自己的安排；事后发现的延期，无论解释得多好，信任都折损一次。告知动作由系统生成待办，完成才算流程走完，不能靠自觉。
五、月度过一遍加急台账，读出改进信号
加急台账按客户统计次数与原因。某个客户每单都要求加急，是他自己计划性差，谈预付与代价；全行业客户都在催同一类产品，说明常规交期报得虚，该修订交期承诺而不是月月加急。台账里还看得见加急的成本：顺延了多少台、占了多少产能、换来了多少代价，这些数字是跟客户重新谈交期与价格时的依据。
这套加急申请、代价与留痕的做法，用 9527CRM 这类轻量级 CRM 的审批流与工单模块就能落地：加急申请挂在客户与订单之下走分级审批，受影响客户的告知动作自动生成待办提醒，台账按客户汇总次数与影响；由于支持私有化部署，系统开放 API，可以与自家的 ERP、生产排程工具打通，加急影响面用真实产能数据说话，审批不必在几个系统之间来回抄数。
