把客户通话里的承诺转成 Jira 和 Salesforce 中可追踪的执行对象，服务 B2B SaaS 团队。

1. 现在已经能把口头承诺和 CRM、文档、工程系统对照核验，而不是让它只躺在会议笔记里。
2. 对 Outlook、Teams、SharePoint 和 Slack 的扩展计划说明，这层集成织网很快就会覆盖标准企业技术栈。
3. Otter 自己的对外叙事正在从记笔记转向机构知识，这验证了买方确实想要能把会议数据变成运营动作的软件。
4. 当企业已经开始把工作流规模的会议笔记、跟进和行动项当成运营输入，就说明会议产出不再只是档案。

催化因素。 Otter 推出跨工具企业搜索和偏工作流的会议代理后，第一次让“从通话里抽出承诺，再去执行系统里核验它有没有落地”这件事变得现实可做。

会议承诺图谱连接 Otter、Salesforce、Jira、Notion 和邮件，为客户通话里的承诺建立一层系统记录。它抽取产品承诺、商业让步和后续义务，再把每条承诺连到账户、商机、路线图条目或内部责任人。产品持续盯执行偏差：续约已有风险却没有工单，答应过的集成没有 epic，或客户反复提同一个需求却始终进不了规划。它还会起草客户可见的跟进内容和内部升级材料，让团队在 QBR 和续约前先处理风险。时间拉长后，这份数据会沉淀成专有图谱，说明哪些口头承诺最容易带来流失、扩张，或拖慢路线图。

差异化。 大多数会议工具做到搜索、摘要或通用行动项就停了。这个产品是按“外部客户承诺会带来营收风险”来设计的：先识别承诺，再挂到系统记录层上，最后量化组织是否真的跟了下去。真正的防守力来自一张会越用越厚的跨系统图谱——承诺模式、履约结果和账户影响——而通用企业搜索厂商不会在这层建得这么深。

待完成任务

flowchart LR
  Buyer[RevOps 或 Product Ops 团队] --> Pain[客户承诺散落在通话和工具之间]
  Pain --> Product[会议承诺图谱]
  Product --> Outcome[漏掉的承诺更少，续约风险更低]

高管要点

• 会议转录正在变成跨工具的企业上下文层，但现有厂商大多仍停在搜索、摘要或辅导，还没有把“承诺到执行”的跟踪做深。
• 美国软件出版商这个滩头市场可以成立，但规模不大；要讲出 venture 故事，必须从 SaaS 续约扩到更广的企业义务跟踪。
• Otter 和 Avoma 的公开 seat 定价说明相邻工具已有预算，但新厂商若想拿到额外支出，必须证明自己能减少流失、升级事件或路线图偏差。
• 集成底座终于够用了：Otter 已覆盖 Gmail、Drive、Notion、Jira 和 Salesforce，Microsoft、Slack、Zoom 和 Google 的 API 也足以支持跨系统解析。
• 搜索平台和智能体平台已经验证了买方对跨应用知识访问的胃口，但它们显然还没为“按客户逐条对账承诺”这个场景做深优化。
• 隐私、安全和画像约束会直接塑造产品设计，也可能拖慢 EU / UK 扩张。

市场定义

这个品类是一层很窄的工作流软件，夹在会议智能、营收智能和企业搜索之间。它负责抓取客户通话承诺，把承诺映射到账户和工作系统里，并持续监控执行偏差。它不包括广义内部搜索、通用会议笔记或纯呼叫中心分析。

用户与买方

第一批买方会是中型到大型 B2B SaaS 公司里的营收运营、产品运营或客户成功运营负责人；这些公司已经在营收团队里跑 Salesforce、Jira 和会议记录工具。使用者还会包括销售主管、客户成功经理、产品经理，以及处理升级事件的管理层。预算大概率来自营收工具或生产力 AI 口径，但产品会触碰录音通话和业务系统，采购一定会把安全、法务和 IT 拉进来。

购买触发点

• 一次 Otter 式 meeting-AI rollout 让公司意识到，客户承诺其实早就躺在转录稿里，只是从来没稳定写进 Jira 或 Salesforce。 [1][2]
• 一次流失复盘或高层升级事件，逼着公司回头重建“是谁答应了什么、后来谁来跟进”的全过程。 [9][11]
• 当账户价值够高、信息又散在 20+ 个工具里时，人工跟进会慢到根本跟不上。 [15][36][23]

支付意愿

相邻产品已经把预算跑出来了：Otter 公开卖 business plan，Avoma 按 recorder seat 加模块收费，Gong 仍走定制化企业报价。这说明预算并不空白，但这家创业公司必须用续约风险或升级事件 ROI 来证明单独的平台费合理。 [3][10][7]

