> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# 集成战略与 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 加盟商         | 独立/弱管控连锁健身房 |
| --------------- | --------------- | ----------- |
| **技术自主权**       | 几乎为零，总部强制指定所有技术 | 完全自主        |
| **Mindbody 集成** | 必须总部批准          | 老板自己授权即可    |
| **集成策略**        | 走总部路线           | 走单方面集成      |

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

***

## 二、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 强制指定的完整技术栈：

| 系统                     | 用途                | 费用              |
| ---------------------- | ----------------- | --------------- |
| **Mindbody**           | 会员管理、预约、POS、账单    | 包含在 $899/月技术费   |
| **OTconnect / OTbeat** | 心率监控、课程显示、可穿戴设备   | $149/月          |
| **Qvinci**             | 财务报告、BI           | 包含在技术费          |
| **Retool 应用**          | Lead 管理、会员管理、门店组合 | 总部提供            |
| **3 台 Dell 台式机**       | 前台运营              | \~$41K-$56K 一次性 |
| **3-6 台电视 + Apple TV** | 课程显示              | 硬件费             |
| **课程设备平板**             | 跑步机/划船机上的平板       | 硬件费             |

加盟商每月支付 **$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 数据所有权

| 数据类型            | 谁能访问           | 加盟商能导出吗？        |
| --------------- | -------------- | --------------- |
| 会员基本信息          | 总部 + 本店加盟商     | 通过 OTF 工具，非自主导出 |
| 到访/预约记录         | 总部 + 本店加盟商     | 同上              |
| 跨店到访（会员在其他门店上课） | 总部 + 两个门店      | 同上              |
| OTbeat 心率数据     | **仅总部**        | 加盟商之间不共享        |
| 财务数据            | 总部通过 Qvinci 聚合 | 加盟商看自己的门店       |

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

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

| 想做的事                 | 能做吗？                 |
| -------------------- | -------------------- |
| 在 Mindbody 后台激活第三方集成 | ❌ 没有权限               |
| 用 Zapier 连接 Mindbody | ❌ 需要 API 权限          |
| 导出会员 CSV             | ⚠️ 可能可以（取决于操作权限等级）   |
| 用自己的 CRM 替代 OTF 指定的  | ❌ 违反加盟协议             |
| 接入 RingCentral 通话分析  | ✅ 电话系统不在 OTF 强制指定范围内 |

### 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 准备谈判筹码。

| 动作               | 说明                                             |
| ---------------- | ---------------------------------------------- |
| **最大化 CI 价值**    | 通话质量评分、Cancel Intent 检测、AI Coaching — 纯通话数据就能做 |
| **CSV 导入覆盖会员数据** | 如果加盟商能从 Mindbody 导出 CSV，retaintive 手动导入补全画像    |
| **积累 ROI 数据包**   | 每个客户的：Lead 转化率提升、通话质量改善、响应时间缩短 — 用数字说话         |
| **扩大 OTF 客户基数**  | 口碑传播 + 加盟商社群推荐，目标：10+ 家 OTF 门店使用 retaintive    |
| **建立加盟商关系网**     | 找到有影响力的多店加盟商（拥有 5-20 家店的大加盟商）                  |

**Phase 1 里程碑**：

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

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

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

| 动作                          | 说明                                                             |
| --------------------------- | -------------------------------------------------------------- |
| **组织加盟商联合提案**               | 多个使用 retaintive 的加盟商联合向总部提交 vendor 审批请求                        |
| **准备企业级销售资料**               | ROI 数据包、安全合规文档、数据处理协议（DPA）、SOC 2 / ISO 27001 进展                |
| **直接接触 OTF 总部**             | 联系 OTF 技术团队或 Purpose Brands 平台团队，提出集成合作                        |
| **利用 Purpose Brands 平台化趋势** | Purpose Brands（OTF 母公司，含 Anytime Fitness）正在建设跨品牌统一平台 — 这是进入的窗口 |
| **提供飞行测试**                  | 请求总部批准 3-5 家门店的试点项目，限定范围、限定时间、可控风险                             |

**谈判要点**：

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+ 门店同时打开。

| 动作                       | 说明                                            |
| ------------------------ | --------------------------------------------- |
| **试点项目验证**               | 3-5 家门店的完整集成（RingCentral + Mindbody），量化效果     |
| **打通 Mindbody 数据**       | 通话 + 到访 + 支付 + 合同 — 完整画像，AI 分析质量跃升            |
| **总部级 Dashboard**        | 为 OTF 总部提供跨品牌分析视图（所有门店的通话质量、Lead 转化、Churn 风险） |
| **规模化推广**                | 总部统一采购 or 加盟商自主选购（作为 Approved Supplier）       |
| **进入 Purpose Brands 平台** | 服务 OTF + Anytime Fitness + 其他品牌               |

**Phase 3 的战略价值**：

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

***

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

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

### 4.1 单方面集成的本质

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

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

### 4.2 平台可行性对比

