销售管理·Sales Note Taker

它解决什么问题

销售团队落地 AI 会议记录时常见的两个坑：选型只看功能清单，忽略团队自己的销售方法论和下游系统；集成方案反过来被单一供应商的 API 绑架。这个技能不绑定任何厂商，把「选哪个」和「接到哪」拆成两条可组合的决策路径，而不是一次采购决定。

技能如何工作

第一步：先收上下文

• 若存在 references/learnings.md，先读取已有的经验积累。
• 向用户确认四个问题：主要目标（选型对比 / 接入已有 note-taker 的 API / 两者兼顾 / 排查具体的 API 或 webhook 问题）；使用场景（销售管线智能与教练辅导、客户成功、跨部门会议，或指定工作流，例如自动写入 HubSpot、把待办推到 Slack、全量进 Snowflake）；转写流向（CRM、数仓、内部应用或数据库、Slack，或多目标 fan-out）；规模。

选型维度

技能给出的是可比较的排序，而不是泛泛的推荐：

• 销售方法论支持：Avoma > tl;dv Business（MEDDIC/BANT/SPIN playbook、聚合洞察）> Salesloft Conversations / Chorus > Fathom / Fireflies（仅基础 scorecard）。
• API 完整度：Gong（webhooks + REST，最丰富）> Fireflies（GraphQL + webhooks）> Avoma > Fathom > Wave / MeetGeek / Jamie（均带 MCP）> Grain > Sembly > Read.ai > tl;dv > Granola（只读 REST、无 webhooks）> Jamy（REST 仅 2 个端点）；Otter API 仅企业版 beta。
• 合规：Gong、Avoma、Fireflies Business、Fathom Business 具备 SOC 2 + GDPR；涉及 HIPAA 等强监管行业时，候选缩到 Gong / Avoma / Fireflies Enterprise。

集成架构

• 优先 webhook，polling 兜底：厂商提供 transcription.completed / meeting.ended 事件就用事件推送；没有则退回 list + fetch；生产环境建议 webhook 实时 + 定期 reconcile-poll 混合，覆盖 webhook 漏事件的情况。
• 标准链路第一步：webhook receiver（Lambda / Cloud Run 等 serverless）校验 HMAC 签名并把原始 payload 入队；第二步交给 worker 处理转写数据——SKILL.md 正文在此处截断，下游处理细节需要按项目补齐。

适用边界

• 它是策略顾问而非执行器：输出选型排序和集成模式，不会替你调用任何厂商 API。
• 快速推荐矩阵覆盖上百个工具（从 Gong、Fireflies 到开源自托管的 Meetily、Handy），信息密度高，但价格和版本档位仍需对照官网复核。
• 排查 webhook 问题时，技能从问题分类入手，但实际排障仍需在目标平台上验证。