#五、潜在合作方竞品分析

公开资料补查：2026 年 9 月 16 日。 本轮补查产品页、更新记录、开发文档、培训入口、价格页及用户评价，未登录竞品后台、申请 Demo 或进行实际操作测试。Retaintive 的对比仍依据产品说明，不是本轮重新验收的生产状态。

证据读法： “官方明确说明”包括产品页、文档与更新记录；“厂商案例”是厂商发布的客户经验与结果；“用户反馈”是第三方评价，不代表普遍表现；“待确认”表示公开证据不足。页面截图只能证明展示过该界面，本轮没有把截图或视频入口当作实测。

#1. 竞争关系

#2. Mindbody AI Concierge：已经连接业务数据的 AI 前台

(1) 功能清单

来源：AI Concierge 官方功能与 FAQ。这是 AI Concierge 的范围，不是 Mindbody 全部 CRM、支付与门店管理功能的清单。

(2) 与我们的重叠及对方优势

重叠在客户沟通、线索跟进和预约推进。它的明确优势是已经处于 Mindbody 的业务系统中，能读取预约所需的数据并完成操作。仅凭“能理解客户、帮助预约”，不足以说明我们值得被单独采购。

(3) 我们可以怎么谈

展示 Retaintive 如何帮助员工处理沟通中发现的后续事项，以及经理如何检查执行、复盘沟通和管理多店。再与对方确认，这些工作在现有产品中覆盖到什么程度，是否值得补充。

对 Mindbody 的合作主张仍是：我们在没有完整客户生命周期数据的情况下，已经围绕沟通信息形成了产品；如果获得授权接入更完整的 CRM 数据，可以共同开发更多业务场景。 这是合作开发的方向，不能直接当作我们已经优于其原生产品的证据。

#2.1 补查资料：套餐、使用方式与资料缺口

仍需了解： 多店共用收件箱与权限、员工接手后的责任分配、错误预约如何撤销、客户拒绝联系后的处理、自动回复与提醒额度，以及不同门店可否独立配置。现有公开材料不足以把这些写成已支持或不支持。

#3. RingCentral ACE / AIR Pro：从理解电话到执行业务

(1) 功能清单

ACE：沟通分析与员工辅导

来源：官方产品页、ACE API 文档、2026 更新记录、团队辅导更新。

AIR Pro：AI 接待与业务执行

来源：AIR Pro 官方发布公告。这是公告明确描述的能力；当前官网仍标为 Early Access，开放状态和依赖条件见 3.2。

(2) 与我们的重叠及对方优势

ACE 与沟通分析、行动建议和 Coaching 重叠；AIR Pro 与客户联系和业务自动化方向重叠。RingCentral 本身掌握通讯入口，可以把分析和执行直接结合在产品中。我们的合作价值需要超出再做一遍通话摘要。

(3) 我们可以怎么谈

用具体门店问题展示行业应用：客户提出取消、升级或付款问题后，如何结合后续沟通判断还需要做什么，如何安排员工处理，以及经理如何检查进展。需要比较的是整件事能否持续处理，而不只是单次电话分析得怎么样。

对 RingCentral 的合作机会是：把通讯与 AI 能力进一步用于客户的销售、服务和经营管理。 是否有价值，要看我们的行业规则、产品流程和实际使用经验，能否减少其进入这些业务的开发与验证工作，并符合其当前战略方向。

#3.1 ACE 补查：已不只是摘要和建议

接入条件已比较清楚。 开发文档要求购买 ACE 许可并分配到用户分机，读取分析还需要相应权限；可以通过通知或 API 获取结果。事件依赖有效许可与已录制的通话／会议。我们已有 RingCentral 电话连接，不代表自动拥有 ACE 功能或数据访问权。ACE 开发文档

价格与学习入口： 本轮没有核到可直接用于目标客户预算的 ACE 统一公开报价。可继续查官方产品页和RingCentral University；课程目录混合 AIR、RingCX 等产品，不能把所有课程功能都算到 ACE。

仍需了解： 跨多次通话的客户事项如何合并、是否有负责人和长期未解决事项队列、员工如何纠正分析、哪些能力按套餐分别收费。不能仅凭 NextSteps 字段就判断其有或没有与我们相同的持续 Task。

#3.2 AIR Pro 补查：功能范围与开放状态要分开

官方明确说明： 当前产品页仍提供 Early Access 申请，注明需要人工审核，申请不保证获准。应把它视为已公开并开放申请的产品，不能认定所有客户都可直接购买并启用完整能力。当前产品页

