1. 明确具体的房型、房价计划、入住日期、入住人数、设备、市场和 Genius 会员级别。
2. 列出所有正在进行的促销活动，并确认哪些活动适用于同一搜索条件。
3. 在进行宾客端测试之前，计算出酒店可接受的最低底价（酒店承担折扣部分）。
4. 分别在未登录和已登录状态下，通过桌面端和移动端验证报价，然后检查实际预订订单的价格明细。
Booking.com Genius 折扣叠加 可能会使房价看起来比单一促销活动旁显示的折扣百分比更低。Genius 房价可能与移动端专享价、特定国家/地区专享价、限时优惠、活动营销或其他定向优惠同时适用。部分折扣可能由酒店承担，部分由 Booking.com 承担，还有一些折扣可能根本无法叠加。
稳妥的提问方式不是“Genius 折扣总是会叠加吗？”，而是“针对该房型、房价计划、宾客、设备、市场和日期，应用了哪些价格调整，最终酒店将获得多少收入？”
为什么 Genius 价格往往难以解释
Booking.com 会根据旅客的资格和酒店当前的配置显示优惠。两名员工搜索相同的日期，如果其中一人已登录、拥有不同的 Genius 级别、使用移动设备、从其他国家/地区搜索，或者符合平台补贴的激励条件，他们看到的价格可能截然不同。
一项促销活动也可能仅适用于特定的房型或房价计划。因此，最便宜的公开搜索结果，可能与收益经理原本打算测试的产品并不相同。
一个 Genius 折扣 可以与其他符合条件的优惠叠加，但这并非绝对。账号必须开启折扣叠加功能，而且每项优惠仍有其各自的适用规则。请核实酒店的具体配置，而不要想当然地认为每一个 Genius、移动端或定向房价都会自动叠加。
本文的重点在于介绍如何进行这种验证。文章不探讨酒店是否应该加入 Genius 项目，也不会比较 Genius 项目与首选合作伙伴（Preferred Partner）项目的优劣。
明确你要测试的具体房价
在打开酒店后台（Extranet）之前，请先记录一个完整的测试案例：
- 酒店及所用货币；
- 入住和退房日期；
- 房型及房价计划；
- 成人、儿童人数及客房数量；
- 餐食、取消条款及付款时间；
- 桌面端或移动端设备；
- 旅客所在国家/地区或市场；
- 未登录、已登录状态及 Genius 会员级别；以及
- 显示价格是否包含税费。
不要将搜索结果的首个价格直接与 酒店管理系统 中的基础房价进行对比。请在最终价格显示页面确认房型、计划、入住人数及各项条件均保持一致。
接下来确定控制性房价。如果是由酒店渠道管理系统发送母价，请记录发送至 Booking.com 的数值。如果是直接在酒店后台管理房价，请重新打开日历并记录存储的金额。在应用任何促销活动之前，衍生房价、按入住人数定价以及儿童加价等因素都可能改变初始价格。
在酒店后台审核每一项符合条件的促销活动
打开相应酒店的 Booking.com 酒店后台 ，查看 促销活动 以及该账号可用的 Genius 设置。菜单名称可能有所不同，但审核过程应解答相同的问题。
- 确认哪些房型和房价计划参与了 Genius 项目。
- 记录已配置的 Genius 折扣以及任何更高级别的权益或奖励。
- 列出正在进行中的移动端专享价、特定国家/地区专享价、早鸟特惠、最后一分钟特惠、活动营销、限时优惠或自定义优惠。
- 记录每项促销活动的预订日期、入住日期、不适用日期、最少入住天数、预订窗口、适用市场、适用设备以及涵盖的房型和房价计划范围。
- 检查该促销活动是由酒店承担、平台承担，还是由双方共同承担。
- 识别账号中显示的不适用条件或折扣叠加控制设置。
- 留意在测试期间计划开始或结束的促销活动。
不要将促销活动总览直接视为每一个显示的优惠都会影响酒店收入的证据。一项正在进行的促销活动可能并不适用于当前选择的旅客或产品，而平台承担的价格调整可能仅出现在宾客端报价或预订订单详情中。
Smart Order 的 酒店渠道管理系统 可保持母价与关联的 Booking.com 产品具有可追溯性，从而在应用渠道专属折扣之前，为收益团队提供一个可靠的初始价格参考。
保持 Booking.com 母价可追溯
通过单一来源管理关联的基础房价，随后隔离 Booking.com 内部应用的 Genius 折扣及其他促销层级。
计算酒店承担下的最低可能性房价
将每一项符合条件的折扣转换为房价瀑布模型（Rate Waterfall）。从促销活动适用的基准金额开始，然后依次扣减各项折扣。请不要简单地将百分比相加。
例如，如果客房起价为 200，且依次适用两项各 10% 的酒店承担折扣，结果将是 162：因为第二次 10% 的扣减是基于 180，而不是原始的 200。具体的扣减顺序和适用基准可能有所不同，因此请以账号内的规则和实际观察到的结算明细为准，不要将此示例想当然地视为 Booking.com 的通用公式。
得出卖价后，还需计算佣金、酒店承担的权益成本、酒店承担的税费、支付手续费以及可变的入住成本。请将平台承担的折扣单独列出，因为它们可能会降低宾客支付的价格，但并不会以同样的方式减少酒店协议约定的住宿收入。
请使用以下公式进行把控：
预期净收益 = 酒店应收账款 - 渠道费用 - 酒店承担权益成本 - 支付成本 - 可变入住成本
在测试前设定一个止损点。如果合理推算出的最低酒店承担房价低于已获批的底价，请在更多日期适用该优惠之前，缩小重叠促销的范围或将其暂停。
测试 Genius 是否与其他促销活动叠加
在每次搜索中，务必使用相同的日期、房型、入住人数、货币、市场和取消条件。建议使用隐身/无痕模式等受控会话来清除缓存影响，而不是比较不同员工的搜索截图。
- 在桌面端未登录状态下进行搜索，以建立公开的参考价格。
- 在桌面端登录相应级别的 Genius 会员账号进行搜索。
- 在符合条件的移动端设备上重复未登录状态下的公开搜索。
- 在移动端登录相同的 Genius 会员账号再次进行搜索。
- 打开完全一致的房型和房价计划，并进入到付款前的最终价格页面。
- 展开任何可见的折扣或价格明细，并记录适用的折扣标签。
- 将最终的宾客价格与先前计算出的房价瀑布模型进行对比。
每次只更改一个条件。如果移动端 Genius 登录状态下的搜索价格更低，请在使用移动设备但不登录 Genius 账号的条件下重复测试。这样可以隔离出额外的折扣是来源于移动端定向、Genius 会员身份，还是两者的叠加。
不要从差价的大小来推断是谁承担了折扣。直观看到的 10% 降价，并不能证明就是酒店承担了这 10%。折扣资金来源及佣金处理方式必须在预订订单和财务记录中进行核实。
通过受控预订订单进行验证
对于风险较高的营销活动，请在一个低需求的日期创建一个经授权的可退款测试预订订单。保存宾客端的最终价格截图，然后在酒店后台和酒店管理系统（PMS）中检查该预订订单。
核对房型、房价计划、日期、入住人数、基础住宿费、已适用的促销标签、佣金基数、税费以及预期的酒店应收账款。在政策允许范围内取消订单，并确认房态已准确回传恢复。
预订订单记录比搜索截图更具说服力，因为它展示了实际产生的商业结果。如果订单记录无法解释价格差异，请记录预订订单号，并联系平台合作伙伴支持团队，以确定具体的已应用优惠及资金承担方。
常见折扣叠加现象诊断
移动端登录后的价格远低于预期。 请检查 Genius 资格、移动端专享价、定向国家/地区优惠、活动日期，以及同一房价计划是否允许叠加第二项促销活动。
宾客看到低价，但酒店应收账款正常。 在更改酒店基础房价之前，请先查看是否存在 Booking.com 承担的激励措施或钱包/奖励金抵扣。
只有一个房型的折扣力度极大。 对比 Genius 房型的参与情况和每一项促销活动的适用范围。受影响的房型可能是唯一同时符合这两项优惠条件的产品。
在未更新房价的情况下价格发生了变化。 在诊断是否为渠道同步问题之前，请先检查促销活动的起始和结束日期、旅客资格、设备、市场、Genius 会员级别、税费以及货币汇率转换。
酒店渠道管理系统设置的底价未能拦截最终低价。 传输的基础房价和渠道端的促销卖价处于不同的层级。除了在源系统中设置，你还需在 Booking.com 的商业配置中控制促销底价。
记录测试条件、截图、母价、预期价格瀑布模型、观察到的最终价格、预订订单明细以及资金承担证据。在任何促销活动发生更改后均需重新检查；关闭一项优惠可能会暴露出另一项适用的房价。
常见问题
Booking.com Genius 可以与移动端专享价叠加吗？
在符合条件的配置下是可以的，但并非绝对会叠加。请检查酒店的折扣叠加设置，并验证实际登录移动端搜索的价格及预订订单明细。
酒店应该将折扣百分比直接相加吗？
不应该。需针对符合条件的基准价依次进行扣减计算，并将酒店承担的折扣与 Booking.com 承担的价格调整分开处理。
为什么两名 Genius 会员看到的价格不同？
他们可能有不同的 Genius 级别、使用不同设备、所在市场/货币不同、适用的促销活动不同，或者可订的房型及房价计划不同。在比较之前，请确保所有条件都一致。
最低的宾客端价格总是会同等程度地减少酒店收入吗？
不会。最终价格可能包含了平台承担的激励措施。请依据预订订单和财务记录来确认酒店实际的应收账款。
证明促销活动产生叠加的最可靠证据是什么？
受控的搜索能够隔离各项适用条件，而经授权的测试预订订单则能确认已应用的优惠项目以及最终的酒店应收账款。
Genius 的折扣叠加应被视为一次价格审计，而不是仅凭一个标签进行的猜测。请追溯母价，列出所有符合条件的促销活动，一次测试一个条件，并在确认最终净收益后再决定是否保留这些重叠的优惠。
