团队订单确认后，剩余散客价先核对什么？月房态与中央价的一轮检查

团队锁房之后，散客价为什么不该原样不动

团队订单通常是以折扣价锁定大量房源的。一笔团队预订确认之后，这家店里同一批日期的房源结构就变了：一部分房间已经被一个固定的、偏低的价格拿走，剩下的散客库存面对的供需关系，和团队确认之前已经不是同一回事。

如果剩余散客房还沿用团队预订前的那套散客价格水平，等于用旧供需关系下的判断，去卖一个已经被重新划分过的新房态。价格本身不一定马上要涨，但“要不要重新看一遍”这件事，在团队确认那一刻就已经成立了。

所以这轮动作的重点不是立刻改价，而是先弄清楚两件事：还剩多少房可以卖，以及现在挂的散客价是按什么口径在卖。

先看月房态：哪些日期、哪些房型还剩可售

月房态把视角从今天拉到未来一整月，用日期（列）× 房型（行）的网格来看可售情况：每一列表头是日期，下方标出该门店当日总可售量；每个房型行在各日期格里显示「余N」，也就是该房型那天还剩几间可售。房型行还可以展开到具体房间，需要看单间时再逐层往下点。

网格里还有两类状态值得注意：某间房某天被设为不可售时，格子会显示「停用」；某个房型某天已经没有任何余房时，会显示「售罄」。两者都不进入可售，但原因不一样，一个是人为关掉的，一个是已经卖完的，核对时分开看才不会误判还剩多少可卖。

图中所展示的就是月房态视图：横轴排开日期，纵轴按房型列开，格内能看到剩余可售与状态标记。团队确认之后，第一件事就是顺着团队占用的那几天，一格一格看过去——把“还剩多少能卖”落到具体的日期和房型上，而不是凭印象估一个大概。

月房态跨天可售

再看中央价：当前散客价与渠道系数是一个什么口径

路客云 SPMS 以中央房态、中央房价为底座：房态、房价各维护一套，系统据此推算并同步到各直连渠道，做到全网一个口径、一致售卖。对经营者来说，这意味着“这家店这段时间散客卖多少钱”有一个统一维护的位置，而不是每个渠道各挂一套说法。

房价用「中央价」一处定价，配合渠道系数为各渠道推算售卖价，再同步到渠道。中央价日历维护的是基础价、划线价、实际卖价这三层价格及渠道系数，因此要判断剩余散客价是否需要调整，先要在这里看清对应房型、对应日期当前维护的是什么价、渠道系数是怎么设的。

图中所展示的是中央价日历，价格按房型与日期排列维护。核对时建议把月房态里看中的那几天、那几个房型，对照到中央价日历上同一位置：先确认现在挂出去的散客价属于哪一层、口径是否还是团队确认前的那一套，再决定动不动它。

中央价日历

先核对、后定价：一轮检查怎么落在同一个后台里

把前面两步连起来，就是一轮有先后顺序的检查：团队订单确认后，先在中央房态日历上按天、按房型核对剩余可售与停用／售罄，弄明白目标日期到底还剩什么；再到中央价日历上确认对应房型、对应日期的当前散客价与渠道系数口径。两边的信息对齐之后，再去判断剩余散客库存的价格要不要脱离团队预订前的水平。

之所以能按这个顺序走下来，是因为在路客云 SPMS 里，房态与房价各维护一套，并同步到已直连的各渠道。核对剩余可售和确认当前散客价口径这两步，加上核对之后的改价，都在同一个后台完成，不必在多个平台之间来回切换、对同一批房反复确认。

至于最终调不调、调到什么水平，仍取决于每家店对剩余库存的供需判断，本文不给出具体价格结论。这一轮检查的价值在于：先把房态和价格口径这两个事实摆清楚，再动手改价。