智能门牌最尴尬的场景不是刷不了脸，而是人到了门口，脸也对得上，系统却不放行——因为这个人不是订单上的预订人。
团队入住正是高发场景：十几个同事分批到店，只有预订人被录入了系统。
识别之后的分层处理
1
先识别，不直接拒绝
用户用刷脸、密码或手机号尝试开门时，系统识别出此人非该房间预订人，进入「房间已被预定」提示界面，而不是简单报错。
2
判断订单性质
系统读取该房间对应的预订单类型。若为散人订单，则不放行；若为团队订单，则进入下一步。
3
给出团队码入口
界面底部同步展示「团队码」校验入口，客人输入团队码后进入现有入住流程，与全天房入住流程保持一致。
团队码解决了什么
分批到店
团队成员不是同时抵达、也不是同一批入住，逐一录名单既慢又容易出错。
名单变更
临时换人、增补成员很常见，名单录死后现场就锁死了。
安全边界
团队码是有时效、有范围的凭证，不是万能钥匙——这与"随便给个码就放行"有本质区别。
流程统一
校验通过后走的是现有入住流程，制卡、核验、登记都不需要另起一套。
设计上的两个要点
正确的做法
- 只在"订单确实是团队单"时才提供团队码入口
- 团队码有明确有效期与适用房间范围
- 团队码使用记录要留痕，进团队订单可查
容易出问题的地方
- 散人订单也放出团队码入口
- 团队码长期有效，等同于万能房卡
- 谁用了团队码查不到，无法追责
一个提醒
门牌的价值在于在保证安全的前提下把门打开。识别非预订人不是终点，而是分流——散人订单守住，团队订单给一条合规的路走，两类客人都不会被挡在门外。
3 步
识别后处理逻辑
2 类
订单性质判断
1 条
团队码路径
可追溯
使用记录要求