前台最常听到的一句话：「我住几号房来着？」
客人忘了房号，也忘了自己订的是哪种房型。前台只能问姓名，然后在系统里翻——同名同姓的、拼音打错的、订单是别人代订的，翻两三分钟很常见。
11 月批次给 APP 加了一套「以卡找房」的能力，覆盖四个界面：实时房态、订单管理、工作台排房、续住选房。核心逻辑是——读身份证或房卡，直接定位到房间或订单。
四个界面各自能做什么
| 界面 | 读什么 | 结果 |
|---|---|---|
| 实时房态 | 身份证 / 房卡 | 读到单个在住单或预订单，直接弹房间操作框 |
| 订单管理 | 身份证 / 房卡（NFC） | 定位订单并跳到全部订单页 |
| 工作台排房 | 身份证 | 匹配一个房间直接进选房页，多个则按待排房订单分组列出 |
| 续住选房 | 身份证 / 房卡 | 自动定位对应房间或待续住订单 |
第二个界面的进步最明显：任意 Tab、任意日期都能唤起读卡，读到有效卡自动跳转。以前要先切到「在住」Tab，再找到那个人。
读到多张卡怎么办
读到 1 个
直接弹对应的操作框，最快。
读到多个
以卡片列表形式让员工选。常见于「同一个人有多间房」或「一张卡开过多间门」。
读到无效卡
无效、注销、过期、非本店卡，都有明确提示。不会静默失败。
第三个是最容易被忽略的设计。没有提示的读卡失败，员工会以为是设备坏了，然后放弃使用。
三个真实场景
场景一：客人忘房号
客人走到前台说「我住 8 楼」。让他把身份证放上去，一秒定位。比问姓名快得多，也不会出错。
场景二：团队集中到店
二十个人同时到，报名字报到前台崩溃。改成收身份证、读卡、发卡，流水线作业。
场景三：查房与维修
客房主管在楼层，想知道某间房是谁住的。读一下门卡就知道，不用回前台查。
第二个场景的价值最大。团队入住的瓶颈从来不是系统慢，是「一个一个人问名字」。读卡把这一步变成了「收身份证—刷—发卡」的动作流。
姓名搜索的三个细节
除了读卡，这批还加了姓名搜索的优化：
| 细节 | 说明 |
|---|---|
| 支持拼音简称 | 输入 zs 能匹配「张三」 |
| 支持缩写 | 输入 zhangsn 也能匹配 |
| 输满 1 字即检索 | 不用等输完再按搜索 |
这三条加起来，把「找一个人」从十几秒压到了三四秒。
为什么拼音比汉字快？因为前台用的是实体键盘或手机键盘，打 zhang 四个字母比选「张」这个字快。而且不用切换输入法——很多人卡在「切输入法」这一步。
这个细节只有真正在柜台后面站过的人才会想到。
读卡能力的前提
前提一：手机支持 NFC
读身份证和房卡都依赖 NFC。老款手机可能不支持，要提前确认设备清单。
前提二：身份证要能读芯片
不是拍照识别，是读芯片。这需要专门的读卡模块或者支持 NFC 读身份证的手机。
前提三：网络要通
读到的信息要回服务器查询。断网时只能手工输入。
第一条是硬件门槛。门店要配手机，就得配支持 NFC 的型号。这一点在采购时容易被忽略——买了一批便宜手机，发现读不了卡。
使用上的一条建议
该主动用
客人报不出房号时、团队到店时、查房时。这三个场景用读卡，效率提升最明显。
别硬用
客人能清楚报出姓名和手机号时，直接搜更快。读卡要掏证件、要贴准位置，反而慢。
工具要选对场景。所有场景都用读卡，会让员工觉得麻烦，最后连该用的场景也不用了。
最后一句
以卡找房解决的是一个很具体的小痛点：「我住几号房」这个问题，不该花三分钟回答。
小痛点解决了，前台的节奏才顺。而前台的节奏，决定了客人进门那三十秒的感受。