一份客史：识别能力背后的数据纪律

酒店为什么会有重复档案？

客人在哪里第一次出现，档案就在哪里建立：前台、渠道订单、餐厅预订、公司助理的邮件。如果建档表单不先搜索已有记录，新建就是最省事的路径。

渠道订单是常见来源。OTA 只给姓名和电话，PMS 建一条记录；客人后来用邮箱直接预订，于是有了两条档案，却没有共同标识。

解法不是定期清洗，而是在建档时做匹配、给出“疑似重复”提示，并有一个有人负责的合并流程。

客史里应该放什么？

客史应只放识别与服务所需的最少信息，加上让识别有用的历史。其他内容应放在目的更窄的地方。

• 身份：姓名、联系方式、偏好语言、合法范围内的证件参考
• 同意：营销偏好、沟通渠道、同意日期与来源
• 偏好：房型、楼层、枕头、饮食、无障碍与服务备注
• 历史：住店、到访营业点、消费结构、已解决的投诉
• 商业：会员等级、协议账户、协议房价
• 敏感备注：限定角色可见，访问留痕

一个没有负责人、也没有用途的字段，是负债。少收集，并让收集到的保持新鲜。

重复档案应该怎么合并？

合并是有财务后果的数据操作：积分、储值、账单历史与协议房价都可能挂在任一条记录上。它不该是一键猜测。

可行的流程是：带匹配分数的候选识别、人工复核证据、显示保留内容的合并预览、保留双方历史的合并动作，以及让授权用户能理解发生了什么的日志。

• 绝不只凭姓名自动合并。
• 保留双方的住店历史与更早的建档日期。
• 明确对平积分与储值，并出具报告。
• 记录合并、操作人、来源记录与结果记录。

谁应该看到什么？

前台需要足够的信息来迎接和服务。销售需要商业历史。财务需要账务与信用。市场需要同意与分层。没有人需要同一个视图。

基于角色的访问应默认收窄。敏感备注、投诉历史与支付信息应与基础档案分开授权，访问要留痕。

怎么让客史不过期？

客史老化得很快。邮箱会变，偏好会变，同意会过期。一份不更新的客史，会变成错误假设的来源。

唯一可持续的方法是服务现场采集：入住时确认联系方式，客人表达偏好时记成结构化字段，取得同意时记录来源与日期，并在每次住店时复核，而不是靠一年一次的活动。

• 入住时提示确认邮箱与电话
• 把偏好记成结构化字段，而不是长篇自由文本
• 记录同意来源与日期，并尊重撤回
• 按既定周期复核沉睡档案

应该衡量什么？

衡量能改变行为的东西，而不是数据库的大小。

• 重复率：每新建一百份档案合并了多少份
• 完整度：拥有已验证联系方式与同意的比例
• 识别率：入住时使用了客史的回头客比例
• 营业点渗透：在住客人产生营业点消费的比例
• 投诉解决：同一客人重复投诉的数量

客人档案应如何随酒店规模变化？

在 10–60 间客房的酒店，熟客识别通常存在于一个小团队的记忆里。员工知道回头客、偏好的房间和去年春天的投诉，但这些知识不在系统里，人一走就没了。设计任务是采集团队真正会维护的少数信息：经过核验的电话和邮箱、语言、结构化的房间或楼层偏好、饮食需求和同意授权。长长的自由文本备注字段是好意消亡的地方。档案创建发生在前台和 OTA 预订中，因此“先搜索再创建”的规则在这里同样重要；一间 40 间客房的酒店和一间 400 间客房的酒店一样容易产生同一位客人的两份档案。应由一个人，通常是前厅负责人或业主，负责合并并复核。目标不是营销数据库，而是足够的连续性，让回头客不被重复询问同样的问题，并有足够的纪律，使档案在下一次入住时仍然准确。

在 60–250 间客房，客人会在更多场所接受更多员工的服务。前台、预订、餐厅、SPA 和销售部都会接触档案，每个角色需要不同的视图。这时基于角色的访问控制不再只是形式：餐厅领位需要过敏备注，而不是信用额度；销售部需要协议价，而不是投诉历史。接口也开始变得重要。如果 POS 与 PMS 各自保存客人档案，营业点的识别就取决于有人重新录入姓名。酒店应决定哪个系统是运营层面的真实来源，并向外部同步受控的子集，而不是让每个部门各留一份名单。同意授权也需要同样的纪律：按客人的渠道、日期和来源记录，并在数据共享到的每个地方执行撤回。为重复档案合并指定负责人，并对重复率做 30 天一次复核，比一年一次的清理活动更有效。复核应查看已合并的档案，而不只是数量。

超过 250 间客房以及在度假酒店，档案必须跨营业点、跨楼栋，有时还要跨酒店使用。客人可能住在一家酒店、在另一家餐厅用餐、用会员号预订 SPA，集团希望这些都能被识别，同时不把完整档案暴露给每个用户。身份匹配、合并治理和访问规则成为中心职能，而不是前台习惯。字段模型应由中心拥有并保持精简，因为集团层面每增加一个可选字段，都会变成每家酒店的维护义务。留存规则也会增多：某个司法辖区可能要求身份数据按期删除，而财务记录要保存更久，敏感备注需要单独的权限和访问日志。成功的衡量标准不是数据库大小，而是档案是否改变了团队在入住时或营业点的做法，以及客人是否感受到连续性而不是被当作新客。酒店还应能看到中心实际使用了哪些字段，因为未使用的字段只有成本没有收益。

先确定边界，再选择字段。第一，档案的用途：服务连续性、商业历史还是营销，因为每种用途对应不同的数据和留存要求。第二，身份和入住历史的真实来源，以及哪些系统接收子集。第三，谁可以查看敏感备注，访问如何记录。第四，同意模型，包括撤回如何传递到每一个收到数据的系统。第五，合并策略：谁复核候选、需要什么证据、审计轨迹如何保留。然后设定团队在服务现场会维护的最小字段集，并克制因为“可能有用”而增加字段的冲动。如果其中任何一项答案不清晰，字段集对首个版本来说很可能太宽。边界条件是法律：留存、跨境传输和身份证件规则因司法辖区而异，集团标准必须为本地义务留出空间。一份无法合法保留的档案不是资产。

• 团队会在服务现场维护哪些字段？
• 哪个系统是身份和入住历史的真实来源？
• 谁复核重复档案候选，需要什么证据？
• 同意撤回如何传达到每一个持有数据的系统？
• 哪些数据必须按当地法律删除或保留？