TapTalk | 圆桌实录：澳门综合度假村敏捷转型之旅，MongoDB + TapData 赋能酒店业卓越实践

在刚结束的 2025 MongoDB 用户大会·香港站上，TapData 联合创始人兼 CEO 唐建法（TJ）受邀与 MongoDB 港澳企业客户经理 Keith Fok 在圆桌讨论环节，和来自澳门综合度假村的两位在酒店服务行业数字化方面深耕十余年的客户代表同台，围绕综合度假村的全旅程数字化、客户数据平台（CDP）与实时数据服务展开对谈。

讨论聚焦于：在遗留系统复杂、业态多元（酒店/餐饮/零售/娱乐/博彩）的环境下，如何以 CDC 数据管道 + MongoDB 构建统一实时数据层，借助敏捷与微服务化推动跨部门协同，提升运营效率与宾客体验，并通过“小步快跑”的 Quick Win 快速验证价值。本文为现场对话实录，在不改变原意的前提下做了必要的口语化整理，便于快速阅读。

参与嘉宾

• Davide Lau | 客户代表 | 市场与非博彩解决方案助理总监
• Jacky Wu｜客户代表｜企业方案设计高级经理
• Keith Fok｜MongoDB｜企业客户经理（港澳）
• TJ Tang｜TapData｜联合创始人 & CEO

问：在澳门综合度假村这种“多业态、强运营”的场景里——住宿、博彩、餐饮、零售、演艺并行——你们如何给数字化转型排定优先级？

基于我们在多家综合度假村的落地经验，优先级最后沉淀为六个关键构件：

1. 战略与创新：先把优先级锚定在三件事——以客户为中心、提升运营效率、驱动营收增长，基于“以交付推动增长”原则，把战略落到可执行的路标上。

2. 客户旅程：客户旅程在抵达物业之前就已开始；围绕酒店、会展（C&E）与（澳门场景下的）博彩等多业态触点，深度分析客户的印象、期望与反馈，把每个触点的价值与体验目标画清楚。

3. 流程自动化：把全旅程流程预先打通、优化，做到“客户未开口，服务已就绪”，例如到店即能基于画像与意图推送亲子/纪念日餐厅与活动等建议。

4. 组织现代化：不只是技术升级，而是“人+流程+机制”的重构；采用新的协作与工作模型，打通市场、公关、酒店、零售、安全等多部门，形成更强的跨部门协同效能。

以去年的一场大型对外活动为例。为保证整体体验与安全，我们把市场、公关、酒店、零售、安全（含停车与交通）等团队拉到一张桌上，开跨部门协调会，把从宣传、预订到到场、动线、餐饮与离场的每个触点逐一打通，梳理与责任落实，明确对外与对内的响应机制与单一窗口——完成‘人—流程—技术’的一体化协同，把协同做实，数字化转型才落得下去。

5. 技术底座：让技术成为“粘合剂”，以更短的面市周期（Faster Time to Market）、可定制方案（Bespoke Solution）、高可用保障（Uptime Guarantee）与快速故障响应（Rapid Response），稳态支撑前台体验与后台运营。

6. 数据分析（含 AI）：在所有触点持续采集与汇聚数据，利用 AI 分析客户与业务环境变化，把洞察反哺到体验优化、效率提升与营收增长中。

一句话总结路径：定战略 → 绘旅程 → 服务自动化 → 组织现代化 → 以技术落地 → 用数据与 AI 持续迭代，形成可复制的综合度假村数字化方法论。

问：框架非常完整！但实话说，这些蓝图看起来都很美，落地却从不容易，尤其是在既有系统和组织结构复杂的情况下。能谈谈你们在 IT 转型中遇到的挑战吗？

的确不轻松。我们长期处在创新与稳定的拉扯中：业务团队希望更快推出功能与体验；运维团队因为博彩业务每日处理百万级交易，必须守住 99.9% 可用性；而开发者则需要更灵活、现代的工具链——运维团队要稳定，开发与业务团队想要新功能、新能力，这里天然就有矛盾。 为此，我们把 IT 策略聚焦为三大支柱：项目管理、技术现代化、开发者提效。

首先，是项目方法上的敏捷转型。过去的瀑布式方法让交付周期动辄 6–12 个月，风险大、创新被明显压制，风险大，常常不能满足业务的即时诉求。我们把“年度大项目”改为两周一个 Sprint，与业务建立快速反馈闭环，用小步快跑持续交付——这让对客服务的面市周期显著缩短，整体 TTM 约降低 70%，业务诉求能够被更及时地响应。

