识别断层
忠诚计划停在大堂。
很多酒店都有会员体系，但能让餐厅、SPA 和第二家门店真正看见的，并不多。
01
同一个客人的四个版本
PMS、餐厅、SPA 与销售表格各存一部分档案。偏好互相冲突，历史永远不完整。
02
积分用不出去
客人在一个营业点攒积分，却在另一个营业点无法使用；余额还要打电话去前台问。
03
靠记忆管理合约
协议价、佣金条款与授权签单人散落在邮件里，而不是在给客人记账的系统里。
能力地图
客人，都在一处。
为希望把“识别”变成运营能力、而不只是钱包里一张卡的酒店而设计。
01
客史档案
一份随着每次住店和用餐不断变厚的记录。
- 住店历史、偏好与重要日期
- 重复档案识别与合并
- 备注、提醒与服务请求
- 同意与沟通偏好
02
会员与忠诚
等级、积分与权益，在服务现场看得见、用得上。
- 等级规则、权益与升级条件
- 积分累计、兑换与手工调整
- 储值与预付余额
- 电子券与会员礼遇
03
协议单位与旅行社
订单背后的商业关系，和账户放在一起。
- 协议单位档案、房价与信用条款
- 授权签单人与转账路由
- 旅行社佣金与对账
- 销售活动与拜访记录
04
运营中的识别
档案必须出现在做决定的地方——前台、餐厅、楼层。
- 入住时的 VIP 与常客提示
- 餐厅里的忌口与偏好提醒
- 生日与纪念日名单
- 客源结构与价值报表
能力
| 核心模块 | 能力 |
|---|---|
| 客史档案 | 住店历史、偏好与重要日期 |
| 客史档案 | 重复档案识别与合并 |
| 客史档案 | 备注、提醒与服务请求 |
| 客史档案 | 同意与沟通偏好 |
| 会员与忠诚 | 等级规则、权益与升级条件 |
| 会员与忠诚 | 积分累计、兑换与手工调整 |
| 会员与忠诚 | 储值与预付余额 |
| 会员与忠诚 | 电子券与会员礼遇 |
| 协议单位与旅行社 | 协议单位档案、房价与信用条款 |
| 协议单位与旅行社 | 授权签单人与转账路由 |
| 协议单位与旅行社 | 旅行社佣金与对账 |
| 协议单位与旅行社 | 销售活动与拜访记录 |
| 运营中的识别 | 入住时的 VIP 与常客提示 |
| 运营中的识别 | 餐厅里的忌口与偏好提醒 |
| 运营中的识别 | 生日与纪念日名单 |
| 运营中的识别 | 客源结构与价值报表 |
酒店现场
走近一点。
产品界面
真实界面截图。
来自实际部署的界面截图。系统支持中英文报表与单据。
一段客人旅程
从第一次入住，到被认出的常客。
档案安静地累积，客人不必反复介绍自己。
第 1 次
建立档案
入住时采集联系方式、同意与住店偏好，并与已有记录做重复检查。
第 2 次
偏好被使用
房型偏好与忌口在抵店前和餐厅里浮现，团队能据此行动。
第 3 次
等级发生变化
间夜与积分触发等级复核。下次到店时，前台与餐厅都能看到权益。
第 6 次
账户变成关系
会员或协议条款、住店历史与营业点消费，在销售与前台处合成一个视图。
数据纪律
档案只有被信任才有用。
客史会老化。这个模块围绕“保持新鲜、保持合并、保持授权”来设计。
合并，而不是复制
重复识别与受控合并流程把记录合成一条，不丢住店历史，也不丢余额。
同意是记录下来的，不是假设的
营销同意与沟通偏好随档案保存，并被营业点与活动工具遵守。
访问权限跟着角色走
前台、销售与财务看到不同深度的档案。敏感备注与商业条款单独授权。
- PMS 客史与住店历史
- POS 客人识别
- 储值与支付余额
- 活动与消息工具
- 协议房价与佣金数据
- 报表与客群分层
常见问题
常见问题
这是一个独立的 CRM 吗？
不是。它是同一平台的宾客层。前台建立的档案，就是餐厅、销售与报表使用的档案，不需要同步任务，也没有第二个事实来源。
现有会员余额可以迁移吗？
可以，取决于原系统能提供的数据。积分、储值与等级会连同一份对账报告一起迁移；异常余额在切换前单独复核。
重复档案怎么处理？
系统根据联系方式与住店历史标记疑似重复，并提供受控合并，保留两条记录的历史与余额。合并操作会留痕。
不同门店可以用不同的会员方案吗？
可以。集团方案与门店权益可以并存，前提是在配置阶段把权限与报表结构定清楚。
支持营销同意的合规要求吗？
同意与沟通偏好按档案保存，可用于筛选营销名单。具体措辞与当地法规要求仍应由你的法务团队确认。
下一步
用你自己的流程，来看这套系统。
一次 30 分钟的演示，围绕你的业态和正在使用的系统展开。不是念 PPT——我们直接走进入住、账单、夜审和报表。
通常在一个工作日内回复。