| 平台                | 单方面可行？ | 认证方式               | Webhook                 | Rate Limit     | 主要门槛                |
| ----------------- | ------ | ------------------ | ----------------------- | -------------- | ------------------- |
| **PushPress**     | ✅ 完全可行 | OAuth 2.0          | ✅ 支持                    | 600 req/min    | 几乎没有                |
| **Mindbody**      | ⚠️ 有条件 | API Key + Staff 凭据 | ❌ 不支持（仅 Marketplace 伙伴） | 1K-50K req/day | 需 staff 账号密码 + 站点激活 |
| **ABC Fitness**   | ❌ 不可行  | 需合作协议              | 需合作                     | 按合同            | 没有公开 API            |
| **Zapier / Make** | ✅ 通用   | OAuth 2.0          | ✅ 触发器                   | 按 Zapier 套餐    | 需发布 Zapier App      |

### 4.3 非 OTF 行动方案

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

| 任务               | 优先级 | 工期    | 说明                               |
| ---------------- | --- | ----- | -------------------------------- |
| CSV 批量导入工具       | P0  | 1 周   | 最低成本方案，所有客户立即可用                  |
| PushPress API 集成 | P0  | 4 周   | 最容易的 API 集成（OAuth 2.0 + Webhook） |
| 数据映射规范           | P0  | 3 天   | 外部系统字段 → retaintive 字段的标准映射      |
| Zapier App       | P1  | 2-3 周 | 发布 retaintive Zapier App，覆盖长尾平台  |

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

| 任务                     | 优先级 | 工期  | 说明                                                  |
| ---------------------- | --- | --- | --------------------------------------------------- |
| Mindbody Public API 集成 | P0  | 6 周 | API Key + User Token 双重认证 + 轮询同步                    |
| 通话摘要回写                 | P1  | 1 周 | `addcontactlog` 端点 — 把 retaintive 分析写回 Mindbody CRM |
| 同步监控仪表盘                | P2  | 1 周 | 客户可查看同步状态、错误日志                                      |

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

| 任务                      | 优先级 | 工期      | 说明                                     |
| ----------------------- | --- | ------- | -------------------------------------- |
| Mindbody Marketplace 上架 | P0  | 4-8 周审核 | 获得 Webhook 权限 + 更高 Rate Limit + 官方获客渠道 |
| Retaintive 开放 API       | P1  | 3-4 周   | 允许第三方调用 retaintive 的 AI 分析结果           |
| Webhook 事件系统            | P1  | 2 周     | 客户可订阅事件（新 Lead、Cancel Intent 等）        |
| ABC Fitness 合作申请        | P2  | 申请期     | 启动 Technology Partner Program 流程       |

***

## 五、平台 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**：✅ 支持

| 数据类型    | 端点                     | 说明            |
| ------- | ---------------------- | ------------- |
| 会员列表    | `GET /v1/members`      | 分页、状态过滤       |
| 会员详情    | `GET /v1/members/{id}` | 姓名、电话、邮箱、入会日期 |
| 签到记录    | `GET /v1/checkins`     | 日期范围过滤        |
| 计划/合同   | `GET /v1/plans`        | 订阅计划、价格、状态    |
| Lead 列表 | `GET /v1/leads`        | 潜在客户、来源       |
| 付款历史    | `GET /v1/invoices`     | 付款状态、金额       |
| Webhook | `POST /v1/webhooks`    | 注册实时推送        |

**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 伙伴）

| 数据类型       | 端点                              | 说明                         |
| ---------- | ------------------------------- | -------------------------- |
| 获取 Token   | `POST /usertoken/issue`         | Staff 凭据换 access token     |
| 客户列表       | `GET /client/clients`           | 分页 Limit/Offset，最多 200 条/页 |
| 客户到访       | `GET /client/clientvisits`      | ClientId + 日期范围            |
| 客户购买       | `GET /client/clientpurchases`   | 购买历史                       |
| 客户服务       | `GET /client/clientservices`    | 已购会员卡/服务                   |
| CRM 日志     | `GET /client/contactlogs`       | CRM 联系记录                   |
| **回写 CRM** | `POST /client/addcontactlog`    | retaintive 通话摘要 → Mindbody |
| 预约         | `GET /appointment/appointments` | 预约状态、时间、员工                 |
| 课程出勤       | `GET /class/classvisits`        | 课程签到                       |
| 销售交易       | `GET /sale/sales`               | 按日期范围过滤                    |
| 合同信息       | `GET /sale/contracts`           | 类型、状态、到期日                  |
| 员工         | `GET /staff/staff`              | 关联到 retaintive staff       |

**同步策略**：首次分批全量（≤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

