1. PMS 即使已经安装并配置完毕，也不代表可以开始接受真实预订——关键在于是否已针对实际可能发生的情形完成测试。
2. 上线故障主要集中在五个方面：房量不正确、房价与预期不符、限制条件未生效、付款设置未经测试，以及员工账户权限错误。
3. 本清单通过 30 个可核查项目覆盖上述五个方面——每一项都对应一种具体问题；若未能在开放日历前发现，就可能直接影响住客。
4. 请在收到首个真实预订前完整执行一次清单，而不是事后补查。
酒店为何会带着错误上线
新 PMS 的设置步骤很明确：创建房型、录入房价、连接渠道、添加员工。大多数酒店都能完成这些步骤。问题在于，完成一个步骤并不等于验证了这个步骤。
房价录入错误，往往要等到住客以错误价格完成预订后才会暴露。渠道连接看似已启用，但若未同步可售房量，通常要等到发生重复预订时才会发现。员工账户权限过大，也往往要等到有人修改了其无权调整的房价后才会显现。
以下清单用于核查验证，而非指导系统设置。每个项目均以配置已经完成为前提，旨在测试配置能否产生正确结果。
房型与房量（检查项 1—6）
1. 每种房型均与实际客房相符。 PMS 中的房型名称、数量和描述应与酒店的实际客房一致。名为“Ocean View Double（海景双人房）”的房型应涵盖所有真正拥有海景的双人房——不多也不少。
2. 房间数量正确，且不会超卖。 系统中每种房型的容量应与实际可售房间数一致。创建测试预订，将某一房型订至满房，并确认系统会阻止用户继续预订该房型在这些日期的房间。
3. 停用客房已被锁定。 所有正在维修、翻新或因其他原因无法使用的客房，均应设为“维修”状态并从可售房量中移除。确认所有已连接渠道均显示相应的房量锁定。
4. 客房设施标签准确无误。 用于住客筛选的特色条件——无障碍设施、位于底层、特大床、阳台等——应分配给正确的房型。住客筛选“无障碍”时，只应看到真正符合该要求的客房。
5. 已为每种房型设置最多入住人数。 系统应对每种房型的住客人数设置上限。标明可住 2 人的客房不能被 5 人预订。
6. 分配给各房型的照片均为最新版本。 显示在 官网直订 和 OTA 房源页面上的图片应与客房当前状况一致，而不是翻新期间的旧版本。
房价与定价（检查项 7—12）
7. 基础房价覆盖完整的未来 90 天。 未来三个月内，每种房型的每个日期都应配置房价。未覆盖的日期可能导致报错或产生零房价预订。
8. 如有需要，周末房价已单独设置。 如果酒店的周五至周六房价与工作日不同，请确认价差应用于正确的日期，且不会误延伸至相邻日期。
9. 旺季及活动期间房价已录入。 已知的高需求日期——法定节假日、当地活动和学校假期等——应采用反映实际需求的房价，而不是默认基础房价。
10. 已设置最低房价底线。 任何房型的预订价格都不得低于酒店的成本底线。确认自动化工具或人工调整均无法将房价降至规定的最低价格以下。
11. 扣除佣金影响后，OTA 渠道房价正确。 如果酒店发布的是净价，请核实平台加收佣金后的加价结果能否形成预期的住客端售价。如果发布的是含佣金总价，请确认 OTA 不会在此基础上再次加收佣金。
12. 官网直订测试显示的总价正确。 通过官网直订链接或预订组件创建测试预订，并确认付款前显示的总价——房价、税费及其他费用之和——符合预期。
在收到首个真实预订前，核查房价、房量和渠道同步
Smart Order 的设置清单可指导酒店业主逐项核查房价配置、渠道连接和员工权限——让上线成为经过验证的状态，而不是未经证实的假设。
限制条件（检查项 13—16）
13. 旺季时段已应用最少连住限制。 设置了至少连住 3 晚的节假日周末不能仅预订 1 晚。请进行测试：尝试在受限日期预订 1 晚，并确认系统会阻止该预订。
14. 停售日期已在所有渠道锁定。 酒店不接受新预订的日期应在 PMS 中锁定，并同步至每个已连接的 OTA 渠道——而不只是官网直订日历。
15. 入住日和退房日限制已生效。 例如，如果酒店在夏季不允许住客周五入住，应在系统中配置这项限制，并通过尝试预订受限日期来进行测试。
16. 已设定临近入住日期的预订时限。 系统应配置最晚接受新预订的截止时间——无论是入住当天、提前 24 小时还是提前 48 小时——且官网直订与渠道预订应采用一致的设置。
付款与取消政策（检查项 17—21）
17. 官网直订的押金金额及收取时间已配置。 应设置押金比例或固定金额及其收取时间——确认预订时或确认后 48 小时——并确保该规则自动应用于每个新的官网直订订单。
18. 取消期限已设定并完成测试。 应配置入住前多少天取消预订将不退押金。请进行测试：在取消期限内取消，并确认押金予以扣留；在期限外取消，并确认押金可以退还。
19. 已设置未入住收费规则。 应配置住客未按时抵店且未在规定期限内取消时收取的费用，并将其与系统中保存的付款方式关联。
20. 已通过真实交易测试支付处理商连接。 应通过已连接的支付处理商完成一笔测试扣款，然后将其撤销。未处理过真实交易的支付集成不能视为已经确认可用。
21. 预订时显示的取消政策与系统配置的政策一致。 住客在预订时看到的文字——包括确认页面和确认邮件中的内容——应与系统实际执行的政策完全一致。
员工角色与权限（检查项 22—25）
22. 每位员工均有有效账户。 所有将在上线前或上线当天使用 PMS 的人员都应完成登录，并确认其账户凭据有效。
23. 前台权限范围设置正确。 前台 账户可以查看预订、办理入住和退房并处理付款，但不能更改房价、查看完整报表或修改系统设置。
24. 客房部账户仅限管理房态。 客房部用户只能更新房态（已退房→清洁中→待检查→可入住→维修），不能执行其他操作。他们无法查看住客付款数据或预订财务明细。
25. 管理人员及业主账户符合正确的权限层级。 经理账户拥有报表和设置访问权限，业主账户拥有全部权限。任何员工账户都不应获得超出其岗位所需范围的权限。
渠道连接与消息通知（检查项 26—30）
26. 每个 OTA 渠道连接均已通过真实预订测试。 在 Booking.com 或 Airbnb 创建一笔测试预订，并确认其在两分钟内显示于 PMS。不要因为设置页面显示“已连接”，就认定连接可以正常工作。
27. 房量锁定可同步至所有已连接渠道。 在 PMS 中锁定某间客房的特定日期，并确认每个已连接的 OTA 渠道均显示该锁定。随后解除锁定，并确认所有渠道的可售状态均已恢复。
28. 官网直订链接或预订组件显示准确的可售房量。 以住客身份打开官网直订页面，并确认其中显示的可售房量与 PMS 日历一致，包括所有房量锁定和限制条件。
29. 预订确认消息内容准确。 预订确认邮件应包含正确的酒店地址、入住时间段以及有效的联系电话。向员工邮箱发送一封测试确认邮件，并检查每个字段。
30. 抵店前消息的发送时间设置覆盖所有预订类型。 系统应针对所有预订来源自动发送入住前 72 小时提醒——不仅包括官网直订，也包括 OTA 预订。请查看测试 OTA 预订的消息发送计划进行确认。
以充分验证后的信心开放预订日历，而不是凭想当然
Smart Order 将客房库存、OTA 渠道、付款设置和自动化住客消息整合到同一系统中——因此，这份清单中的 30 项检查只需针对一套配置完成，而不必分别核查五种独立工具。
常见问题
新的 酒店 PMS 上线前应检查哪些项目？?
系统上线时最容易出错的五个方面是客房库存与房量、房价配置、预订限制、付款与取消政策设置，以及员工账户权限。每个类别都包含可在首笔正式预订产生前测试的具体项目——完成配置并不等于确认配置正确。
如何测试酒店物业管理系统中的 OTA 渠道连接？
在 OTA 平台创建一笔测试预订，并确认该预订在两分钟内出现在物业管理系统中。然后在物业管理系统中关闭某个日期的客房库存，并确认 OTA 日历上也显示为不可售。这两项测试缺一不可——能够同步传入预订的连接，未必能正确向外推送可售房量更新；能够推送关房信息的连接，也未必能正确接收传入的预订。
酒店前台员工在物业管理系统中应具备哪些权限？
前台账户应能够查看和修改预订、办理入住和退房、处理宾客付款，以及在预订记录中添加备注。前台账户不应有权访问房价配置、系统级设置、完整的财务报表或其他员工账户管理功能。将前台权限限制在日常运营任务范围内，可以防止意外更改房价，并降低凭证相关安全问题的影响范围。
如何确认物业管理系统中的取消政策设置正确？
应从两个方向进行测试：在取消政策规定的时限之外取消预订，确认订金已退还；在规定时限之内取消预订，确认订金未退还。此外，还应将宾客预订时看到的政策文本与系统的实际处理结果进行对比——两者应体现相同的条款。
酒店物业管理系统何时可以正式上线？
只有在上线前检查清单中的每个项目都经过测试验证，而不只是完成录入配置后，物业管理系统才具备正式上线条件。这包括检查未来完整 90 天的房价、通过每个渠道完成一笔正式测试预订、确认一笔付款交易成功、确保所有员工账户均已启用且权限范围设置正确，以及审核自动发送的消息内容是否准确。配置与验证是两个独立步骤——系统应在验证完成后上线，而不是在配置完成后上线。
