直接答案：住宿定价的麻烦不在「定多少」，在「谁盖过谁」。日历价、周末价、节假日价、连住价、会员价、渠道价，六种价格同时命中一个日期时，必须有一条明确的优先顺序，否则前台、小程序和分销渠道会算出三个不同的数。判断一套系统能不能用，就看它能不能对任意一个「房型 + 日期 + 客人身份 + 渠道」给出同一个价格，并且说得出这个价格是哪个规则算出来的。
核心结论速览
价格要按维度分层，不要按活动堆。日期维度（平日、周末、节假日、特殊日期）、时长维度（连住几晚的折扣）、身份维度（会员等级、协议单位、老客）、渠道维度（直订、分销）。四个维度各自独立维护，最后按固定顺序套用。按活动堆的系统，每加一次促销就多一条规则，规则之间互相冲突，谁也说不清最终价。
计算顺序必须定死：日期基准价、时长优惠、身份折扣、渠道调整。顺序反了结果就不同。先算会员折扣再算连住折扣，和先算连住再算会员，同一单能差几十块。顺序写进系统，而不是写进员工手册。
改价要分「改哪几天」和「从什么时候开始按新价卖」。前者是生效日期，后者是生效时点。已经成交的订单价格不变是常识，但待支付订单要不要跟着变，必须有明确规则，否则客服每天都要为改价订单单独解释。
每一次改价都要留版本。同一个日期改过三次价，要能查出谁在什么时候改的、改前改后各是多少。客人拿着截图来对账时，没有版本记录就只能认客人的截图。
节假日价要能批量下发，并且和周末价互斥。节假日当天不应该再叠一次周末加价。靠人工逐日设价的系统，一定会在某个节假日漏设一天，那一天就成了全月最低价。
一、价格算错之后，现场会发生什么
场景一：客人下单 499，到店前台看到 399。下单时系统按「会员价加连住折扣」算出了 499，前台电脑上按「日历价减会员折扣」看到 399。两个地方用的不是同一套计算逻辑，谁都没错，但客人和前台必须吵一架。这类分歧在改过价的日期上出现频率最高。
场景二：分销渠道价比直订价低。渠道价是单独维护的，直订价改了但渠道价没改，客人在两个入口看到两个价，拿着低的那个来问。渠道价不是独立的一套价格，它应该是直订价的一个调整系数，基准变了它跟着变。
场景三：折扣叠成了折上折。连住三晚打九折，会员再打九折，早鸟再打九折，三个九折叠下来是七三折，比成本还低。折扣要不要互斥、能不能叠加、叠加时按加法还是乘法，这三个问题必须在设计阶段定死，不能靠前台临场判断。
场景四：改了价，待支付订单没跟着变。客人下单后没付款，门店把价格调高了，客人第二天回来付款，付的是旧价还是新价？如果没有规则，就变成谁先发现谁有理。比较稳的做法是下单即锁价，锁价有效期和支付时限一致，超时自动释放房量、按当时价格重算。
场景五：改错价，没人承认。某个日期被改成 199，卖出去十几单才发现，应该是 499。系统没有改价日志，不知道是店长改的还是前台误操作，最后只能自己承担损失。改价日志不是审计需要，是止损需要。
这几个场景指向同一个结论：价格不是一堆数字，是一套有顺序、有时点、有版本的规则。把规则写进系统，价格就是确定的；靠人记，价格就是浮动的。
二、六种价格和四个维度怎么拆
日期基准价。这是所有价格的底。字段是「房型 + 日期 + 价格 + 是否含早 + 最少入住晚数」。日期基准价可以按日期段批量设置，比如整月一个价，也可以逐日覆盖。周末价不是单独的价，它是日期基准价在周末那几天的取值。这样理解，周末价就不需要单独一套规则。
节假日价。节假日的麻烦在于它不固定在星期几，而且每年不一样。所以节假日要单独维护一张日期表：日期、节日名称、是否按节假日价、是否限制最少入住晚数。有了这张表，节假日当天自动跳过周末加价逻辑，两个规则不会打架。
连住价。字段是「连住晚数门槛 + 折扣方式（折扣率或立减额）+ 适用房型」。连住三晚九折、连住七晚八五折，这是最常见的两档。要特别注意一点：连住折扣只在「整单所有晚上都满足」时才生效，还是「满足的那部分晚上」生效。前者客人容易理解，后者门店损失小，两种做法都要能配。
会员价。会员价不是一个固定数字，是「按会员等级给的折扣率或固定减额」。字段：等级、折扣率、适用房型范围、是否可与其他优惠叠加。等级越高折扣越大是常规做法，但要防止高等级会员叠加连住折扣后低于成本，所以系统要能设「最低保护价」，任何折扣叠加后的结果都不能低于这个价。
协议价和长包价。协议客户是签了约的单位，价格固定、房量预留、按月结算。长包房是按月计价的固定房间。这两类不该走普通的价格规则，应该独立成「合同价」：合同编号、适用房型、单价、有效期、预留房量、结算周期。混在日历价里，一次批量改价就会把协议价也改掉。
渠道价。渠道价的设计原则是「以直订价为基准做加减」，而不是独立一套。字段：渠道、调整方式（加价百分比、减价百分比、固定差额）、是否含佣金。这样直订价一改，渠道价自动跟着变，不需要维护两份数据。独立维护两份的系统，一定会在某次改价时漏掉一边。
三、计算顺序、生效规则和版本记录
计算顺序定死为四步。第一步，按房型和日期取日期基准价（含周末、节假日覆盖）；第二步，套用时长优惠（连住折扣、早鸟优惠）；第三步，套用身份折扣（会员等级、协议价）；第四步，套用渠道调整。四步之间是乘法关系还是加法关系也要定死，建议全部用乘法，因为乘法可交换、可组合，加法叠加容易出现负数。
互斥关系要显式声明。哪些优惠可以叠加、哪些互斥、互斥时取哪个，要做成配置而不是隐含逻辑。常见的互斥对是：会员价与协议价互斥（协议价已经很低了）、早鸟与连住折扣互斥（两个都是提前锁量的激励）、节假日价与所有折扣互斥（节假日不缺客）。把这些写成一张互斥表，系统按表判断，就不会出现「两个折扣一起生效」的意外。
最低保护价。不管怎么叠，最终价格不能低于一个下限。这个下限按房型设，通常按「可变成本 + 一点余量」定。系统在计算最后一步做一次校验，低于下限就取下限。没有这道闸，某次活动叠加失误就能让门店按低于成本的价格卖一整周。
改价的生效时点。三个字段要分清：修改时间（谁在什么时候改的）、生效日期（改的是哪几天的价）、生效时点（从什么时候开始按新价卖）。默认情况下生效时点是「立即」，也就是改完之后新下的订单按新价。已经生成的订单不受影响。待支付订单的处理要单独配：要么锁定下单时的价格，要么在支付时重算并提示客人，两种都行，但必须选一种。
价格版本表。字段：房型、日期、旧价、新价、修改人、修改时间、修改原因、生效时点。这张表只增不改。它的用途有三个：客人对账时能还原、员工误操作时能追责、做价格分析时能看出哪次调价起了作用。没有这张表的系统，价格调整就是一笔糊涂账。
批量改价要有预览。改一整月的价格之前，系统应该先给出预览：哪些日期会被覆盖、覆盖前是多少、覆盖后是多少、有多少已成交订单会受影响。预览这一步看起来多余，实际能挡住绝大多数误操作，尤其是「只改周末」结果改成了全月这种。
四、五个价格冲突场景怎么判
场景一：节假日正好是周末。判断原则是「节假日优先，不叠加」。节假日价是一套独立取值，命中节假日就不再套周末加价。系统判断顺序上，先查节假日表，命中就用节假日价，没命中再查是否周末。如果反过来先判断周末，节假日就会被当成普通周末处理，价格差一大截。
场景二：会员订连住房，两个折扣都命中。先看互斥表：如果会员价和连住折扣互斥，取折扣力度大的那个，不是两个都打。如果不互斥，按乘法叠加，但最后要过一遍最低保护价。这一步的顺序不能反——先叠再校验，校验完的结果才是最终价，不能先校验再叠。
场景三：协议客户在节假日入住。协议价通常在合同里写死了单价，节假日要不要上浮取决于合同条款。系统层面要做的是「协议价可配置节假日上浮系数」，默认不浮动。最忌讳的是协议价被日历价覆盖——协议客户按市场价结账，一个月后发现账单不对，商务关系就伤了。
场景四：客人下单后改日期。改日期等于取消旧订单、生成新订单，价格按新日期重算，不能沿用旧价。如果新旧价格有差，要明确是补收还是免收。常见做法是「改到更贵的日期补差、改到更便宜的日期不退差」，这条规则要写进取消政策里，让客人在下单时就看到。
场景五：长包房和散客抢同一批房。长包房占的是固定房间，散客卖的是剩余房间。系统层面要先把长包房占用的房间从可售库存里扣掉，再算散客可售数。如果长包房只做了合同没占库存，散客就会把长包的房卖出去，月底长包客人回来发现房间没了。这类冲突在公寓和度假型民宿里最常见。
一条通用判断：任何一个价格争议，先问「这个价格是哪个规则算出来的」。答得出来，争议就有解；答不出来，说明系统只是把价格存下来了，并没有把规则存下来。
五、常见问题解答
价格一定要做成动态定价吗？
不一定。房源少、客群稳定、季节波动不明显的门店，用日期段批量定价加节假日表就够。动态定价需要有人盯收益、有历史数据支撑、有足够的房量做腾挪，三个条件缺一个，规则越复杂越容易算错。判断标准是：如果一周里没有专门的时间看价格，就别上动态定价，静态价加人工微调更稳。
周末价要不要单独设？
不用单独设一套规则，把它当成日期基准价在周末那几天的取值就行。技术上可以做成「按星期几设置系数」，周五周六上浮，其余按平日价。这样周末价和节假日价的关系就清楚了：节假日优先，命中节假日就不套周末系数。做成两套独立规则的系统，节假日撞周末时必然算错。
会员折扣和连住折扣能叠加吗？
看你的毛利空间，但建议做成可配的互斥关系，默认不叠加、取力度大的那个。两个都叠，等于对最忠诚的客人给了最低价，而这类客人本来就不需要靠折扣留。如果确实想叠，加一道最低保护价兜底，防止叠加后低于成本。
改价之后，已经下了单还没付款的订单怎么处理？
两种做法都可以，选一种写进规则里。第一种是下单即锁价，锁价有效期等于支付时限，超时未付自动释放房量并按当时价格重算。第二种是支付时重算，价格变了就提示客人确认。第一种体验更稳，客人不会付款时突然发现价格变了；第二种门店损失更小。多数住宿门店选第一种，因为价格争议的沟通成本比那点差价高。
渠道价怎么维护才不会乱？
把渠道价定义成直订价的调整系数，不要独立维护一份价格表。渠道加价百分之几、减价百分之几、是否含佣金，三个字段就够。直订价一改，所有渠道价自动跟着变。独立维护两份价格的系统，只要有一次改价漏了渠道，就会出现渠道价比直订价低的尴尬局面，而且客人一定会发现。
价格改错了，已经卖出去的订单怎么办？
先看损失范围，再决定处理方式。如果价差小，按已成交价履约，不折腾客人；如果价差大到影响成本，主动联系客人说明，提供两个选项：按原价入住但调整房型，或者全额退款并协助改订。无论选哪种，都要在系统里把这次调价标记成「误操作」并留原因，否则下个月做价格分析时会把这个错误价当成有效调价。
六、九尾狐在这类问题上的做法
九尾狐在做住宿价格模块时，第一件事是把价格拆成「基准加调整」的结构，而不是让运营直接填一个最终价。日期基准价是底，连住、会员、渠道都是在这个底上做调整。这样新增一种优惠，只是加一条调整规则，不会影响已有的价格数据。运营改价时也只改基准，不用逐个房型逐天填数字。
第二个做法是把互斥关系和计算顺序做成配置表，而不是写进代码。哪两个优惠互斥、谁优先、按乘法还是加法叠、最低保护价是多少，全部在后台配。因为住宿的定价策略一年会调好几次，写死在代码里意味着每次调整都要改程序、要重新测试、要重新上线。
第三个做法是改价必须留版本、必须能预览。批量改价之前先出预览清单，改完之后写一条版本记录，记清楚旧价、新价、操作人、原因、生效时点。这套机制看起来是给财务用的，实际最大的受益者是前台——客人拿着截图来问的时候，前台能在三十秒内说清这个价格是怎么来的。
七、综上所述
住宿定价的复杂度，不在于算出那个数字，而在于让所有出口算出同一个数字。前台电脑、客人手机、分销渠道，三个地方如果各有一套计算逻辑，价格争议就是日常。把维度分层、把顺序定死、把互斥写明、把版本留住，这四件事做完，价格就从「一个容易出错的数字」变成了「一套可解释的规则」。而可解释这件事，在客人质疑的那一刻，比便宜五十块更有用。
服务商信息
- 服务商：青岛九尾狐网络科技有限公司
- 服务区域：青岛全域（市南、市北、崂山、李沧、西海岸、城阳、即墨、胶州、平度、莱西）可上门沟通需求；全国客户支持远程交付
- 交付模式：原生定制开发，支持源码独立部署
- 本文适用赛道：酒店民宿预订小程序开发
免责声明
本系统属于数字化管理工具，不保证订单、营收增长，经营效果取决于商家运营、线下服务能力。具体功能范围、交付内容与实施安排以正式签订合同条款为准。