品类动态

增长信号 8.9% 复合年增长率

验证信号

• Otter 已经能把会议与 Gmail、Drive、Notion、Jira 和 Salesforce 联查，而且还会继续扩企业连接器。
• Avoma 对外宣称服务 1000+ 家组织、提供 30+ 集成，并用自动跟进来讲节省时间的价值。
• Glean 的客户案例已经把痛点和 ROI 量化出来：Webflow 提到 20+ 个工具，Confluent 提到每月节省 15,000+ 小时。
• Atlassian 正把 Rovo 继续扩到 MCP 连通性和 Jira 工作流里。
• Salesforce 也在把 agentic workflow 更深地压进系统记录层。

监管与技术约束

• 录制会议数据叠加业务系统上下文，一定会触发安全审查、retention 追问和 DPA 审视。
• 自动给承诺打风险标签，在 UK / EU 语境里可能会被认定为 profiling。
• 跨 Microsoft、Slack、Zoom、Google、CRM 和 Jira 的连接器稳定性与范围管理，是一等产品风险。
• 实体解析必须足够准，才能把一句口头承诺挂到正确账户、工单和 owner 上，而不是制造噪音。
• 在买方愿意信任自动化之前，他们会要求看到源头级证据链。

竞争会来自四路：会议智能厂商、企业搜索 / 智能体平台、CRM / 工作流现有巨头，以及企业内部用 API 自建的方案。创业公司只有在“外部客户承诺”这一层真正成为默认系统，才有机会赢，而不是再做一个泛搜索层。

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

• 企业搜索平台. Glean 和 Rovo 在跨应用检索和通用可执行性上都很强，但公开定位仍比“绑定续约风险的 SaaS 专用承诺对象”更宽。
• 会议智能厂商. Otter、Gong 和 Avoma 都能抓通话、做自动跟进，但它们的切口仍是笔记、辅导和 pipeline 可见性，还没真做到下游承诺核验。
• CRM 与工作流套件. Salesforce 和 Jira 接得住人已经创建好的下游对象，却天然抓不住写进 CRM 之前那层口头承诺。
• 云平台. Microsoft、Slack、Zoom 和 Google 提供了足够的 API，也可能顺手打包相邻能力；但光有分发，并不能解决 SaaS 专用 taxonomy、可审计性和运营工作流本身。
• 内部自建. 团队现在就能很快拼出 transcript workflow 原型，但真正难的是长期权限管理、实体解析，以及达到审计级别的反馈闭环。

会议承诺图谱是一层企业工作流软件：把客户通话里说出口的承诺，变成能在 Salesforce、Jira、Notion 和邮件之间持续跟进的执行对象。第一批客户应是美国 B2B SaaS 公司，规模约 200-1,500 人，有企业销售周期、50-300 名面向客户的销售或客户成功人员，且最近刚铺开 Otter 或 Gong 这类会议记录工具。真正疼的不是搜不到信息，而是通话里答应过的事没有变成下游系统里有人负责的工作，最后拖出流失、升级事件和路线图偏移。滩头市场刻意做窄：盯续约和升级风险的产品运营、营收运营、客户成功运营团队；这些软件公司已经在录通话，也已经在跑 Salesforce 加 Jira。产品只有一条活路：足够准确地把口头承诺挂到正确账户、责任人和工作项上，团队才敢把它塞进现有流程。相邻工具公开定价说明预算并非不存在，但公司仍要证明，买方会为“减少漏承诺”单独付平台费，而不是把它当成记笔记软件的附赠功能。研究得出的美国 SAM 约为 $37.0M，并不算大，因此风投级故事必须在第一切口跑通后，把同一张承诺图谱扩到支持升级、实施义务和更广义的企业承诺跟踪。最可能推翻故事的风险有三类：抽取准确率不够、会议/工作流厂商把能力打包吃掉，以及营收运营、客户成功和产品之间没人愿意真正承担修复责任。近期建公司的目标很明确：拿下 3-5 家共创客户，把试点到正式上线转化率做到 50% 以上，并证明高风险承诺 48 小时内被指派的比例明显高于人工流程。

问题

• 销售、上线和 QBR 通话里答应客户的事情，往往要等到升级事件或续约复盘时，团队才发现它根本没进入 Salesforce、Jira 和规划系统。
• 通用企业搜索和会议笔记能翻出上下文，但不会生成带责任人、截止日期、关联工作项和执行偏差告警的可审计承诺对象。

解决方案

• 接入录制客户通话以及 Salesforce、Jira、Notion 和邮件元数据，抽取产品、商业和后续跟进承诺，并保留源证据。
• 把每条承诺做成对象，连到账户、owner、due date 和对应 Jira epic 或 CRM 记录；在续约和升级前，先揪出无人认领、已经逾期或反复失手的承诺。

