这张卡讲交付项目的安全通道：升级不是告状，是预先约定的求助机制。
核心拆解：升级路径三要素——触发条件（超时时限、金额阈值、客户高管介入）、升级对象（具体到角色与备份人）、响应时限，触发条件尽量写成数字，避免临场争论。健康的设计是两级：一级到交付负责人，二级到双方管理层，客户侧要有对称的升级入口。两种极端都要避免：工程师把升级当失败、硬扛到爆炸；或者事事升级，管理层变成工单池，升级从此失去严肃性。
增量判断：国内驻场场景的惯性是不敢升级——怕显得能力不足。要把「升级是专业行为」写进团队文化，同时升级记录本身是宝贵的复盘素材，反复升级的问题说明流程有洞，这类记录是复盘的金矿。
行动建议：为你当前项目写一页升级路径卡，贴进项目群公告并同步给客户对接人，触发条件写到数字，并随项目阶段更新一次。
—— FDEChina编辑部 · 实战派
定义
升级路径（Escalation Path）指问题超出当前处理人的权限或能力时，向上流转的预定通道：什么条件触发升级、升级给谁、多长时间内必须响应，应在项目启动时与客户共同约定。
展开
升级路径有三要素：触发条件——响应超时、影响金额阈值、客户高管介入等，最好写成数字；升级对象——具体到角色并列出备份人，不能只写部门；响应时限——每级升级后的承诺响应时间。健康的设计是两级结构：一级升级到交付负责人，二级升级到双方管理层，且客户侧要有对称的入口，客户内部的问题升级同样需要通道。两种极端都要避免：工程师把升级视为失败、硬扛到爆炸，小问题拖成大事故；或者事事升级，管理层沦为工单池，升级失去严肃性。把升级定义为专业行为而非无能，是团队文化层面的事。
对 Forward Deployed Engineer（FDE）团队，升级路径还有一层价值：驻场人员常是单点，清晰的升级通道等于给客户一个不依赖某个人的承诺，也降低了团队自身的人员风险。升级记录应进复盘——反复升级的同类问题，说明流程本身有洞。