该页进一步说明支持呼入与呼出、接入知识来源、配置技能和业务流程、设置转人工边界，以及监控处理效果；部分功能依赖另购第三方业务系统。这些是官方功能说明，不是本轮验证过的可用集成或效果。 本轮未取得 AIR Pro 报价、测试账号或完整连接器清单。功能与申请条件

不要混用产品资料： AIR（AI Receptionist）与 AIR Pro（AI Representative）在官网上分列。前者的价格、试用、集成教程，不能自动套用到后者。公开页面有视频入口，本轮只核对页面文字与申请条件，没有完成视频操作流程复核。

仍需了解： 目标行业是否获准接入、计费单位、呼出限制、转人工时上下文如何传递、操作失败的处理方式，以及健身 CRM 的具体读写能力。

#4. Keepme Antares：应重点比较的行业同类产品

(1) 功能清单

来源：Antares 官方 FAQ。各模块的购买方式、具体集成和部署成熟度需通过演示确认；上表不代表一个套餐默认包含全部功能。

(2) 为什么值得重点研究

它与我们面向的行业和业务问题都接近，而且公开能力已经涉及跨沟通理解、后续行动和会员留存。不能用“对方只是聊天机器人，我们才理解业务”来区分，也不能仅凭有 Task 或客户上下文就声称独有。

(3) 具体比较什么

• 员工怎么参与： AI 发现问题后，员工如何接手、补充情况、纠正判断和持续处理？
• 经理怎么管理： 能否看清未处理事项、员工执行和多店差异，而不仅是 AI 回复量？
• 接入需要什么： 依赖哪些 CRM 数据和授权，现有门店是否具备条件？
• 使用是否划算： 配置、培训、费用与维护投入多少，门店是否愿意持续使用？

这些是下一步演示和试用要核对的问题，暂时不能写成对方的缺点。

#4.1 补查资料：集成、人工接手与上线过程

#4.2 价格与用户证据

• 第三方价格线索，未获官方报价确认： Capterra 列出起价 US$2,000／月、按用量。未说明适用门店数、Agent 范围、渠道额度、实施费及合同期限，不能直接用作每店价格或与我们的报价作比例比较。Capterra 产品页
• 用户反馈，证据有限： 评价页搜索摘要可见一位区域经理在 2025 年 8 月称，产品减轻了团队处理线索的压力。但全文页面本轮未成功打开，也不能将较早评价推到 2026 年所有 Agent；暂不据此判断整体满意度或稳定性。评价入口
• 厂商案例： 2026 年 9 月的 Club4 案例具体描述了 Nova 处理非营业时间咨询并推进预约。它支持“有具体客户采用场景”的判断，但增长数据属于厂商发布，未取得原始统计或独立归因验证。Club4 案例
• 可继续查看的材料： 官方客户案例与视频入口可用于查找实际经营者及使用场景。本轮没有完成视频逐段观看，不把页面上的评价和演示入口视为操作实测。

仍需了解： 人工接手后的事项是否持续存在、员工能否改计划和纠正判断、跨渠道客户去重方式、取消挽留是否实际修改会籍、各 Agent 的上线范围，以及报价包含哪些模块。

#5. OTF / Retool：总部自己开发也是一种替代方案

(1) 公开案例中的功能清单

来源：Retool 的 OTF 客户案例。这里列的是案例明确提及的应用能力；公开资料没有提供完整功能规格。不能由此推断它已包含通话 AI 分析、Coaching 或与我们相同的持续 Task，也不能推断它一定没有。

(2) 对我们意味着什么

总部已有开发基础和业务系统，单纯展示几个页面、报表或管理功能，未必能说明采购价值。需要让对方判断：自行开发同样的业务能力，还需要多少需求整理、规则设计、门店验证和持续维护。

(3) 我们可以怎么谈

围绕具体需求演示已经积累的产品做法，再商量作为现有系统的补充、嵌入功能或共同开发项目。用一个对方提供的业务场景检查能复用多少、需要适配多少，比笼统说“我们开发更快”更有说服力。公开案例也不足以证明截图中的所有 OTF CRM 或 SPOG 页面都由 Retool 实现。

#5.1 补查边界：Retool 的能力不能代替 OTF 实施资料

官方案例能确认： OTF 使用 Retool 开发线索、会员和门店应用，支持客户触达、查看业务数据与写回操作。案例还说明了自托管及与 Microsoft 企业平台结合的选择。OTF / Retool 案例

本轮仍未查到： OTF 当前完整操作手册、各加盟商部署范围、角色权限矩阵、AI 功能清单，以及这些应用的实际维护费用。Retool 公共文档或通用 Demo 只能解释开发平台，不足以证明 OTF 启用了哪些功能。案例中的历史推广计划也不能当作已完成状态。

