给酒店集团用的住客身份金库——入住时完成证件核验，又不把原始护照和自拍照片留在供应商存储里。

1. 酒店在入住环节采集的，已经不是前台看一眼证件，而是足以引发重大泄露的身份数据。
2. 暴露文件横跨 2020 年到 2026 年 5 月，说明存储问题会长期累积，几年住客记录都可能悄悄堆在里面。
3. 流程里加入自拍核验后，隐私和合规压力已经超过老式复印证件，数据最小化因此成了更紧迫的产品要求。
4. 如今供应商一出事，酒店就得跟着做范围排查和住客通知，这会直接触发预算，让酒店想找更安全的身份处理方案，又不愿倒回人工入住。

催化因素。 Reqrea 暴露的 Tabiq 存储桶说明，外包数字化入住现在会把护照扫描件、驾照和自拍照片一存就是好几年。对酒店来说，能安全压缩身份数据留存，已经不是未来可选项，而是眼前就要采购的问题。

做一层住客身份金库，卡在酒店预订/自助机流程和真正记录入住的系统之间。产品只采一次证件影像和活体自拍，跑证件质量与匹配校验，只提取门店真正需要的字段，再把带签名的“已验证住客”记录回写到 PMS 或入住 App。原始影像不再扔进通用供应商存储，而是按严格留存策略保存、加密、分权访问，并在策略允许时自动删除。同一套控制面还给酒店运营方提供审计日志、驻留规则，以及供应商评审和事件响应所需的证据。第一步只做窄切口：在下一次安全审查或供应商续约前，替某一家酒店集团把外包数字化入住里的原始影像存储替换掉。

差异化。 通用身份验证 API 优化的是开户注册转化或欺诈评分，不是酒店场景下的留存策略、入住可审计性和对 PMS 友好的数据最小化。这个创业公司要拿下的是酒店身份控制面：什么必须留、可以放哪、谁能看、验证完什么时候该消失，都由它说了算。时间一长，护城河会来自酒店运营系统的深度集成、按门店类型和司法辖区沉淀的策略模板，以及一套越来越强的数据能力——在不伤入住完成率的前提下，把敏感影像留存压下去。

待完成任务

flowchart LR
  Buyer[Hotel digital ops leader] --> Pain[Raw guest IDs live too long in vendor storage]
  Pain --> Product[Guest Identity Vault]
  Product --> Outcome[Verified stays with lower breach exposure]

高管要点

• Reqrea/Tabiq 泄露事件说明，外包酒店入住供应商会在不知不觉中积累跨越数年的护照、驾照和自拍档案，把本该普通的到店流程变成高风险数据暴露面。
• 酒店大概率不会把数字化到店收回去：70% 的旅客表示愿意跳过前台，Mews 还称，美国已有 30% 的预订在支持该功能的场景下使用自助机入住。
• 市场缺的不是基础身份验证，而是“安全最小化”这一层：核验一次，只把必需字段和证明送进酒店系统，之后还能拿出删除与访问控制证据。
• 最值得先打的客户，是那些已经使用数字化入住、自助机或到店前登记、同时又承受人手和审计压力的多门店酒店集团；他们需要的是更安全的控制层，而不是把整个流程推倒重来。

市场定义

一层酒店身份控制能力：在到店前入住或自助机入住环节完成证件与自拍核验，然后只把策略允许的住客字段和验证状态写进 PMS 或入住系统，同时尽量压缩原始证件留存。

用户与买方

核心使用者是使用外包在线入住或自助机入住的 20-200 家门店酒店集团里的数字化运营、IT、隐私和前厅负责人。买方通常是掌管到店工具和供应商风险的 CIO、首席数字官或酒店运营 VP。

购买触发点

• 一旦遇到安全审查、泄露惊魂或供应商续约，酒店集团就必须解释清楚护照扫描件和自拍到底存在哪、留多久。 [1][4][5]
• 前台长期人手紧，让酒店即便被合规团队追着问原始证件存储，也不愿放弃自助到店。 [12][15]
• 旅客就是想跳过前台，因此运营方需要的是更安全的数字化到店模型，而不是重新回到人工复印证件。 [10][11][13]

支付意愿

酒店本来就在为到店自动化付费，因为人力和收入效果都能量化：Mews 宣传 7 个月回本、双位数工时节省，以及自助入住带来的 upsell 转化提升。也就是说，即便公开标价不多，一层身份最小化控制也可以挂靠现有数字化入住与合规预算。 [11][12][14][15]

品类动态

增长信号 2025 年旅行与旅游 GDP 同比增长 4.1%（作为行业代理指标）

