#集成战略与 OTF 客户策略

最后更新：2026-03-28

#一、战略背景

Retaintive 定位为 AI-native Sales & Retention CRM for Fitness，核心能力是 CI + CRM + BI 三合一。

当前数据来源只有 RingCentral（通话 + SMS），尚未打通健身房管理系统（Mindbody、ABC Fitness 等）。这意味着：

• AI 分析只有通话维度，缺少到访、支付、合同数据 — 分析画像不完整
• 客户需在 retaintive 和管理系统之间手动切换 — 工作流断裂
• 新客户 onboarding 依赖手动录入 — 获客摩擦大

集成的战略意义：不是"锦上添花"，而是决定 retaintive 能否从"通话分析工具"升级为"不可替代的运营系统"的关键。

但集成的可行性取决于客户类型。retaintive 面对两种截然不同的客户：

本文分别给出两条路线的完整策略。

#二、OTF 技术治理模型

本章基于 OTF 2026 FDD（特许经营披露文件）、隐私政策、Retool 案例研究、Qvinci 案例研究等公开信息整理。

#2.1 中心化技术管控

OTF 的 FDD 明确要求：

"Franchisees must obtain, maintain, and use the hardware, software, other equipment, and network connections that Orangetheory specifies periodically in the Manuals necessary to operate... the Technology System."

加盟商没有技术选择权。以下是 OTF 强制指定的完整技术栈：

加盟商每月支付 $899 技术费 + $149 OTbeat 费，启动时还要交 $575 安装费 + $4,495 软件许可费。所有产品和服务必须来自"指定或批准的供应商"。

#2.2 Mindbody 账号结构

OTF 总部 (Ultimate Fitness Group / Purpose Brands)
  │
  │  合同关系：Mindbody 是"与 Ultimate 和加盟商签约的服务提供商"
  │
  ├── 门店 SiteId: 312145 (Orange, CA)        ← 加盟商 A 运营
  ├── 门店 SiteId: 926209 (Forest Hills, NY)  ← 加盟商 B 运营
  ├── 门店 SiteId: -29573 (Canada Corporate)  ← 总部直营
  └── ... 1,600+ 门店

关键事实：

• 每个门店有独立的 SiteId，但 Mindbody 合同是与总部和加盟商共同签署的
• OTF 在 Mindbody 之上建了自有 API 抽象层 — 加盟商通过 OTF 提供的 Retool 应用操作数据，而不是直接访问 Mindbody
• 加盟商没有 Mindbody API 管理权限 — 无法自行激活第三方集成、创建 API 账号、授权第三方应用
• 存在非官方的第三方 Python 库（otf-api）逆向 OTF 的 API 层，但这是用会员账号认证，不是 Mindbody API

#2.3 数据所有权

隐私政策没有提到加盟商有独立导出数据的权利。数据实质上由总部控制。

#2.4 加盟商的技术自主权边界

#2.5 关键发现

RingCentral 是目前唯一不受 OTF 总部管控的集成通道。

OTF 的 FDD 明确列出了 Mindbody、OTconnect、Qvinci、Retool 等系统为强制指定，但电话系统不在清单中。这意味着加盟商可以自主选择电话服务商，也可以自主授权 retaintive 接入通话数据。

这就是为什么 retaintive 现在能服务 OTF 客户 — 走的是电话系统通道，完全不碰 Mindbody。

#三、OTF 客户策略（三阶段路线图）

#Phase 1：深耕 RingCentral 通道（Month 1-6）

目标：在不碰 Mindbody 的前提下，最大化通话数据的价值，让更多 OTF 加盟商依赖 retaintive。

核心逻辑：先用通话数据证明价值 → 积累成效数据 → 为 Phase 2 准备谈判筹码。

Phase 1 里程碑：

• 10+ OTF 门店活跃使用 retaintive
• 3+ 个可量化的 ROI 案例（如："使用 retaintive 后 Lead 转化率从 22% 提升到 31%"）
• 识别出 2-3 个愿意向总部推荐 retaintive 的大加盟商

#Phase 2：自下而上推动总部认可（Month 6-12）

目标：通过加盟商的集体诉求 + 成效数据，推动 OTF 总部将 retaintive 列为 Approved Supplier。

谈判要点：

retaintive 对 OTF 总部的价值：

总部的痛点                          retaintive 的解法
───────────────────────────────    ─────────────────────────────
加盟商通话质量参差不齐              → AI Coaching + 通话质量评分跨门店对比
不知道哪些门店 Lead 跟进有问题       → 全品牌 Lead Pipeline 可视化
Cancel Intent 发现太晚              → AI 实时检测 + 自动预警
总部无法监控通话合规                → 通话分析自动合规检查