对我们最有用的下一步资料： 获授权的 OTF 门店实际操作流程，尤其是线索进入、取消请求、员工交接、未解决事项和经理检查。需要与我们的同一业务场景比较，不能只比较页面名称。

#6. Retaintive 的优势应该怎样表述

本节保存 2026 年 9 月 30 日讨论确认的优势与接洽思路，依据当前官网、产品源码和官方竞品资料。这些是我们值得展示和验证的长处；是否比某个竞品更好，需要在同一场景下比较。 源码存在、官网演示和客户实际使用效果分别记录，不相互替代。

#6.1 核心价值

把可负担的多门店部署作为重要目标，将客户历史、持续跟进、员工执行和经理管理连在一起，让老板能比较门店，并回查数字背后具体发生的事。 产品目标是通过更好的 lead conversion 和 member retention 帮助门店增长收入；当前不能把这个目标写成已经证明的收入提升。

老板最关心的路径是：看各店差异 → 找到需要检查的环节 → 打开相关客户、任务和沟通 → 决定该跟进、调配工作还是辅导。比较能帮助提出问题；具体原因需要回到记录确认。

#6.2 优势与展示方法

1. 跨店比较，并回查具体工作。 My Stores 可以在同一报告期间比较 Leads、Tasks、Calls；可点击的指标带着门店和日期范围进入对应工作台。老板可以看到哪家店线索多、联系少或预约少，再查看相关客户和原始工作记录。三类报告各有日期依据与统计对象，同一期间不代表同一客户 cohort，不能直接把跨表数量相除当转化率。不是所有汇总数字都有等数明细入口，例如 Received 是进线事件计数。见 My Stores。

2. 看出跟进停在哪一步，找到还需要处理的客户。 单店漏斗区分新线索、开始外联、联系上、预约等阶段，并能进入尚未外联、尚未联系上、尚未预约的队列。首次外联速度帮助检查响应是否及时。这样老板和经理能决定先处理哪一环，而不只看电话总量。它不是广告投放 ROI，也不能单凭某个阶段的比例判断员工造成了流失。见 Dashboard 和 Leads。

3. 客户目标可以持续推进。 同一个客户任务保留后续沟通、处理记录、下一步和结果；一次电话或短信是一次 Activity，通常不等于整个 Task 已完成。员工能继续推进线索转化、会员关怀等工作，经理能检查进展。给客户预约 intro 也不等于已经入会或产生收入。见 Tasks 和 Calendar。

4. 员工能用历史接手工作，减少重复整理。 客户沟通、任务和员工补充集中到业务记录中，后来接手的人可以查看背景、已经做过什么、客户顾虑和下一步。换员工或换模型后，这些记录仍然积累在产品中。它提供交接所需的上下文；完整 owner 离任、连接转移和账号交接能力仍需另行验证。见 Contacts。

5. 经理能看到工作分配、开始情况和无人负责的工作。 Team 视图按员工查看任务和处理记录，区分未开始、尝试过、证据不足、已关闭等状态，也保留未分配工作。经理可以据此检查、分配或调整下一步。证据不足不等于员工没有工作，任务数量也不能直接当绩效排名。见 Dashboard。

6. 辅导能回到具体沟通和依据。 经理可查看录音、转录、关键片段和辅导意见，用实际对话说明哪里需要改进，并留下复盘记录。经营异常与沟通复盘可以在同一产品中检查。这是可展示的管理流程，不能写成已自动形成跨店最佳实践库或已证明辅导提升收入。见 Coaching。

7. 员工可以复核和纠正 AI，记录保留前后变化。 当前已有纠正 AI-set intro booking、修正识别错误的 staff name 等具体路径。AI-set intro booking 的纠正需填写理由，并保留原事件与后续修正；staff name 修正保留前后值、操作者和时间，并可附理由。好处是团队能检查判断，不必把 AI 输出当不可更改的事实。不要扩大为所有 AI 字段均可任意编辑，或员工反馈已自动训练模型。

8. 模型选择有弹性，业务流程与历史可以延续。 当前经 OpenRouter 接入模型，共享配置可选择模型，默认使用 DeepSeek。我们可以按工作要求平衡质量、速度和费用；更换模型仍需验证结构化输出、质量和时延，部分阶段也有固定模型。对外可讲 flexible model selection，不承诺任意模型无需适配即可切换。RingCentral MCP 也面向不同 LLM，模型选择本身不能当作对方没有的能力。

