酒店里有很多「只可意会」的信息：8306 的客人怕吵、7201 带了个两岁的孩子、5103 是老客户每次都要硬枕头。
这些信息以前存在三个地方：老员工的脑子里、微信群里、交接班的本子上。换班就丢，换人就忘。
11 月批次把收银台和 APP 的房间备注功能里的「房间标签」改成了多选——同一房间可同时绑定多个标签，并在各端房态、筛选标签中展示。
从单选到多选，差在哪
| 方式 | 能表达什么 | 局限 |
|---|---|---|
| 单选 | 「这间房是 VIP 房」 | 既是 VIP 又带娃又怕吵怎么办？只能选一个 |
| 多选 | 「VIP + 带娃 + 需安静」 | 标签太多会乱，需要规范 |
多选的价值在于一个房间往往同时有多个属性。真实场景里，「带娃」和「需安静」经常同时出现——因为带娃的客人最怕吵。
标签该分几类
客人属性
VIP、老客、长住、带娃、老人、外宾、团队。
服务需求
需安静、要高楼层、要硬枕、加床、无烟、宠物。
房间状态
待检修、设备特殊、朝向特殊、连通房。
风险提示
投诉过、有损坏记录、需重点查房。
四类里，前三类是「服务信息」，第四类是「风险信息」。
第四类要慎重。「投诉过」这种标签如果被客人看到，会很尴尬；如果被员工当成「这人难搞」，会形成偏见。建议这类信息用更中性的表述，或者只对管理层可见。
落地时最容易犯的错
错误一：标签太多
一口气建了三十个标签，员工记不住，最后只用那两三个。
错误二：没人清理
客人走了标签还在。下一批客人被按「带娃」标准服务，反而奇怪。
错误三：只有前台能打
客房、工程也需要打标签（比如「这间房空调有异响」），权限不给就变成单行道。
第二个最实际。标签是「当前状态」，不是「历史记录」。退房时必须清，否则标签会变成噪音。
建议做法：标签和订单绑定，退房时自动清除服务类标签，只保留房间属性类（朝向、连通房）。
一个可用的标签体系
| 标签 | 谁打 | 退房是否清除 |
|---|---|---|
| VIP | 前台 | 清除 |
| 带娃 | 前台 | 清除 |
| 需安静 | 前台 | 清除 |
| 加床 | 前台 / 客房 | 清除 |
| 无烟 | 前台 | 清除（房间本身无烟则常驻） |
| 设备待修 | 客房 / 工程 | 不清除，修好手动清 |
| 连通房 | 管理 | 常驻 |
| 朝南 | 管理 | 常驻 |
最后两行是「房间固有属性」，应该常驻；前五行是「本次入住的服务信息」，应该随退房清除。
把这两类分开，是标签体系能不能用起来的关键。
标签真正的价值
标签的作用不是「记录」，是「传递」。
一个信息如果只在一个员工脑子里，它不是资产。写进系统、能被下一个班次看到，它才变成资产。
酒店业最大的浪费之一，就是「每个员工都重新认识一遍客人」。
这一点对连锁门店更重要。客人在 A 店被记住的偏好，到 B 店能不能被看到？如果能，会员体系才算真的有用。
一个延伸用法
标签还能用来做筛选。
比如输入「带娃」，系统列出所有带娃的房间，客房部可以提前准备儿童拖鞋、加床护栏；或者输入「需安静」，前台在安排保洁时避开客人在房间的时段。
从「记录信息」到「批量动作」，中间只差一个筛选。
最后一句
标签是个特别朴素的工具，但它解决的是一件大事：让服务不依赖于「谁当班」。
一个店的 service 水平，如果取决于今天是谁在值班，那它就不是稳定的。标签是把稳定性做出来的一个小手段。