验证信号

• 真实泄露已经证明，酒店入住供应商会暴露出海量身份证件和自拍档案。
• 旅客正在主动要求自助到店而不是前台排队，因此“更安全的数字化入住”是一个现实需求。
• 酒店运营端，尤其前台，依旧被人手问题压着走，因此保留自动化的控制方案更容易被 justify。
• 现有供应商已经在线采集护照影像、自拍、法定表单和支付信息，这说明流程本身已经成熟且有预算。

监管与技术约束

• GDPR 要求个人数据处理遵循最小化、存储限制和可问责原则。
• 默认隐私/设计即隐私意味着酒店及处理方应只采每个用途真正必要的数据，并默认限制存储与可访问性。
• 如果生物识别数据被用来唯一识别住客，它就属于特殊类别数据，既要合法依据，也要满足有效的特殊类别处理条件。
• 日本要求没有本地住址的外籍住客出示护照并复印，因此任何最小化产品都必须支持按规则处理例外。
• 酒店集成必须能把结果回写进 PMS、支付和自助机工作流，而且不能拖慢到店速度或影响发卡。

竞争并不轻，但大多和切口并不完全对齐。Canary 和 Mews 优先优化的是住客旅程与 PMS 效率；Chekin 优化的是合规登记与身份匹配；Agilysys 优化的是一体化自助机硬件和 PMS 工作流；Oracle 则掌握记录系统。已抓取的现有厂商里，没有谁公开把零拷贝证明、跨供应商留存治理或独立删除证据当成主叙事；它们卖的是安全存储、运营提效，或者更广的住客体验套件。

为什么现有厂商不会默认胜出

• 云 PMS 平台. Oracle 这类 PMS 供应商已经占住了住客档案和核心工作流，但它们的激励是把更多数据吸进 PMS，而不是把原始证件压缩成纯证明。
• 住客旅程套件. Canary 赢在移动入住、消息和安全交易，但它公开讲述的仍是安全托管流程，而不是独立于供应商之外的数据最小化。
• 本地合规/入住工具. Chekin 在住客报送、生物识别和智能门锁联动上很强，但它公开的合规模型依旧默认要存住客数据、跑各国上报链路。
• 自助机与硬件型到店方案. Agilysys 解决的是到店终端本身，靠原生 PMS 与发卡/发腕带集成做强闭环，但这更像工作流终点，而不是能横跨多家供应商的中立控制层。

Zero Copy Guest ID 应该先做成面向酒店集团的身份控制层，服务那些已经上线数字化入住或自助机入住的客户，而不是一上来就做大而全的住客体验套件或消费者身份钱包。第一批客户会是拥有 20-100 家门店的酒店集团：它们的数字化运营和安全团队既要保住自助到店体验，又得把护照扫描件、驾照和自拍照片的存储风险压下去。研究已经把切口说明白了：旅客想跳过前台，酒店前线人手依旧紧，而 Reqrea/Tabiq 泄露事件证明，外包入住供应商会在不知不觉中变成跨越数年的高风险身份档案库。产品该做的是验证住客身份、只提取策略允许的字段、把签名证明回写到 PMS 和入住系统，并按司法辖区执行删除或留存规则，而不是空喊“永不存储”。GTM 应该围绕具体事件、由创始人主导，专门打在审计、续约或泄露惊魂这些时点：买方此时已经有预算压力，也不接受把整条工作流推倒重来。第一个证明点，是在少量 PMS 和自助机集成上落地一个酒店集团项目，让原始影像留存明显下降，同时不伤入住完成率。公司有机会靠酒店场景策略模板、删除证据和跨供应商集成做出真正的控制层护城河，但市场证据还没回答清楚：买方究竟想要独立身份金库，还是只想让现有供应商贴牌补一个功能。研究里第 3 年的初始 SOM 只有 $1.4M，所以如果第一款产品跑通，尽早扩展到相邻住宿工作流很关键。

问题

• 酒店集团如今大量采用外包数字化入住和自助机入住流程，流程里会采集护照、驾照和自拍，这让到店自动化变成了长期留存高风险身份数据的机器。
• 安全、隐私和运营团队往往说不清这些原始文件到底存在哪、谁访问过，以及留存方式是否符合各地监管要求。

解决方案

• 提供一套住客身份金库：证件和自拍只核一次，把签名验真状态和必需的结构化字段回写到酒店系统，同时把原始材料放进明确的策略控制之下。
• 先做一层轻量控制层，接进现有 PMS、自助机和到店前入住栈；支持可配置的数据驻留、删除计时器、审计日志，以及在仍有例外要求的司法辖区或门店里提供人工兜底。