Phase 2 里程碑：

• OTF 总部同意启动试点项目（或至少进入 vendor 审批流程）
• 签署数据处理协议（DPA）
• 获得有限的 Mindbody API 访问权限（试点范围）

#Phase 3：成为 OTF Approved Supplier（Month 12-18）

目标：正式成为 OTF 认可的技术供应商，1,600+ 门店同时打开。

Phase 3 的战略价值：

试点成功
  → OTF 总部批准
    → 1,600+ 门店瞬间变成潜在客户
      → 跨门店基准数据积累
        → 护城河形成（竞品无法获得同等数据规模）
          → Purpose Brands 跨品牌扩展（6M+ 会员）

#四、非 OTF 客户的集成策略

独立健身房、精品工作室、弱管控连锁品牌 — 老板自己有 Mindbody/PushPress 账号的管理权限，可以自主授权集成。

#4.1 单方面集成的本质

"单方面集成" = 利用第三方平台的公开 API 拉取客户数据，不需要平台方的审批或合作，但必须获得客户（健身房老板）的授权。

类比：Gong 单方面接入 Salesforce API — 不需要 Salesforce 的合作协议，但每个 Gong 客户都要在 Salesforce 授权页面点"允许"。

#4.2 平台可行性对比

#4.3 非 OTF 行动方案

#Phase 1：基础打通（Month 1-3）

#Phase 2：Mindbody 集成（Month 3-6）

#Phase 3：生态建设（Month 6-12）

#五、平台 API 实施细节

#5.1 认证流程

不同平台的认证机制差异很大：

#模式 A: OAuth 2.0（PushPress）— 与 RingCentral 相同

用户点 "连接 PushPress" → 跳转 PushPress 授权页 → 用户点"允许"
→ PushPress 回调 retaintive（带 auth_code）
→ retaintive 换取 access_token + refresh_token → 加密存储 → 开始同步

#模式 B: API Key + User Token（Mindbody）— 需要 staff 凭据

Step 1: retaintive 注册开发者，获取全局 API Key（一次性）
Step 2: 健身房老板在 Mindbody 后台"激活" retaintive
Step 3: 健身房提供 staff 账号的用户名 + 密码
Step 4: retaintive 调用 POST /public/v6/usertoken/issue 获取 User Token（1 小时有效）
Step 5: 每个 API 请求带三个 Header：Api-Key + SiteId + Authorization

⚠️ 安全注意：Mindbody 模式需要存储客户的 staff 凭据（用户名/密码），必须用 KMS 加密，并在隐私协议中明确说明。

#5.2 PushPress API 端点

认证：OAuth 2.0 | Rate Limit：600 req/min | Webhook：✅ 支持

Webhook 事件：member.created/updated、checkin.created、invoice.paid/failed、lead.created

同步策略：首次全量 → 之后 Webhook 实时 + 每 6 小时增量轮询兜底

#5.3 Mindbody Public API v6 端点

认证：API Key + User Token | Rate Limit：1K-50K req/day | Webhook：❌ 无（仅 Marketplace 伙伴）

同步策略：首次分批全量（≤60 req/min）→ 之后每 15 分钟增量轮询（无 Webhook 可用）

Onboarding 注意：每个健身房接入需 3 步手动操作 —

1. Mindbody 后台激活 retaintive
2. 提供 staff 账号凭据（建议创建专用 API Staff 账号）
3. 提供 SiteId

#5.4 ABC Fitness（❌ 不适合单方面集成）

没有公开 API。所有访问需通过 Technology Partner Program（申请 → 审核 2-6 周 → 签协议）。

Phase 1 替代方案：ABC 客户从后台导出 CSV → 上传到 retaintive CSV 导入工具 → 自动映射、去重、导入。

#六、数据映射规范

#核心映射：外部会员 → retaintive Contact

#会员状态映射

#七、同步引擎技术设计

#7.1 基础设施

studio-IntegrationConnections-{env}     ← DynamoDB 表（OAuth token / staff 凭据，KMS 加密）
studio-IntegrationSyncState-{env}       ← DynamoDB 表（同步状态、游标、错误日志）
integration-sync-queue-{env}            ← SQS 队列（同步任务）
integration-sync-dlq-{env}             ← 死信队列

#7.2 Lambda 函数

#7.3 增量同步流程