| retaintive 字段       | Mindbody              | PushPress           | 说明       |
| ------------------- | --------------------- | ------------------- | -------- |
| `external_id`       | `Client.UniqueId`     | `member.id`         | 外部唯一 ID  |
| `external_source`   | `"mindbody"`          | `"pushpress"`       | 来源标识     |
| `first_name`        | `Client.FirstName`    | `member.first_name` | 名        |
| `last_name`         | `Client.LastName`     | `member.last_name`  | 姓        |
| `phone`             | `Client.MobilePhone`  | `member.phone`      | E.164 格式 |
| `email`             | `Client.Email`        | `member.email`      | 邮箱       |
| `membership_status` | `Client.Status` → 映射  | `member.status`     | 见下表      |
| `join_date`         | `Client.CreationDate` | `member.created_at` | 入会日期     |
| `contract_end_date` | `Contract.EndDate`    | `plan.end_date`     | 合同到期     |
| `last_visit_date`   | `Visit.LastVisitDate` | 从 checkins 计算       | 最近到访     |
| `visit_count_30d`   | 从 visits 聚合           | 从 checkins 聚合       | 近 30 天到访 |
| `payment_status`    | `Sale.PaymentStatus`  | `invoice.status`    | 付款状态     |

### 会员状态映射

| retaintive  | Mindbody                 | PushPress   |
| ----------- | ------------------------ | ----------- |
| `active`    | `Active`                 | `active`    |
| `frozen`    | `Suspended`              | `frozen`    |
| `cancelled` | `Terminated`, `Expired`  | `cancelled` |
| `prospect`  | `Non-Member`, `Prospect` | `lead`      |
| `past_due`  | `Active` + 欠费标记          | `past_due`  |

***

## 七、同步引擎技术设计

### 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 函数

| Lambda                         | 触发方式                 | 职责                              |
| ------------------------------ | -------------------- | ------------------------------- |
| `integration-auth-handler`     | API Gateway (Hono)   | OAuth 回调、Mindbody 凭据验证、token 刷新 |
| `integration-sync-scheduler`   | EventBridge（每 15 分钟） | 扫描活跃连接，发送同步任务到 SQS              |
| `integration-sync-worker`      | SQS                  | 执行 API 调用、数据映射、写入 DB            |
| `integration-webhook-receiver` | API Gateway          | 接收 PushPress webhook 推送         |

### 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 路由

```typescript
// ── 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 引擎获得**完整画像**：

| 维度                  | 现状（仅通话）    | 集成后（通话 + 管理系统）                       |
| ------------------- | ---------- | ------------------------------------ |
| 客户认知                | "打了 3 次电话" | "打了 3 次电话 + 上周没来签到 + 合同下月到期 + 有欠费"   |
| Cancel 检测           | 基于通话关键词    | 通话意图 + 行为模式（到访从 12 次/月降到 2 次）        |
| Churn 预测            | \~60% 准确率  | \~85% 准确率（通话情绪 + 到访频率 + 合同临期 + 付款异常） |
| Revenue Attribution | 无法做        | 通话 → 预约 → 到访 → 付费 完整归因链              |

**自动化工作流触发**：

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

***

## 九、风险与应对

| 风险                       | 概率 | 影响 | 应对                                     |
| ------------------------ | -- | -- | -------------------------------------- |
| OTF 总部拒绝合作               | 中  | 高  | 继续深耕 RingCentral 通道；拓展非 OTF 客户群降低依赖    |
| Mindbody 收紧 API          | 中  | 高  | 多平台支持 + 尽早申请 Marketplace 获得官方身份        |
| OTF 加盟商不愿推动总部            | 中  | 中  | 提供更强的 ROI 数据；找到多店大加盟商作为 champion       |
| 集成维护成本高                  | 高  | 中  | Adapter Pattern 标准化框架，新平台接入成本递减        |
| Mindbody 自建 CI/AI        | 中  | 高  | 深度嵌入客户工作流（先入优势）；差异化在通话分析（Mindbody 没有）  |
| Purpose Brands 统一平台排斥第三方 | 低  | 极高 | 提前接触 Purpose Brands 技术团队；定位为"补充"而非"替代" |

***

## 十、成功指标

### OTF 客户线

| 阶段                 | 指标                   | 目标                   |
| ------------------ | -------------------- | -------------------- |
| Phase 1 (Month 6)  | OTF 门店活跃使用数          | ≥ 10 家               |
| Phase 1 (Month 6)  | 可量化 ROI 案例数          | ≥ 3 个                |
| Phase 2 (Month 12) | 进入 OTF vendor 审批流程   | 是/否                  |
| Phase 2 (Month 12) | 试点门店数                | ≥ 3 家（含 Mindbody 集成） |
| Phase 3 (Month 18) | 成为 Approved Supplier | 是/否                  |
| Phase 3 (Month 18) | OTF 门店覆盖率            | ≥ 50 家               |

### 非 OTF 客户线

| 阶段                 | 指标               | 目标        |
| ------------------ | ---------------- | --------- |
| Phase 1 (Month 3)  | 使用集成/CSV 导入比例    | > 50% 新客户 |
| Phase 2 (Month 6)  | PushPress 连接客户数  | ≥ 20 家    |
| Phase 2 (Month 6)  | Mindbody 连接客户数   | ≥ 15 家    |
| Phase 3 (Month 12) | Marketplace 获客占比 | > 15%     |
| Phase 3 (Month 12) | 集成平台覆盖数          | ≥ 3 个平台   |

***

## 十一、结论

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 标准层。