9. 业务数据独立积累，记录规整且可回查。 客户沟通、Tasks 和 AI 分析保存于 Retaintive 管理的 Neon／AWS 存储；记录包括时间、来源、员工处理和结果依据。更换模型时，客户历史不需要跟着聊天会话重建。“数据留给自己”在这里指经营记录持续积累在业务系统中；不等于客户 self-host，也不等于内容不经过第三方模型。完整数据导出、删除及供应商留存承诺需单独核实，不能从现有报表 CSV 导出推断全部数据都可迁移。

10. 低成本运行与多店部署的定价空间。 可以选用经济模型、记录模型用量和费用，这是支持可负担定价的基础。已有历史成本报告和单次模型费用记录，但尚未核实当前完整 SaaS 成本、客户售价及同功能竞品报价。因此保留成本作为重要优势方向，具体“便宜多少”留到同样人数、用量和功能对齐后证明。门店本来使用 RingCentral 时，应比较新增运营能力的增量费用；RingCentral 插件对现有用户免费，ACE起价 $60/user/month，不能统一写成每店必须新增 $200–300。

11. 与既有门店软件配合，并为合作方提供可复用的产品积累。 当前主要使用 RingCentral communication、Email Lead 和员工输入，预约及会员业务仍由门店既有工具负责。围绕 OTF 工作流程形成的跟进、管理和辅导产品可供合作方评估，有机会减少从头开发的工作；节省多少仍需共同验证。Mindbody 等更深入的业务数据连接、其他品牌或行业适配、自动 AI 销售与客服属于后续开发方向。见 工程资产与未来能力。

其中第 1–7 项和第 9 项的价值在于一套工作流程的衔接：员工处理客户，经理看执行与沟通，老板从汇总进入同一套记录。官网的 Staff、Managers、Owners、HQ 是理解产品的角色视角，不据此推断已实现完整的集团角色权限树。

#6.3 官网可以怎样帮助对方理解

首次邮件附 retaintive.ai 即可，让对方按自己的工作进入对应页面：Staff、Managers、Owners、HQ。不用在首封把上面的优势全部展开。

官网 Owners 页展示线索阶段、首次外联速度和仍等待处理的客户；HQ 页展示两家测试门店的线索、预约和电话差异。用这些例子说明“可以比较什么、接下来查什么”，不把差异直接归因于话术、员工能力或产品效果。

演示资料边界： Demo Studio 使用合成数据，Coaching 使用内部测试通话，HQ 使用测试门店汇总；视频由产品截图制作，并非一次真实客户操作的完整录像。Drew 的故事展示持续跟进到员工确认的 intro booking，没有入会或收入。真实门店使用证据另见 West Harlem 生产证据，不能与这些示例混写。

#6.4 按收件人选择重点

首次接洽的目标是获得回复、短会或准确转介。 保留相同产品主干，结合对方当前职责、背景与经验选一两个相关价值；其余留给网站和交流，不把每个人的邮件写成完整功能清单。

对 RingCentral 的首封不以“我们更便宜”或“你们没有这些功能”开场；成本、模型与具体合作形式可以在对方有兴趣后展开。成本方向仍保留在内部优势判断中，不因为首封省略而放弃。

#6.5 证据入口与仍需验证的事项

本轮源码快照：callytics-infrastructure 为 79ccdf8f2，landingPage 为 bd3914c。这是 source review，不是当前目标门店的运行验收。

• 门店比较与进入工作台：apps/web/src/pages/my-stores/composables/use-report-drill-targets.ts、apps/web/src/pages/my-stores/components/leads-report-table.vue；单店漏斗和团队查看入口在 apps/web/src/pages/store-detail/。
• AI 纠正与保留前后记录：apps/web/src/pages/tasks/components/task-ai-booking-correction-action.vue、apps/api/src/routes/v3/calls-amend.ts。
• 模型、持久化与结果依据：lambda/shared/utils/ai/model-config.ts、lambda/ai-analysis-processor/src/infrastructure/persistence-repository.ts、packages/common/src/db/schema/tasks.ts。
• 成本：历史成本报告与 docs/evals/results/2026-09-18-communication-first-pass/observations/model-cost-investigation.md。历史基础设施费用和单次模型费用不等于当前完整客户交付成本。
• 官网素材边界：landingPage/docs/otf-demo.md。收入估算与因果边界：packages/task-engine/src/metrics/revenue.ts，当前金额按配置价格推导，并非 billing／POS 实收，因果归因尚未建立；未知金额不显示成零。

后续比较要确认：员工是否更容易接手、重要客户是否更少遗漏、经理是否更快找到需要处理的问题、多店部署完整成本是否可负担，以及合作方能否复用已有积累。录音数量不等于有权出售的独家数据，客户关系与连接是否能够继续也需分别确认。