酒店的收入流失，很少是"少收了房费"这种明账，更多是藏在折扣、免费房、临时退款这些"顺手就办了"的动作里。审批流的作用，就是给这些动作装一道可配置的闸门。
先分清：审批流管"要不要批"，权限管"能不能做"
这两个东西经常被混为一谈。区别在于：
- 权限：决定某个岗位能不能进入某个功能（比如前台能不能改价）
- 审批流：决定某个动作在执行前要不要经过谁同意（比如前台改价超过 8 折就要店长批）
只做权限，前台有改价权就会随便改；只做审批，每个动作都要走单又会把效率拖垮。正确做法是权限给足、审批设阀。
哪些动作必须挂审批
按"直接动钱"的程度排序，建议至少覆盖这几类：
| 动作 | 建议阈值示例 | 审批人 |
|---|---|---|
| 房价折扣 | 低于门市价 8 折 | 店长 |
| 免房 / 内部房 | 任何金额 | 店长或业主 |
| 退款 / 冲账 | 单笔 > 200 元 | 店长 |
| 挂账 | 超出该客户授信额度 | 财务 |
| 房态强开 | 满房状态下开房 | 店长 |
阈值不要一次定死，先跑两周看数据，再根据实际发生频率调整——定得太松等于没有，定得太紧所有人都会绕开系统私下处理。
单据必须留痕，且要有时效
审批流的设计有两个容易忽略的细节：
1. 留痕要完整：谁发起、谁批准、什么时间、批准时订单的原始状态。缺任何一项，事后都无法复核 2. 时效要设定：一条审批挂三天没人处理，客人早就走了。要给审批设置超时提醒，超时自动升级给上一级
选住云管家的审批与操作日志是打通的——每一次批准都进入审计轨迹，和上一篇文章讲的"可回溯"是同一套底层。
谁审批，层级怎么设
层级不是越多越好。三层审批（前台→店长→业主）会让一张免房单卡一周。实践上：
- 日常经营动作（折扣、退款）→ 一层审批，店长决策
- 资产性动作（大额免房、押金豁免）→ 两层，业主把关
- 跨店/集团动作 → 走集团统一规则
> 一条经验：把"审批超时率"纳入店长考核。审批流真正的敌人不是设置复杂，而是"挂了没人管"。
审批流不会直接增加收入，但它能堵住那种"每天漏一点、一年漏一台车"的隐性损耗。设计得好，它几乎不影响效率；设计得差，它会成为所有人绕过系统的理由。