再者，采用微服务架构，推动组织与文化的变革。我们将单体系统拆解为小而独立的服务，在解耦的基础上实现局部更新、按域演进，避免大规模变更带来的系统抖动；同时打破团队“墙”，让跨团队分布式协作成为常态。结果是系统级故障率下降约 85%，稳定性与迭代速度实现了更好的平衡。

同时，尝试 AI 辅助研发。我们在编码、测试与部署环节为开发者引入 AI 助手，用于代码生成、单元测试覆盖、变更影响分析与流水线自动化，开发者生产力提升约 40%；目前已在一个部门试点并逐步推广，工程效能的提升是可复用、可规模化的。

总的来说，我们用敏捷解决“交付节奏”，用微服务解决“架构解耦与稳定性”，用 AI 工具链解决“人效与质量”——三者合力，让创新速度与运行稳定真正同频。

问：可以看出 IT 流程与技术交付方式发生了明显变化，但最终还是要落在对业务的影响。能具体谈谈你们是如何把这些转型举措投射到客户旅程里的吗？

简单来说就是客户旅程的“全链路一体化”。回到我们之前的“六个关键构件”，这次转型最直观的改变体现在客户旅程上——从到店前到离店后，都变得连续、可感知、可响应。

到店前：客户先在官网、OTA 与短信等渠道收到触达信息，感兴趣后通过自有预订平台或合作渠道完成下单；此时画像与偏好就已进入统一数据底座。

在店中：客户抵达即由忠诚度/会员团队接待，住宿、餐饮、零售、娱乐与（澳门场景下的）博彩等触点串为一个连续体验。我们有多类型酒店、众多高端餐饮与140+ 精品零售入驻；系统会在关键事件上实时触发服务：

• 博彩区获胜的宾客，会收到实时定制的餐饮或演出权益；
• 入住宾客在零售或娱乐点位，会员身份与偏好立即被识别，礼遇与推荐即时生效；
• 从办理入住、娱乐、用餐、SPA 到购物，每个触点都像同一系统的不同“界面”。

离店后：客户通过轮渡或列车返程；我们以电话/邮件做回访与关怀，对高价值客群在合适时机再次触达专属礼遇，为下一次到访做好铺垫。

支撑这一切的是客户数据平台（CDP）+ 实时数据与事件能力：多触点数据被标准化、统一到一个实时底座（以 TapData CDC 接入、多源整合，落到 MongoDB 增量/明细视图与变更流），在不打扰的前提下完成即时识别、个性化与自动化编排——“客户未开口，服务已就绪”。

结果是：这不再是一堆分散的服务，而是一个单一、智能的度假村生态系统，把体验、效率与营收目标真正串在了一起。

问：这的确是巨大的转变。我们注意到，这套图也和其他行业的客户旅程很类似，像是银行、保险、航空、零售……大家都想建客户数据平台，就像你们所展示的这样，一旦数据打通，很多“理想状态”就能实现。但现实中，业务总想知道：为什么现在才做？阻碍在哪里？要实现如此顺滑的一体化体验，之前被哪些技术瓶颈限制住了？

过去我们一直被三类限制拽着走：其一是实时性——宾客期望“即刻响应”，而传统批处理满足不了；其二是数据源异构与烟囱化——我们整体管理着上百个业务与支撑系统，餐饮板块（F&B）、酒店物业管理（PMS）、POS、零售、娱乐、博彩等彼此割裂，底层数据库也高度异构：Oracle、PostgreSQL、SQL Server 等并存，还夹杂一部分文件/Excel 源；其三是规模与弹性——每日百万级事件要求系统能随峰值弹性伸缩且保持稳定。

在这些限制之上，我们把“非做不可”的技术要求明确为：（1）无延迟处理实时数据流，（2）把各触点汇成统一的宾客视图，（3）可按峰值弹性扩缩，（4）能在实时链路中执行复杂业务规则，（5）关键业务可用性≥99.9%。这实际上逼着我们做一次架构级重设计。

落地路径上，我们按老规矩先做 POC：选择开放标准、低厂商绑定、可弹性伸缩的组合，最终用 TapData 作为流式/CDC 数据管道，以 MongoDB 作为实时运营数据存储。在 POC 与后续上线过程中，也特别感谢 TapData 与 MongoDB 团队的紧密支持。高层架构就是：多源系统（市场/会员、博彩、PMS、POS、零售、娱乐，以及文件源）→ TapData 持续采集与整合 → MongoDB 汇聚为明细/增量视图 → 通过 Change Streams 与统一服务层把数据实时送达自研营销应用、实时看板与营销决策系统等前台/中台场景，形成 Guest 360 的单一事实来源。

