11 月批次的 32 条里，有五条改了「每天要重复几十次」的动作。
单看每一条都微不足道——没人在会上会为「日历控件优化」鼓掌。但一天点五十次，一年就是一万八千次。一万八千次里省下一秒，就是五个小时。
一、前台日历控件
收银台所有带起始时间的控件都做了调整。以前选日期要么点开一个大日历，要么手输；现在起始时间的输入更顺手。
为什么这件事重要：前台一天要选几十次日期——开单、续住、延期、查报表。每次多点一下，一天就是几十下。而且选错日期是前台最常见的手误之一。
二、APP 实时房态筛选同步前台
APP 的「更多」筛选里，新增了本地、联房、散客、会员、协议公司、团队、自定义宾客类型，以及 OTA 渠道（携程/同程/飞猪等）筛选项。排序与前台一致，选完还显示数量。
| 以前 | 现在 |
|---|---|
| 手机上只能按楼层、房型筛 | 能按客源类型和渠道筛 |
| 想看「今天有几个携程客」要回电脑 | 手机上直接筛出来 |
| 筛完不知道有多少间 | 筛选项上带数量 |
第二行的价值最大。店长在楼层想知道「今晚携程客占多少」，这个数以前要回办公室看。
三、远期房态预订时带房号
在 APP 远期房态点房间的「预定」，会自动把房号、房价、早餐券类型、每日赠早数量带进新订单，再补散客/OTA/协议信息就能开单。
以前
在远期房态看到 8306 空着，点预定，进到一个空白表单，要重新选房型、重新填房号。选错了就订到别的房间。
现在
点的是哪间就订哪间，房价和早餐跟着过来。只补客人信息。
这条改的是「所见即所订」。以前从远期房态开单，中间有一次信息转手，转手就会错。
四、房态页面的统计口径可勾选
收银台房态设置新增了四个勾选项：总房数、空房数、可订数、在住数。默认只勾空房数与可订数，没勾的不显示。
这个设计的聪明之处在于「默认只给两个」。四个数全显示，房型那一行会被数字挤满，反而看不懂。默认给空房和可订——这两个是前台当下最需要的。总房数和在住数留给想看的人自己打开。
顺带一句：这四个数的顺序是固定的（总房数 / 空房数 / 可订数 / 在住数），勾选结果与房型筛选列表、弹窗标题联动。固定顺序比「按勾选顺序显示」好，因为位置稳定才看得快。
五、集团报表的「去零列」
集团付款科目汇总报表里，整列都是 0 的支付方式不显示；支付方式按名称去重。
| 问题 | 改法 |
|---|---|
| 15 种支付方式，6 种所有门店都是 0 | 那 6 列不显示 |
| 同一个支付方式出现两行 | 按名称去重 |
这两条都是做减法。报表的通病是字段只增不减，最后谁也不敢删。这两条说明产品团队在克制。
五条放一起看
| 改动 | 省的是 | 频率 |
|---|---|---|
| 日历控件 | 每次选日期的一两秒 | 每天几十次 |
| 筛选同步 | 一次回办公室 | 每天几次 |
| 远期带房号 | 一次重复输入 + 选错风险 | 每天几次 |
| 统计口径 | 看房态时的一眼扫读 | 每天几十次 |
| 去零列 | 看不必要的信息 | 每月几次 |
频率最高的是第一和第四，都是「每天几十次」量级。这两条的价值远大于它们在更新日志里占的篇幅。
一个提醒
这类小改动，最容易「上线了但没人知道」。
该做的
早会上说一句「日历选日期的方式变了，你们试试」，比发一份更新文档有效。
常发生的
没人说，员工继续用老办法，甚至抱怨「怎么跟以前不一样了」。
最后一句
大功能决定「能不能做」，小改动决定「做起来烦不烦」。
一家店用不用得顺，往往不取决于有多少功能，而取决于这些每天几十次的动作顺不顺。