EventBridge (每 15 分钟)
  → sync-scheduler: 扫描 IntegrationConnections (status=active)
    → 发 SQS 消息: { connectionId, platform, lastSyncAt }

SQS → sync-worker:
  1. 解密 access_token 或 staff 凭据
  2. Token 过期? → 刷新（OAuth）或重新 issue（Mindbody User Token）
  3. 调用平台 API（带增量过滤）
  4. 遍历分页 → Data Mapper 转换 → Upsert Neon contacts 表
  5. 更新 IntegrationSyncState { lastSyncAt, recordsSynced }
  6. 失败 → 重试 3 次 → DLQ → Discord/Lark 告警

#7.4 Adapter Pattern 代码结构

studio-website-monorepo/apps/api/src/integrations/
├── adapters/
│   ├── base-adapter.ts          // 统一接口
│   ├── mindbody-adapter.ts      // Mindbody 实现
│   └── pushpress-adapter.ts     // PushPress 实现
├── mappers/
│   ├── contact-mapper.ts        // 外部会员 → retaintive contact
│   ├── visit-mapper.ts          // 到访记录
│   └── payment-mapper.ts        // 支付记录
├── services/
│   ├── sync-service.ts          // 同步编排
│   ├── token-service.ts         // Token 管理（复用 RC 加密逻辑）
│   └── connection-service.ts    // 连接 CRUD
├── routes/
│   └── integration-routes.ts    // Hono 路由
└── types/
    └── integration-types.ts

#7.5 API 路由

// ── PushPress（OAuth 2.0）──
GET  /integrations/pushpress/authorize    // 发起 OAuth
GET  /integrations/pushpress/callback     // 回调

// ── Mindbody（User Token）──
POST /integrations/mindbody/connect       // 提交 staff 凭据 → 验证 → 存储

// ── CSV 导入（ABC Fitness 等无 API 平台）──
POST /integrations/csv/upload             // 上传 CSV
POST /integrations/csv/preview            // 预览字段映射
POST /integrations/csv/import             // 确认导入

// ── 通用 ──
GET    /integrations/connections           // 列出所有连接
DELETE /integrations/connections/:id       // 断开
POST   /integrations/connections/:id/sync  // 手动同步
GET    /integrations/connections/:id/status // 同步状态

// ── Webhook ──
POST /integrations/webhooks/pushpress     // PushPress 实时推送

#7.6 实施时间线

Week 1-2:   基础框架 — DynamoDB 表 (CDK) + base-adapter + token-service + 路由骨架
Week 3-4:   PushPress 集成 — OAuth + 全量/增量同步 + Webhook + 前端 UI
Week 5-6:   PushPress 测试上线 — 真实客户测试 + 监控告警
Week 7-10:  Mindbody 集成 — User Token 认证 + 轮询同步 + Rate Limit 处理
Week 11-12: 端到端验证 — 压测 + 断点续传 + Token 刷新 + 客户文档

#八、集成后的 AI 分析增强

打通管理系统数据后，retaintive 的 AI 引擎获得完整画像：

自动化工作流触发：

• 合同 30 天内到期 + 到访下降 → 自动创建 retention task
• 付款失败 → 自动标记高优先级 + 推荐话术
• 新会员 7 天未到访 → 自动触发欢迎通话 task

#九、风险与应对

#十、成功指标

#OTF 客户线

#非 OTF 客户线

#十一、结论

Retaintive 面对两个截然不同的战场：

OTF（强管控连锁）— 不能绕过总部。策略是：用 RingCentral 通话数据先证明价值 → 积累加盟商口碑和 ROI 数据 → 自下而上推动总部认可 → 一旦成为 Approved Supplier，1,600+ 门店同时打开。这是一条慢但爆发力极强的路。

非 OTF（独立/弱管控）— 可以单方面集成。策略是：PushPress 先行（最简单）→ Mindbody 跟进（最重要）→ Marketplace 上架 → 生态建设。这条路见效快、稳步增长。

两条路并行，互相增强：

非 OTF 集成经验（技术能力积累）
  → 用于 OTF 试点项目（证明集成质量）
    → OTF 批准后的规模化推广（复用同一套 Adapter）

OTF 品牌背书（最大连锁认可）
  → 降低其他连锁的销售阻力（"OTF 都在用"）
    → 加速非 OTF 客户获取

18 个月目标：OTF 线拿到 Approved Supplier 身份，非 OTF 线覆盖 3+ 管理系统平台。两条线汇合时，retaintive 就是健身行业的 CI 标准层。