进一步说，MongoDB 与 TapData 在体系内的分工是清晰的：

• MongoDB 作为实时运营数据存储：充当所有宾客数据的中心枢纽；灵活 Schema 适配多系统数据；水平扩展吸收峰值；强查询能力支撑复杂业务逻辑；Change Streams 用于即时事件通知。
• TapData 作为集成/流式平台：对各源系统进行 CDC；亚秒级事件流延迟；内置转换对齐异构 Schema；保障数据准确性与质量。

端到端流程：源系统（Gaming、PMS、POS、Retail、Entertainment） → TapData 捕获与转换 →

MongoDB 统一宾客数据 → 应用侧交付个性化、分析与实时互动。

结果：宾客数据以秒级在各触点可用；形成单一事实来源（SSOT）；可用性达到 99.95%；并且能以极低摩擦集成新增数据源。

至于“为什么现在”——一方面，业务侧对实时体验的期望与峰值流量压力已到拐点；另一方面，微服务/云原生与MongoDB + TapData 这类技术栈的成熟度也到了可大规模落地的阶段。两者叠加，使我们有动因也有条件，把过去分散的系统重构为统一、弹性、可观测的实时底座。最终效果是：我们能在保证高可用（实测 99.95%）的同时，把实时能力稳定地服务到应用，让一线场景真正受益。

问：感谢分享这套完整的架构，可以想见，在这么多触点和宾客体验要统一的背景下，现代化是长跑，快速积累势能很关键。这套架构很强，但我们回到业务层面，能否分享一个快速获胜的案例，看看这套架构如何在短时间内实现较大的业务影响，为宾客带来突破性的体验？

从回访/关怀这个高频又关键的用例切入，出于尽可能早地收集客户反馈的需求，我们围绕 CDP + TapData 实时分发 + MongoDB 做了一个实时通知引擎：

• 聚合宾客的消费、偏好与行为历史；
• 根据综合度假村的运营特点应用业务规则；
• 在宾客未开口之前，主动送达合适的权益或建议。

两个直观场景：

• 回头客到店并完成入住时，专属接待（Host）会即时收到提醒，能够先于询问完成问候与安排（餐饮/活动）；
• 高价值客人在博彩区结束一轮游戏后，会立即收到基于他以往偏好的餐饮推荐，或与其兴趣贴合的零售优惠。
  整体观感是：服务“自己找上门”，宾客会实时地被识别与重视，而不是被动等待。

从工程侧看，这个项目也验证了速度与可靠性可以共存——“快且稳”是可以同时实现的：

• 团队规模：8 位工程师；
• 交付节奏：12 周完成首批能力的可用交付

以往做这类项目，大家可能会说“需要 8–12 个月吧”。但采用 MongoDB + TapData 的新方式后，我们用 8 位工程师、12 周，从构想到上线，就实现了第一批通知/关怀能力，为一线同事服务。

这次实践让团队和业务看到：得益于 TapData 的 CDC/流式集成与 MongoDB 的实时运营数据存储，我们能把事件触发、业务规则与多触点服务跑在同一实时底座上，既快速验证价值，又保证稳定性，真正把“快速获胜”变成可复制的方法。

小结

以上，是一个非常好的案例，清楚地展示了业务愿景、敏捷实践与合适技术栈叠加后的力量。本篇实录内容讲的是综合度假村如何把烟囱式系统与漫长周期，转到实时、敏捷、智能的待客之道。MongoDB 与 TapData 提供了坚实的底座，但真正的成功来自于清晰的愿景、跨团队的协作以及对变革的坚定承诺。

和 MongoDB 相比，TapData 当然更年轻——我们成立 6年，但从第一天起就只做一件事：实时数据平台。我们能够与各类关系型数据库协同工作，Oracle、MySQL、SQL Server等都在连接矩阵里；通过 CDC 与实时管道，低侵入/低改造地把这些系统接入统一的数据底座，帮助大家更快搭建 CDP/数据服务层并孵化新的在线场景与应用。也期待继续和各位伙伴一起，把现代化架构真正跑深、跑稳、跑出业务价值。——TJ