做酒店WiFi认证项目的人大概都经历过这种场景：Portal认证页面设计稿改了七八版，甲方技术部门刚点头，品牌部又推翻重来。不是因为设计不好看，而是各方对Portal页面的诉求根本不在一个频道上。技术部门要的是认证流程能跑通、数据能采集，品牌部要的是视觉风格统一、品牌元素突出，运营部门要的是住客转化率、会员注册量。三个部门各有各的指标，Portal页面就这么被反复拉扯，项目进度卡在页面上推不动。

品牌部的审美逻辑和认证效率的矛盾

酒店品牌部对Portal页面的要求通常很细：背景图要用酒店官方拍摄的场景图，品牌标识位置不能偏，品牌色必须用潘通色号，按钮圆角大小都有规范。这些要求本身没问题，但放到认证场景里就会出问题。Portal页面是住客在手机浏览器里打开的，手机屏幕小，网络信号可能不稳定，页面加载速度直接影响认证成功率。一张高清酒店全景图可能两三兆，住客在客房里信号弱的时候，光等图片加载就要十几秒，很多人会以为认证页面打不开，直接放弃。

实际项目中，我们建议品牌元素用轻量化的方式呈现：品牌标识用矢量格式，背景用纯色或简单渐变，图片做懒加载或不加载。但品牌部往往不接受这种妥协，他们觉得没有品牌大图的Portal页面"没有质感"。这时候就需要项目组出面协调，把认证成功率的数据摆出来，让品牌部看到页面加载慢对用户体验的实际影响。有个项目做了AB测试，轻量版Portal页面平均加载时间一点五秒，认证成功率百分之九十四；重量版平均加载时间六秒，认证成功率掉到百分之八十一。这个数据一出来，品牌部立刻同意简化设计。

运营部门的数据采集需求

运营部门关注的是Portal页面能采集多少住客数据。手机号是基本要求，有些酒店还想采集住客姓名、房号、会员等级、入住目的。这些数据采集字段越多，认证流程越长，住客放弃率越高。我们在一个连锁酒店项目中做过统计：Portal页面只有手机号验证码两个字段时，认证完成率在百分之九十二左右；增加到五个字段后，完成率掉到百分之七十八。每多一个字段，就有百分之几的住客中途退出。

运营部门往往不理解这个数据，他们觉得多填几个字段有什么大不了的。但对住客来说，在手机上输入五个字段，尤其是入住后疲劳状态下，耐心是有限的。比较合理的做法是分层次采集：认证时只采集手机号，其他信息在认证成功后的落地页引导填写，或者通过后台与酒店管理系统对接自动获取，不需要住客手动填写。这样既满足了运营的数据需求，又不影响认证转化率。

技术部门的安全和稳定性底线

技术部门对Portal页面的关注点完全不同。他们关心的是页面有没有安全漏洞，认证接口有没有做防重放攻击，验证码有没有频率限制，页面在不同手机浏览器上能不能正常渲染。这些问题品牌部和运营部根本不会考虑，但对技术部门来说是底线。有一次项目上线后，技术部门发现Portal页面在部分安卓手机上验证码输入框被键盘遮挡，住客看不到自己输入的内容，认证失败率突然升高。这种兼容性问题在设计阶段很难发现，必须用真机测试。

技术部门还会关注Portal页面的HTTPS证书。很多酒店的Portal页面用的还是HTTP，住客手机浏览器会弹出安全警告，有些手机甚至会直接拦截。这个问题看起来简单，但涉及到酒店内网设备的证书管理，很多酒店没有统一的证书签发流程，改起来牵扯面广。在项目规划阶段就要把HTTPS证书的事情确认好，不能等到上线才发现。

怎么在项目初期锁定Portal需求

Portal页面反复改版的根本原因是需求没有在项目初期统一。我们的做法是：在需求调研阶段，把技术、品牌、运营三个部门拉到一起，用一张表格列出所有需求项，然后逐项标注"必须有"、"最好有"、"可以放弃"。对于冲突项，比如品牌部要大图但技术要页面轻量，用数据说话，做AB测试给各方看结果。表格确认后三方签字，后续改需求走变更流程，不能随意推翻。这样虽然前期多花时间，但能避免项目后期无休止的返工。