酒店新预售券解决方案
收藏更新日志
版本号 | 更新时间 | 更新内容 |
| | |
1.业务介绍
1.业务简介
- •业务定义：抖音酒店预售券是指酒店提前向消费者销售的、不指定具体入住日期的客房权益产品（如房券、套餐券等）。用户需先购买预售券获得权益，后续在有效期内通过预约系统选择具体入住日期及房型，本质是“先付费、后消费”的预购模式。预售券是一种支持用户“先买券，后订房”的新商品类型，方便用户囤货和商家卖货。
- •业务价值：
- ◦商家价值：
- ▪淡季引流与库存管理：通过低价预售券刺激非旺季需求，淡季增加预约库存量，平衡全年入住率；
- ▪ 收益优化：预售券可灵活设置退款规则，减少退单损失；同时通过预约时的房型升级、附加服务提升额外收入；
- ▪用户粘性与品牌曝光：预售券常作为会员福利（如积分兑换券），增强用户忠诚度；借助直播、大促等场景扩大品牌触达，吸引新客尝试。
- ◦用户价值：
- ▪价格优势：预售券通常低于日历房实时价格，方便消费者前置低价“囤货”；
- ▪出行灵活：锁定长期权益，适合行程不确定的用户；
- ▪附加权益：商家常捆绑增值服务（如餐饮、SPA、景区门票）吸引下单，提升用户性价比。
- •与日历房的差异：预售券购买与使用存在时间差，且不支持发起当天的预约入住，需通过“预约”环节匹配入住日期，区别于日历房的“即订即住”即时交易场景。
- •直连预售券vs非直连预售券对比
模块 | 功能点 | 直连预售券 | 非直连预售券 |
商家入驻 | 注册账户&认领门店&亮照&开通结算账户等 | 抖音来客 | 抖音来客 |
商品管理 | 预售券 | 接口or抖音来客(手工) | 抖音来客(手工) |
预售房型（预定商品） | 系统直连 | 抖音来客(手工) | |
物理房型 | 系统直连 | 抖音来客(手工) | |
商家经营 | 撮合&直播等 | 抖音来客 | 抖音来客 |
营销产品能力 | 支持提报涡轮,秒杀,货补等功能 | 支持提报涡轮,秒杀,货补等功能 | |
交易履约 | 用户预约 | 用户线上预约 预约锁定库存 | 用户线上预约 预约锁定库存 |
商家接单 | 系统直连 无需人工搬单 | 抖音来客确认订单 人工搬单至酒店系统 | |
核销 | 离店后T+1自动核销 | 离店后T+1自动核销 | |
结算分账 | 分账提现 | 离店后 T+1 天分账 | 离店后 T+1 天分账 |
2.业务流程
用户购买【预售券】 | | | |
用户线上预约【预售券】 | | | |
1.整体流程
3.名词解释
名词 | 解释 |
client_key | 开发方通过接口对接抖音开放平台前需要创建应用，应用的 AppId 等价于 client_key，二者值相同，用于唯一区分一个应用 |
client_secret | |
测试账号 | 为了方便三方与抖音侧进行联调测试， 三方可向抖音侧技术支持同学申请测试账号（包含测试商家账号和对应的开放平台应用），测试账号的应用和权限申请抖音侧已经提前准备好，可直接投入开发测试使用 |
2.接入说明与流程
1.接入前置说明
- •开发者直连接入需遵循平台服务标准并保障商家数据安全及隐私。商家在接入期间应持续符合接入标准要求，如出现影响平台及商家服务质量的问题，平台有权终止直连对接服务。
- ◦开发者正式启用直连对接服务，需要符合平台接入规范并顺利通过技术对接验收标准
- ◦开发者在直连对接期间，需要保障自身技术稳定性，可订检查不得低于大盘平均水平
- ◦开发者在直连对接期间，若出现技术服务质量问题，服务商需要配合平台进行接口整改和优化
2.开发者入驻以及创建生活服务商家应用
- •技术服务商：技术服务商 接入指南
- •自研：自研商家接入指南
3.验收和压测
- •测试环境：若需要测试环境，需联系抖音侧 BD 建群，由抖音侧技术支持提供测试流程并协助测试。
- •注：部分解决方案必须在测试账号下完成联调验收通过后，才可以申请解决方案相关接口权限。
- •正式环境：若只需要在正式环境联调测试，可在开放平台控制台-生活服务商家应用-开发工具，进行自助验收和压测，完成后可进行上线操作
4.申请解决方案并上线
- •需要申请「酒店新预售券解决方案」，审批通过之后在正式环境上线
3.接口对接
1.预售券对接场景
1.时序图
2.接口清单
能力名称 | 是否必接 | 对接模式（必接） | 接口 | 说明 | 流程图 |
酒店静态信息匹配/创建/更新 | 必接（模式二选一） | 模式一:推送模式（推荐） 合作方推送酒店静态信息,抖音进行匹配和创建 |
| | |
酒店静态信息匹配成功后通知服务商。 | | ||||
酒店匹配状态查询 | | ||||
酒店静态信息自助获取 | 模式二:自助匹配模式 合作方从抖音侧获取酒店核心静态信息,在合作方侧自行mapping | 抖音酒店查询（不适用于代理商） | | ||
物理房型静态信息匹配/创建/更新 | 必接（模式二选一） | 模式一:推送模式 （推荐） 合作方推送物理房型信息,抖音进行 匹配和创建 | 创建或更新抖音物理房型 | | |
物理房型审核通过/拒绝后通知服务商。 | | ||||
查询物理房型审核状态 | | ||||
物理房型静态信息自助获取 | 模式二:自助匹配模式 合作方从抖音側获取物理房型核心静 态信息,在合作方侧自行mapping | 门店下物理房型查询 | | ||
物理房型上下架 | 对接物理房型信息时，必接 | | 对物理房型进行上下架或者删除，单批次最多5个，单商家限制每秒最多操作40个房型 | | |
房价/房态/房量更新 | 必接 | 模式一:推送模式 （必接） 合作方直接通过接口实时推送ARI变化给抖音 | 保存价量态房量，该接口最多支持单次传递50组房量房态 | | |
保存价量态价格，该接口最多支持单次传递50组房价 | | ||||
商家侧日历库存或价格有变更触发接口商用 | | ||||
主动拉取价量态 | 模式二:拉取模式 （必接） 1合作方无法通知变化,靠抖音根据尽 可能快的频率进行拉取 | | 抖音侧调用第三方主动拉取价量态信息。 | | |
预售券线上开票 | 选接 | | |||
住宿预售券交易正向 | 必接 | | 抖音侧调用 第三方进行可订检查。如果不可订需要返回价量信息进行价量更新 | | |
必接 | 抖音侧调用第三方创建酒店预售订单。 | ||||
必接 | 抖音侧调用第三方创建酒店订单。 | ||||
选接 | 两步骤模式需要对接「支付结果通知」 | 抖音侧通知第三方支付成功。供应商交易模式为支付后创单的情况下抖音不会调用该spi | |||
异步接单模式必接 | | 抖音侧通知第三方支付成功后，第三方需要在商品上单中设置的接单时间内通知抖音侧接单结果。超时会拒单 | |||
住宿预售券交易逆向 | 必接 | 立即取消（同步）模式，仅需要对接酒店取消订单接口 | | 抖音侧通知第三方取消订单。 | |
异步取消模式必接 | 抖音侧请求第三方申请退款后，第三方异步回调审核结果。 | ||||
必接 | | 抖音侧完成退款后，通知第三方订单实际退款信息。 | |||
入住/离店状态同步 | 选接（建议接入） | 三方通知调用用户的入住状态 | |||
住宿预售券创建和更新 | 直连必接 | 保存或更新预售券预定商品信息，单次最多传入20个商品，即单商家每秒最多保存200个商品 | | ||
直连必接 | 保存或更新预售券信息 | | |||
选接 | 通知三方预售券审核结果 | | |||
酒旅商品上架和下架信息推送 | 选接 | | 售卖房型上下架，售卖房型创建后自动上架，无需调用该接口。该接口最多支持单次传递20个商品id，单商家每秒最多保存 200 个商品 | | |
KA核销对账 | 选接 | 商家通过接口查询自己账单详情。 | |
2.酒店会员对接场景
调用方式 | 接口作用 | 是否必接 | 接口使用场景 | 时序图 |
抖音调用商家 （SPI 接口） | | 必接 | 抖音生活服务调用对接方绑定会员接口进行会员注册或绑定。 | |
| 必接 | 抖音生活服务调用对接方接口进行渠道会员解绑。 | ||
| 抖音生活服务调用对接方进行会员数据查询 | |||
商家调用抖音 （OpenAPI接口） | 对接方调用开放平台的会员信息更新接口，更新会员数据 | |||
| 必接 | 对接方调用开放平台的会员信息变化通知接口通知会员信息注销 | ||
| | |
