民宿预约小程序的关键不是先做页面，而是先统一“房型—日期—库存—价格—订单”规则，再让用户按入住和离店日期完成下单。日期应按“含入住日、不含离店日”计算，配合支付占房、渠道同步和人工锁房，才能降低超卖风险。下面以两间虚构客房为例，演示完整操作。
先确定预约小程序要管理什么
至少准备四类基础数据：房型、可售库存、日期价格、订单状态。若民宿同时在多个平台售卖，还要明确哪个系统负责库存主数据，以及渠道回传的频率和失败处理方式。
用户端通常需要完成：选择入住与离店日期、选择房型和套餐、填写入住人信息、提交支付、查看订单、申请取消或改期。管理端则要能查看房态日历、处理订单、锁定房间、调整库存和核对渠道订单。
一个容易遗漏的规则是：离店日不占用夜晚库存。例如客人 6 月 10 日入住、6 月 12 日离店，实际占用 6 月 10 日和 11 日两晚；6 月 12 日可继续安排新客入住。
评估现成方案时，可参考酒店旅游小程序的预订与客房管理范围，再用连续多晚、锁房和渠道同步场景实测。
虚构演示：两间房连续多晚如何配置
以下为教学用途的虚构示例，不代表任何真实民宿数据。
民宿有两个可售房型，每个房型各 1 间：
- 山景大床房 A：基础价 480 元/晚。
- 庭院双床房 B：基础价 560 元/晚。
- 可售日期：6 月 10 日至 6 月 15 日。
- 每个房型每日基础库存均为 1。
第一步：建立日期库存表
在房态日历中，为 A、B 两个房型分别维护每日可售数。初始状态下，6 月 10 日至 14 日每晚库存均为 1；6 月 15 日仅作为可能的离店日，不应因前一笔订单被自动占用。
输入判断：如果房型是“1 间可售”，就不能只按整个订单判断有无房，必须逐晚检查日期区间内的库存。
结果：客人选 6 月 10 日入住、6 月 13 日离店时，系统需校验 A 房在 10、11、12 日三晚都至少有 1 间库存，才允许进入下单页。
第二步：设置套餐和逐晚价格
可将价格设计为基础房价加套餐，而不是把所有内容写死在一个价格中。例如：
- A 房标准套餐：480 元/晚。
- A 房含双早套餐：530 元/晚。
- B 房标准套餐：560 元/晚。
- 6 月 12 日为高需求日，A 房标准套餐调整为 580 元/晚。
若用户选择 A 房含双早套餐，6 月 10 日入住、6 月 13 日离店，系统应逐晚计算：530 + 530 + 630 = 1690 元。这里 6 月 12 日是在对应基础价格上加入早餐后的价格。
输入判断：套餐是否影响每日价格、人数限制、早餐份数或取消条件，需要在商品规则中明确。若套餐名称相同但规则不同，应拆分为不同可售产品，避免前台展示和后台履约不一致。
第三步：支付前后怎样占房
客人甲选择 A 房，6 月 10 日入住、6 月 13 日离店，提交订单。
较稳妥的处理是：订单创建后先进入“待支付占房”状态，对 10、11、12 日暂扣 1 间库存；在设定的支付有效期内未完成支付，则释放库存。支付成功后，订单转为“已确认”，对应日期库存由 1 变为 0。
结果：此时另一位用户再选择 A 房的 6 月 11 日至 6 月 12 日，系统应提示无房，或自动推荐 B 房、其他日期。因为其入住区间与甲订单占用的 6 月 11 日发生重叠。
不要只在支付成功后才扣库存，否则多人同时进入支付时，可能出现都支付成功却只有一间房的情况。具体的锁库存方式、锁定时长和支付回调处理，要结合所使用的小程序、支付服务和订单系统实际能力核验。
取消、改期和人工锁房怎么处理
取消订单后的库存回补
客人甲若在允许取消的规则内取消 6 月 10 日至 13 日的 A 房订单，管理端确认取消或系统按规则自动取消后，应将 10、11、12 日的库存逐晚恢复为 1。
输入判断：订单是否已入住、是否已退款、是否涉及渠道订单，决定库存是否立即回补。不要仅修改订单备注而不更新房态，否则前台仍会显示无房或产生账实不符。
改期要按“释放旧日期、校验新日期、再占新日期”执行
客人甲希望改为 6 月 12 日入住、6 月 15 日离店。先检查 A 房在 12、13、14 日是否均有库存。假设 12 日仍被原订单占用，而 13、14 日可售，则应在同一笔改期操作中完成旧日期释放和新日期重算，避免中间状态把房间错误卖出。
改期后价格可能变化。应明确采用原订单价格、改期当日价格还是补差价规则，并让客人在确认前看到新的入住区间、金额和退款或补款结果。
人工锁房用于线下客、维修和特殊安排
管理员可对 B 房的 6 月 11 日至 13 日设置人工锁房，原因填写“线下预订”或“设备维修”。锁房后，这两晚的线上可售库存应为 0，但锁房记录应可追溯，避免员工误以为是普通订单。
人工锁房不能替代正式订单管理。若是线下客入住，仍建议建立对应订单或登记记录，以便核对入住、收款、清洁和后续改期。
渠道同步与商城、客房管理对接要核验什么
如果小程序商城、前台客房管理工具和第三方渠道同时售房，最重要的是确认库存是否共用、订单是否双向同步、失败时谁负责人工补救。
上线前可按以下场景逐项测试：
- 小程序支付成功后，其他渠道的同日库存是否减少。
- 外部渠道进入订单后，小程序是否及时显示无房。
- 取消、改期、退款后，各端库存和订单状态是否一致。
- 人工锁房是否能传递到需要限制销售的渠道。
- 同一时间两端下单时，是否存在重复确认风险。
订房营销商城与客房管理系统的对接，不应仅凭“支持对接”的描述判断可用。需要核验可同步的字段范围，例如房型映射、库存、房价、入住人、订单状态、取消和改期；还要确认异常订单、网络延迟、重复回调和人工介入的处理流程。未核验前，不宜承诺实时同步或完全避免冲突。
需要把预约、到店服务和会员维护放到同一经营链路时，可参考有赞公开的本地生活解决方案，再按民宿实际房态、人员安排和服务规则核验适用范围。
上线前按这个顺序执行
先整理房型和真实可售房间，再建立逐日库存与价格规则；随后配置入住离店日期、支付、取消和改期规则；最后用测试订单走完支付、取消、改期、锁房和渠道同步场景。测试通过后，再开放用户端预约入口。
建议每天固定核对一次未来日期房态：比较小程序订单、线下登记、人工锁房和渠道订单，优先处理库存不一致的日期。这样即使对接存在延迟，也能在客人到店前发现问题。
常见问题 FAQ
小程序是否必须按具体房间售卖？
不一定。房量较少且房间差异明显时，可按具体房间管理；房间配置一致时，可按房型管理库存。但无论采用哪种方式，都要保证一个可售单位不会被重复占用。
为什么离店当天还能被另一位客人预订？
因为订房日期通常按夜晚计算，入住日包含在占用区间内，离店日不包含。前提是清洁、交接和实际入住时间能够安排；若需要留出清扫缓冲，应通过房态规则或人工锁房提前预留，而不是改变日期计算逻辑。
待支付订单要不要占库存？
一般需要短暂占用，否则多人并发支付容易超卖。但占用多久、超时如何释放、支付成功回调失败如何处理，要根据实际系统能力配置并测试，不能只依赖页面显示。
渠道不同步时还能继续售卖吗？
应先判断不同步影响的是价格、库存还是订单状态。若关键日期库存无法确认，较稳妥的做法是暂时关闭该日期或该渠道销售，并完成订单核对后再恢复，避免继续扩大冲突。
取消政策应该写在哪里？
应同时展示在套餐或预订确认页面、订单详情和取消申请流程中。至少说明免费取消截止点、不可取消情形、退款处理方式及改期限制，避免用户付款后才发现规则不一致。
