很多酒店在推进WiFi改造时，会把"上一套认证系统"当成一件简单的事：找个供应商、买台设备、配一配就能用。但实际项目做下来，往往是前期没问清楚，后期被坑得不轻。哪些问题在签合同之前就应该搞清楚？这篇梳理几个最容易被忽略的判断节点。

当前网络架构是否支持Portal旁挂？

酒店宾馆WiFi认证最常见的落地方式是Portal旁挂：在现有网络出口处旁挂一台认证服务器，对未认证用户做强制跳转。这种方式改造成本低、对原有网络影响小，是中小酒店的主流选择。但前提是原有核心交换机或出口路由器支持Portal协议。如果酒店用的是老旧家用路由器，或者某些不支持VLAN划分的廉价设备，这条路就走不通。评估阶段必须让供应商到现场查清楚网络拓扑，而不是凭图纸估算。

认证方式选什么，和PMS系统有没有关联需求？

酒店宾馆WiFi认证的方式通常有几种：手机号短信验证、房间号+姓名验证、PMS系统同步房态验证、微信一键授权。选哪种，不仅仅是技术选择，还涉及运营逻辑。如果酒店需要做到"入住即可联网、退房自动下线"，就必须和PMS系统做数据对接，这个对接的接口开发量不小，选型时要确认供应商是否有现成的PMS对接方案，还是需要定制开发。定制开发意味着额外的时间成本和费用，项目周期会拉长。

实名认证日志的存储和上报要求清楚吗？

按照现行规定，酒店宾馆提供公共WiFi需要对用户进行实名认证并留存日志。这不只是在认证页填一个手机号那么简单——日志需要包含哪些字段、保存多少天、是否需要对接地方网安平台，这些要求因地区和运营商而不同。供应商在给方案时，往往只说"我们支持实名认证"，但具体到本地的合规细节，很多人说不清楚。建议在项目启动前主动联系当地运营商或网安部门确认一次，避免上线后因为日志字段缺失或保存期不达标被要求整改。

并发用户数的峰值估算是否准确？

认证系统的并发能力决定了在满房状态下能不能撑住。一家50间客房的酒店，假设每间房2-3台设备同时在线，加上餐厅、会议室的使用，峰值同时在线设备数可能达到150-200台。认证服务器的并发授权数如果只配了100，高峰期就会出现认证排队或失败的情况。很多小酒店在这个环节被供应商省成本，配了一台入门级服务器，上线当天就出问题。配置前先把峰值场景算清楚，给30%-50%的余量，比事后扩容省心得多。

宽带接入侧的带宽是否够用？

有些酒店WiFi差，不是认证系统的问题，是宽带入户带宽不足。50间客房、100M出口带宽，平均每间客房只有2M，满房的时候视频都看不顺畅。认证系统只是做接入管控，没办法凭空变出带宽。如果带宽本身就不够，上了认证系统之后用户还是会投诉网速慢，问题出在运营商侧，不是认证侧。在项目立项时，把宽带接入和无线覆盖、认证系统一起评估，才是完整的方案逻辑。

Portal页是要自己设计还是用默认模板？

Portal认证页是用户进入酒店WiFi的第一个界面，也是酒店品牌露出的一个机会。很多认证系统提供默认模板，能用，但千篇一律。有连锁酒店品牌形象要求的，会要求定制Portal页——加上品牌Logo、调整颜色风格、加入欢迎语和本地推荐信息。这部分需求在合同里明确，否则上线后再提，供应商按定制开发收费，又是一笔额外支出。

系统故障时的应急预案是什么？

认证服务器挂了或者和网络设备的通信断了，会发生什么？是所有用户都断网，还是自动切到免认证模式让大家先上网？这两种处理逻辑对酒店的影响差很远。前者会让满房的情况下出现大量投诉；后者虽然暂时放开了管控，但至少保住了基本服务。不同认证系统对故障场景的默认处理不同，选型时明确要求供应商说清楚故障模式和切换逻辑，比上线后出了事再追问强得多。

后期运维谁来做？

酒店宾馆WiFi认证系统上线后，日常运维包括：账号清理、日志检查、设备重启、固件更新、短信网关余额管理。这些工作听起来不复杂，但需要有人定期去做。大酒店有IT部门，小酒店的前台人员未必懂这些。如果选择完全外包给供应商，要在合同里明确响应时间和SLA。如果是自管，要在部署时要求供应商做一次完整培训，并提供操作手册。运维安排不落实，认证系统迟早变成没人管的"烂摊子"。

扩容和改造的灵活性如何？

酒店业务可能随时调整：翻新装修要新增楼层覆盖、加盟品牌要接入统一认证平台、开会议室服务要增加临时网段。认证系统是否支持在不停服的情况下扩容？是否有多场所统一管理能力？这些灵活性需求，在只有一家门店时看起来不重要，但如果酒店有扩张计划，选型时不考虑，后续改造成本会成倍增加。

把这几个问题在项目启动前理清楚，不是为了给供应商出难题，而是为了在选型阶段就把方案做实。很多部署失败的项目，根源都在于前期没有把边界条件搞清楚，导致中途反复变更，最后成本超标、效果打折。酒店宾馆WiFi认证不是大项目，但细节处理得好不好，直接影响住客体验和日后的运营质量。