为什么我们会赢

• 这家公司对准的是酒店身份流程里真正让买方掏钱的痛点：把原始影像留存压下来，并拿出合规证据，而不是去卷通用开户注册转化。
• 酒店专用集成、按司法辖区沉淀的留存模板，以及跨供应商删除证据，做出的切口会比某个入住产品里再加一个安全存储功能更稳。

里程碑

flowchart LR
  Wedge[Hotel-group audit wedge] --> MVP[Identity vault MVP]
  MVP --> Proof[Deletion and attestation proof]
  Proof --> Expansion[Multi-property and channel expansion]

创始团队

实验路线图

风险评估

必须成立的条件

• 酒店集团愿意为独立控制层买单，而不是等现有入住供应商把留存控制补到“差不多够用”。
• 少量 PMS 和自助机集成就足以覆盖滩头市场，让前 6-12 个集团客户在不过度定制的情况下拿下。
• 基于策略的数据最小化与删除证据，足以降低买方风险，即便部分司法辖区依旧保留例外。
• 试点部署既能把原始身份文件留存大幅压缩，也能保住甚至提升入住完成率。
• 公司能在起步市场天花板压顶之前，尽快从酒店切口扩到更广的场景。

待尽调问题

• 痛点出现时，预算到底掌握在 CIO、运营、隐私团队手里，还是其实已经被流程里的入住供应商占住？
• 目标司法辖区里，哪些地方真的要求留存护照复印件或做生物识别处理？这些例外在滩头市场里出现频率有多高？
• 首批目标地区中，20-100 家门店酒店集团最常见的 PMS、自助机和到店前入住栈到底是哪几套？
• 酒店集团更愿意直接买独立身份金库，还是要求现有到店供应商补上同类能力？
• 首单里到底有多少是真正可持续的软件收入，又有多少只是一次性的安全整改预算？

模型合理性

• 收入引擎. 基准情景收入的核心，是把第 1 年的 2 个付费共创客户转成 Q4Y2 的 6 个生产环境酒店集团，再在 Q4Y3 前扩到 8 个集团、退出 ACV 约 $180K。
• 必须做对什么. 模型成立的前提，是由审计或续约驱动的试点能在大约 6 个月内转成年软件合同，不然实施工作会跑在经常性收入前面。
• 什么情况下会断. 最大的现金风险，是转生产环境变慢叠加例外处理变重，因为下行情景会让下一轮融资前的现金低点跌到零以下。
• 下一轮证明点. 只要公司能拿出 6 个生产环境酒店集团、标准化适配器，以及在约 120 家服务门店里扩张而毛利不塌，下一轮融资故事就会最有说服力。

情景

敏感性

flowchart LR
  Triggers["Audit or renewal triggers"] --> Pilots["Paid pilots"]
  Pilots --> Production["Production hotel groups"]
  Production --> Properties["More properties and modules"]
  Properties --> Revenue["Platform + verified-stay revenue"]
  Revenue --> GrossProfit["Gross profit"]
  GrossProfit --> Cash["Cash / runway"]

警示项: 模型假设每个拿下的酒店集团都会从 5-10 家门店试点扩到 Y3 的约 12-15 家生产环境门店；这是必须的，因为初始切口第 3 年市场只有约 $1.4M。 · 只有按退出 ARR 口径看，人均收入才勉强碰到 SaaS 基准；如果招聘提前，或集成工作过于定制，公司就会显得更像服务生意。 · 基准情景到 Y3 结束仍是 EBITDA 为负，因此除非转生产环境更快，或高级模块把 ARPU 拉得比模型更高，公司大概率还需要下一轮融资。

• 酒店集成拖慢推进. 酒店集团改入住流程通常很慢，因为 PMS、自助机和供应商集成都很脆，而且常常要一店一店地磨。 缓解措施: 先做一层轻量身份层，插进现有入住供应商和 PMS 系统里，不强推整条流程重做。
• 留存规则太复杂. 有些门店或司法辖区仍可能要求保留特定住客记录，单靠“全部删除”的简单叙事打不穿现实。 缓解措施: 做出把必填字段和原始影像拆开的策略模板，并支持按司法辖区和门店类型灵活配置留存。
• 现有厂商渠道挤压. 一旦酒店买方开始追问，现有数字化入住供应商可能会很快补上基础加密或删除功能。 缓解措施: 用零拷贝证明、独立审计日志和跨供应商策略治理拉开差距，让酒店即便更换前端入住工具也能继续用这层能力。