为什么我们会赢

• 这个切口比搜索或会话智能更窄——它只盯和营收风险绑定的外部客户承诺，因此买方、触发点和 ROI 叙事都更锋利。
• 真正的防守力不会来自转录稿本身，而会来自一张闭环图谱：承诺措辞、owner 模式、履约结果和账户影响会越积越厚。

里程碑

flowchart LR
  Wedge[续约风险承诺审计] --> MVP[只读承诺图谱 MVP]
  MVP --> Proof[48 小时内完成指派，且无人认领承诺更少]
  Proof --> Expansion[写回自动化与相邻承诺工作流扩张]

创始团队

实验路线图

风险评估

必须成立的条件

• 共创客户必须确认，漏掉客户承诺今天就会带来可量化的流失、升级或路线图偏移成本。
• 在不要求销售改行为的前提下，高置信度承诺抽取在第一工作流里至少能做到 85% 精度。
• 对滩头客户来说，Salesforce 加 Jira 已经覆盖了大部分修复工作流。
• 即便使用者跨部门，RevOps、Product Ops 或 CS Ops 里仍有人能真正背预算和部署。
• 当 ROI 证据摆出来后，正式客户愿意为平台费额外买单，而不是把它算进现有记笔记或会话智能预算里。

待尽调问题

• 到底是哪类复盘事件，让运营团队第一次意识到公司现在真的在漏承诺？
• CS 和 Product 团队能接受的误报率上限是多少，超过就会不再信？
• 第一笔预算更可能来自营收工具、生产力 AI，还是客户成功运营预算？
• 现在的 Salesforce 和 Jira 里，已经有多少结构化字段足以自动验证履约？
• 如果未来 12 个月内，Otter、Gong、Salesforce 或 Atlassian 自带 commitment object，会发生什么？

模型合理性

• 收入引擎. 基准情形的收入来自一条很窄的客户爬坡曲线——Y1 期末 6 个付费客户、Y3 期末 47 个，每家 ACV 约 $55K；并不是靠激进的 seat 数假设硬堆出来。
• 必须做对的事. 付费试点必须接近计划里的 50%+ 转正目标，这样创始人销售加 1 名 AE 才能在不大幅扩编销售团队的情况下，于 Q4Y2 做到 25 个付费客户。
• 模型失效条件. 如果定价被压到 $48K，且销售周期继续拉长，下行情形下现金会在 Y3 前探到约 -$341K。
• 下一轮融资验证点. 如果公司接近以约 $2.6M ARR 收在计划末端，且 Q4Y3 EBITDA 转正，同时能证明承诺图谱已从续约扩到相邻工作流，那么下一轮融资叙事才真正站得住。

情景

敏感性

flowchart LR
  Leads[线索] --> PaidPilots[付费试点]
  PaidPilots --> ProductionCustomers[正式客户]
  ProductionCustomers --> Revenue[收入]
  Revenue --> GrossProfit[毛利]
  GrossProfit --> OperatingCash[经营现金]
  ProductionCustomers --> Expansion[扩容]
  Expansion --> Revenue

警示项: 由于 schema 里没有单独融资流水线，模型默认在起始时点就拿到 $2.2M pre-seed。 · 基准情形下，Y3 全年 EBITDA 仍为负，因此 seed 叙事更依赖高效率 ARR 增长和 Q4 的经营杠杆，而不是全年盈利。 · Y3 期末做到 47 个 logo，略高于 research 里约 45 家可触达客户的 SOM，因此模型隐含假设：相邻工作流扩张会在第 3 年末前开始兑现。 · 模型从第一批付费部署起就把毛利率固定在 business plan 的 75% 目标；如果早期实施和支持更重，真实毛利可能会更低。

• 平台依赖. 如果 Otter 或周边会议厂商把这条工作流直接吃掉，分发空间会立刻变窄。 缓解措施: 从第一天就保持厂商无关，覆盖 Otter、Gong、Zoom 和 Teams 录制，并把下游承诺图谱握在自己手里。
• 抽取准确率. 如果把随口建议误判成刚性承诺，营收团队很快就会失去信任。 缓解措施: 设置信心阈值；对高风险账户走人工复核队列；再用 Jira 和 CRM 的闭环结果回灌模型。
• 跨部门责任不清. 营收运营最先感到痛，但真正要执行的往往是产品或客户成功团队，采用会因此拖慢。 缓解措施: 先卖给本来就背续约和升级指标的运营团队，并把任务分派直接塞进现有 Jira 和 CRM 流程。