酒店WiFi认证系统和PMS（酒店管理系统）打通，是项目落地后能否真正"省人"的关键。表面看就是API对接，工程师写几个接口调一调就行，但实际跑起来会发现，PMS的版本差异、房态同步时延、特殊业务场景（加床、半日租、续住）都会让这套联动机制出问题。本文从实操层面梳理几个最常被忽略的节点。

第一个节点是check-in触发的开户时机。客人到前台办理入住，PMS生成订单并标记房间为"在售"，WiFi系统要同步触发账号开通。这里有个时间窗：太早开，客人还没进房间，账号就开通了，可能被无关人员使用；太晚开，客人进房间连WiFi还要等几十秒，体验差。POC时一定要测实际延迟——从PMS提交订单到WiFi账号可用，最好控制在3秒以内，超过5秒就要找原因。

第二个节点是check-out触发的关账时机。逻辑上和开户对称，但实际业务里更复杂。客人check-out之后，WiFi账号是立即关还是保留一段时间？不同酒店的业务习惯不同——有的要求客人一退房就不能上网，有的允许在酒店大堂继续用30分钟。这块要和酒店PMS运营方明确规则，然后让系统支持配置化——最好能按酒店单独设置"退房后WiFi保留时长"，而不是写死在系统里。

第三个节点是房型/会员等级的带宽策略联动。这是PMS联动中最有商业价值的一块。商务套房、白金会员、行政楼层——这些客人对WiFi的体验期待高，应该配更高的带宽；普通会员、散客配标准带宽；特价房、协议客户可以压低带宽节省成本。技术上要求WiFi系统能读PMS的会员级别和房型字段，并按字段下发不同RADIUS属性。这块POC时要用真实的会员数据跑一遍，看是否所有等级都生效。

第四个节点是换房和续住的处理。客人从A房换到B房，WiFi账号怎么处理？直接关掉旧账号开新账号是最简单的做法，但客人正在视频会议或者游戏，中断账号会引发投诉。更友好的做法是同一个客人在换房时保持账号不变，只切换绑定的VLAN——技术上要求WiFi系统能接收PMS的换房事件并实时更新账号-房间映射。续住类似，客人住七天，第六天来前台续住一天，WiFi账号的有效期要自动续期，不要让客人半夜被踢下线。

第五个节点是异常场景的处理。客人退房后才发现没关WiFi——这时候账号已经关掉但客人还连着——怎么处理？客人check-in时身份信息登记错误，但已经预付了房费——WiFi账号能不能开？网络中断后PMS订单状态丢失——WiFi系统怎么恢复？这类异常场景在POC阶段很容易被漏掉，但生产环境会高频出现。系统设计时要把异常处理做成可视化、可回滚的，不能让运维人员半夜去手动改数据库。

第六个节点是PMS厂商的API支持度。市面上PMS厂商众多——西软、千里马、Opera、欧溢、用友——每家对外提供的接口协议不一样，有的是RESTful，有的是SOAP，有的是数据库直连。WiFi厂商不可能为每家PMS单独做适配，更现实的方案是走中间件：WiFi系统支持通用的PMS对接中间层，由中间件去适配不同PMS。选型时要问清楚WiFi厂商对接过哪些PMS、是否提供中间件、定制开发费用怎么算。

落地PMS联动，关键是把上面六个节点都明确写进SLA里，不要只对一句"支持PMS对接"就完事。PMS对接做得好，酒店能减掉至少一个专职IT岗的日常工作量；做得差，每天的账号开通/关账都要靠手工，客人投诉还会居高不下。