云 PMS · 餐饮 POS · 会员 · 采购
让酒店， 井然有序。
一套系统管好整座酒店——预订、前台、客房、餐饮与财务在同一处协同。让班次时间留给客人，而不是留给四块互不相通的屏幕。
直接回答
酒店 PMS 是客房、房价、客人、账单、房务与报表的事实来源。它连接预订、前台、账务、OTA 渠道与财务，让全店共用一份客史和一本账。可以云部署、本地部署或混合部署。
云部署、本地部署或混合部署，数据始终由你掌握。
示意酒店摄影
- 核心模块
- 12
- 报表模板
- 300+
- 对接接口
- 20+
- 部署方式
- 3
速览
酒店 PMS 速览
先看范围、部署与实施，再看功能清单。
| 项目 | 说明 |
|---|---|
| 适用规模 | 10–500+ 间房；单店或集团 |
| 核心模块 | 预订、前台、收银、房务、夜审、报表 |
| 部署方式 | 云、本地或混合 |
| 渠道与 OTA | 渠道管理、订房引擎、房价与限制同步 |
| 支付与身份 | 刷卡终端、支付网关、身份证/护照采集 |
| 门锁与客房 | 制卡与房态联动 |
| 报表 | 300+ 模板，覆盖出租率、房价、RevPAR、营业点与应收 |
| 实施周期 | 单店 4–8 周；集团分批上线 |
一条记录，从询价到离店。
核心思路
问题通常不在前台，而在系统与系统之间。
客人订房时报一次名字，入住时再报一次，餐厅里第三次，月底财务对账时还要第四次。每一次交接，都是信息走样的机会。我们只做一套事实来源，让客人、账单和报表不必被反复解释。
- 预订改一次，所有部门同时看到。
- 餐厅入的账，第一次就落在正确的账单上。
- 集团报表与单店报表，用的是同一套口径。
时间漏在哪里
系统割裂的四笔隐性成本。
大多数酒店不是被一次大故障拖垮的，而是被每个班次都要重复一遍的小核对拖住的。
01
同一个客人，录了四遍
客史散落在 PMS、餐厅、会员工具和表格里。偏好传不到该到的人手上，同一位 VIP 在第二个营业点仍被当作陌生人。
02
对不上的账单
营业点消费被批量导入、二次录入或产生争议。前台花整个下午，去还原客人早已签过字的那笔账。
03
决策之后才到的报表
夜审结束得晚，月结要几天，经营会看的是上周的数据，而不是今早的。
04
房态不在同一页上
房态靠对讲机和记忆更新。客人等着一间二十分钟前就该好的房，或者走进一间还没做完的房。
设计约束
每个模块都必须遵守的三件事。
加功能不难，难的是保持一致。从预订界面到集团合并，我们按这三条约束来设计。
01
一份客史
档案只建一次，在各处补充：住店历史、偏好、会员等级、合约单位、账单记录。任何营业点都不再保留私副本。
02
一本账
客房、餐饮、宴会、SPA、电话与杂项消费进入同一套账单结构，支持分单、转账规则与完整的审计轨迹。
03
一套报表口径
出租率、平均房价、RevPAR 与客源分类只定义一次，在所有门店统一执行。集团报表是汇总，而不是一场对账工程。
平台
按部门走一遍。
每个界面背后是同一个数据库。今天需要哪些模块就先上哪些，后续增加不需要再迁移一次。
前台
从询价到房卡，都在一个界面。
散客、团队与时租预订；等待队列；锁房；订金；证件识别入住；升级；续住；换房；分单；快速离店。
- 可售房与房价日历，支持各类限制条件
- 团队房块（Block）、名单与批量入住
- 订金、信用额度与转账规则
- 合并结账或分单结账
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
客房
全酒店都信得过的一块房态板。
脏房、净房、已查、锁房与维修房实时更新。任务按楼层或区域派发，工程单直接挂在房间上。
- 按楼层、区域与房型查看实时房态
- 任务派发、查房与周转时间
- 工程报修与维修房控制
- 楼层员工移动端更新
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
餐饮与宴会
一杯咖啡和一场婚宴，结在同一张单上。
餐厅、酒吧、送餐与宴会共用客史。消费可挂房账、公司账或宴会账，支持厨打与分单。
- 餐位图、翻台与客数
- 厨打与出菜时序
- 挂房账与信用检查
- 宴会活动、包价与 BEO 入账
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
收益与渠道
房价、限制条件与渠道，集中管理。
季节房价、包价、出租率与连住限制、协议单位与渠道连接集中维护，前台即时生效。
- 房价方案、包价与衍生房价
- 与主流 OTA 的渠道管理对接
- 协议单位与旅行社合约
- 预测与订房进度报表
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
财务与夜审
每天夜里，按时关账。
可配置的夜审清单、自动过租与入税、应收账龄、佣金计算与完整交易日志——每一笔更正都留痕。
- 可自定义的夜审流程
- 房费、税费与包价自动入账
- 应收账龄、开票与佣金
- 试算平衡与审计报表
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
集团与后台
集团管控，不牺牲门店的判断。
统一的客史与房价标准、门店自治、合并报表、采购与工程——需要一张总表，而不是一个瓶颈。
- 多店看板与合并报表
- 中央客史与房价标准
- 采购、收货与库存
- 细到按钮的权限控制
模块可用范围取决于版本与部署方式，签约前会与你逐项确认。
产品线
四个产品，一个运营内核。
先从 PMS 开始。等运营准备好了，再加入餐饮、会员与后台，不需要另起一套数据库。
01 · 核心平台 酒店管理系统
这套 PMS 面向系统与系统之间的工作：重复录入的客人、晚到的消费、已经做好却仍显示脏房的房间。一个数据库、一本账、一天只有一种版本。
02 · 营业点运营 餐饮 POS
餐厅账单不是住店之外的另一件事。点单、翻台、厨打与房账和预订在同一个系统里，客人只收到一张账单，财务只有一本账。
03 · 宾客洞察 客史与会员
客人不是一条订房记录，而是一段由住宿、用餐、偏好与例外组成的历史。这个模块把历史放在一处，让前台、餐厅和销售都看得见。
04 · 后台 采购与库存
客房收入最受关注，采购却决定毛利。申领、采购、收货、领用与盘点连接部门预算和厨房菜谱，让成本在还能控制的时候就被看见。
按业态
同一个内核，按运营方式调校。
40 间的精品酒店和 400 间的度假村，不该用同一套流程。数据模型保持一致，配置随业态变化。
酒店现场
工作发生在客房里，也发生在客房之外。
前台、早餐、宴会、房务与后台。系统的好坏，在这些现场被检验，而不是在功能清单上。
生态
边界开放，内核克制。
PMS 的价值，取决于它能和谁对话。门锁、证件阅读器、支付终端、渠道管理、电话系统、客房控制与财务软件，都通过有文档的接口连接——每个接口都被监控、记录并版本化。
查看接口清单渠道
- 渠道管理
- 直连订房引擎
- GDS 与 CRS
客房
- 电子门锁
- 客房能耗
- IPTV 与 VOD
身份与支付
- 身份证/护照阅读
- POS 终端
- 支付网关
运营
- 电话与叫醒
- 厨房打印
- 财务与 ERP
部署
数据放在哪里，由你决定。
有的集团希望托管上云，有的市场要求数据留在酒店，还有的两者都要。应用是同一套，托管方式由你选。
云部署
托管运行，天生适合多店
环境由我们托管运维，自动备份、滚动升级。新门店上线不需要再买服务器。
- 上线最快
- 集中报表
- 自动升级
本地部署
运行在你自己的网络里
完整应用部署在酒店自有服务器，适合有数据驻留或网络约束的集团。包含远程支持与升级规划。
- 数据驻留
- 本地掌控
- 局域网性能
混合部署
本地运营，总部洞察
门店服务器保证断网时前台仍可运转，合并报表在总部运行。分布式集团的务实选择。
- 业务连续性
- 集团报表
- 分批上线
01
调研
梳理现有系统、接口与报表口径，先就“什么叫上线完成”达成一致。
02
配置
房型、房价、账单、税费、营业点、角色与夜审规则，先在沙箱里搭好。
03
迁移
客史、余额、未来预订与历史数据先抽取、清洗、对平，再切换。
04
培训
按岗位在前台、营业点和财务现场培训，用你们自己的流程，不念通用课件。
05
支持
首个结账周期现场或远程值守，之后转入具名支持通道与响应时限。
按角色
周一早上，具体会变什么。
总经理
只有一套数字。
当天的出租率、房价、客源结构与营业点收入在一块看板上，能下钻到交易，而不是一张静态 PDF。
前台
少开几个页签，少排几次队。
预抵、预离、账单与换房在同一屏完成。常客在走到台前之前就被认出来。
财务
结账不用再翻箱倒柜。
夜审、应收账龄、城市挂账、佣金与试算平衡来自同一本账，每笔更正都有审计轨迹。
IT 与系统
需要照看的部件更少。
有文档的接口、基于角色的权限、操作日志，以及与你们网络现实相匹配的部署方式。
运营观察
写给酒店运营者的实务文章。
不追趋势。只写入住流程设计、夜审、数据纪律，以及那些经得起时间考验的系统决策。
常见问题
常见问题
酒店 PMS 是什么？
酒店 PMS 包含什么？
云部署还是本地部署？
可以对接 OTA 吗？
实施要多久？
价格怎么构成？
下一步
用你自己的流程，来看这套系统。
一次 30 分钟的演示，围绕你的业态和正在使用的系统展开。不是念 PPT——我们直接走进入住、账单、夜审和报表。
通常在一个工作日内回复。