sales-ops

销售运营和 CRM 工作流

在 Airtable 中设置并运行销售运营工作流，包括销售管道、客户账户、续约、交易支持、RFP 跟踪、合作伙伴 CRM，以及针对垂直行业打造的销售系统。根据团队规模、现有 CRM 和行业进行调整。搭建前先询问范围；同一个触发条件可能意味着为 5 人团队搭建一个包含 3 张表的销售管道、为 200 人的企业销售团队搭建一个增强 Salesforce 的交易支持系统，或为抵押贷款经纪人 / 房地产公司 / 公共工程承包商搭建一个垂直行业专用 CRM。

面向的用户及其要解决的问题

销售运营涵盖的角色和垂直行业，比“使用 Salesforce 的销售副总裁”这种刻板印象更广。

• 营收负责人（CRO / 销售副总裁 / RevOps / 销售运营经理）——销售管道覆盖率、预测准确性、细分市场可见性、从潜在客户到营收的效率。“出问题了” 意味着 “我无法信任这些数字。”
• 一线运营人员（AE / SDR / BDR / 客户经理）——接触客户时所需的客户背景信息、快速分配入站线索、清晰的交易阶段、轻松记录活动。“出问题了” 意味着 “我为了发一封邮件，要在五个标签页之间来回复制粘贴。”
• 跨职能支持人员（交易支持、销售工程、销售运营分析师）——带审计记录的审批路由、产能与需求对比、技术适配度评分、例外情况分流。这是有别于 CRM 本身的独立产品界面。
• 合作伙伴 / 渠道经理——合作伙伴主导的销售管道汇总、带防冲突规则的交易登记、联合客户规划、MDF 跟踪。
• 垂直行业运营人员——抵押贷款专员、房地产经纪人、商机拓展经理（公共工程 / AEC）、捐赠者关系负责人、资本市场交易台运营人员——使用行业专属术语、遵循行业监管要求并集成行业工具的销售类工作流。

跨领域的常见问题：现有 CRM 通常会继续使用，但实际工作却在电子表格中进行（“在多个系统间来回切换”、“单一事实来源”）；按席位收费会将利益相关者排除在系统之外，导致可见性下降；现代销售技术栈（Outreach / Salesloft / Apollo / Gong / CaptivateIQ）在非科技行业和中型市场中通常 不存在；以 AI 为先的团队希望在开放的数据底座上构建与 Clay 同类的信息丰富功能、AI 起草的外联内容和对话智能数据接入，而不是使用后期强行加入 AI 功能的 CRM。

搭建前：询问范围

销售运营涉及的行业和形态比大多数类别都更广——在 Airtable 中运行销售工作流的大多数客户都不是科技 SaaS 的 GTM 团队。房地产中介公司、抵押贷款运营团队、保险公司、资本市场交易台、公共工程承包商、管理捐赠者的非营利组织、管理合作伙伴关系的教育机构、跟踪交易的人才经纪公司——它们都在 Airtable 中运行“销售运营”，但采用不同的架构和工作流。先提出三个范围问题，再据此分流。

1. 团队规模和结构。 独立开发者 / 小型团队（少于 10 人）/ 中型团队（10–50 人）/ 大型团队（50 人以上）/ 企业级（多个团队 / 多个基地）。这决定架构形态的默认选择——一个由 5 人组成、正在构建首个 CRM 的团队，与一个拥有 200 人、希望扩展 Salesforce 的销售组织，需要的脚手架并不相同。
2. 现有 CRM（或有意不使用 CRM）。 “你们目前有 CRM 吗（Salesforce、HubSpot、Pipedrive、较小型 / 垂直领域 CRM、尚无 CRM、‘大家都讨厌的 Salesforce’，还是正在构建不依赖传统 CRM 的 AI 原生技术栈）？” 这是此技能中最关键的问题。它能促使大家明确讨论扩展、替换还是从头构建。说明整合的价值主张，让用户自行选择：全面迁移（Airtable 替代 CRM——在规模较小或非科技行业中很常见）、扩展（Airtable 作为灵活的 UI / 预处理 / CRM 前置 / CRM 后置层，位于作为事实来源的 CRM 之上——在大规模场景中最常见）、减少许可证（Airtable 作为只读为主的 UI，供无法证明购买 CRM 席位合理性的相关人员使用）、为子团队提供轻量级 CRM，同时主 CRM 继续作为 SoR，或AI 原生精简技术栈（Airtable 作为面向 AI 优先初创公司的数据基础层，这类公司可能永远不会采用传统 CRM——在 Airtable 的类型化记录、AI Field Agents 和 REST API 之上，叠加类似 Clay 的数据丰富功能、AI 客户简报和 AI 辅助外呼）。这五种方案都有效；不要把任何一种当作指令强推。各 CRM 和 AI 技术栈的集成机制，参见 references/integrations.md。
3. 主要子工作流。 “销售管道管理、客户管理、续约流程、交易审批、RFP / 招标管道、合作伙伴 / 渠道 CRM，还是特定垂直领域（抵押贷款、房地产、经纪业务等）？” 这决定了应该优先采用哪种工作模式操作指南和架构形态。大多数用户首先只需要其中一种，而不是全部。

仅在相关时，才围绕以下内容展开：

• 行业 / 垂直领域信号。 当用户的用词表明相关性时（“经纪人”、“招标”、“贷款”、“承保”、“物业”、“捐赠者”），确认所属垂直领域并加载相应架构。垂直领域架构难以跨行业通用——抵押贷款 CRM 和公共工程招标管道在运营层面几乎没有共同点。
• 减少许可证的动机：适用于使用 Salesforce 且团队规模较小（销售代表少于 20 人）或预算有限的情况。此时可提出“Airtable 作为 SFDC 之上的只读为主 UI 层”模式，而不是全面替换。
• AI 供应商限制——出现 AI 工作流时，询问是否存在经批准的供应商 LLM 限制（仅限 Gemini、不允许使用第三方 LLM）。这在受监管的企业中是实际存在的情况。
• 是否需要面向外部用户的界面？ “品牌化的合作伙伴 / 供应商 / 承包商门户？公开的合作伙伴注册？嵌入现有产品？Slack / WhatsApp / Teams 机器人？” 有两种可行方案——都应介绍给用户，由用户自行选择。Airtable Portals 是官方品牌化外部协作者界面（基于 Interface，支持自定义登录 / 标志 / 背景；付费附加组件，门户席位按 Team 层级定价起步）——设置最快，适合 Interface Designer 的组件集能够满足工作流需求的情况。如果用户需要完全掌控设计、担心 Portal 附加组件的预算、需要超出 Interface Designer 组件集的 UX、需要服务端计算、希望嵌入现有产品，或希望采用聊天驱动的渠道，则应选择 Vercel 等平台上的自定义 UI。两者都合理；由用户决定。

三个关键问题通常一轮就能明确脚手架方案。先倾听，不要急于强加框架。

两种模式

搭建模式：构建基础架构

当用户提出 “设置 CRM” / “为我构建销售管道” / “跟踪交易” / “构建合作伙伴注册系统” 时，在明确范围后，通过 MCP 搭建架构。

1. 范围问题（见上文）。阅读答案。花 5 分钟沟通范围，胜过重建一个结构错误的架构——尤其是这个类别涵盖的行业多种多样。
2. 选择架构结构，以匹配团队规模、现有 CRM 和垂直领域。技能正文中内联列出了五种潜在客户架构；垂直领域和专用架构可按需查阅 references/vertical-shapes.md 和 references/schema-shapes.md。
3. 通过 MCP 构建架构——基础表、类型化字段、关联记录、公式、汇总字段、示例 / 种子数据。架构是后续所有工作的基础。将 Agent 的精力投入到更丰富的类型化字段、精心设置阶段颜色的状态 singleSelect，以及带汇总计数的关联记录关系（例如，将 Opportunities.Amount × Probability 汇总为 Account 级别的预期收入）。
4. 移交 UI 配置——视图（按阶段分组的 Opportunities 看板、按下次操作日期排列的日历、Accounts 画廊）、Interface 页面、自动化、表单、同步向导（Salesforce / HubSpot / Slack / Jira）。请参阅下文的“构建计划输出”。
5. 构建用户所需的任何外部界面——对于合作伙伴 / 供应商 / 承包商 / 客户门户，说明 Airtable Portals（付费附加组件，基于 Interface，支持品牌化登录）是一种选择，使用 REST API 读取 Airtable 数据的自定义 Vercel 应用是另一种选择。用户选择哪种，就构建哪种；不要替用户决定。聊天驱动的工作流（Slack / WhatsApp / Teams 机器人）、嵌入现有产品的界面或其他自定义 UI 也是如此——用户最清楚哪种适合自己的情况。请参阅 references/build-shapes.md 了解相关模式。

潜在客户架构

最常见的五种架构——涵盖绝大多数调用场景。字段逐项的完整说明见 references/schema-shapes.md。

• 轻量型销售流程（1–2 张表） — 销售流程 + 联系人。适用于独立创始人、2–3 人的销售团队，以及没有专职 SDR/AE 职能的交易跟踪场景。不要强加他们用不上的多表 CRM 结构。客户常见说法：“我只需要跟踪交易”、“列出我聊过的人”。
• 独立使用 / 小型（3 张表） — 客户 + 联系人 + 商机。经典 CRM 三角结构。用户想要 CRM，且没有现有系统需要扩展时，这是默认选择。添加阶段推进、概率、预期成交时间、负责人和潜在客户来源。可选轻量 AI 集成（LinkedIn 信息补全、AI 生成会议准备材料）。
• 中型（5–6 张表） — + 活动（电话 / 会议 / 邮件）、+ 若入站线索量足够大则添加独立的线索表、+ 阶段配置表。适用于端到端自主管理 CRM 的 10–50 人团队。添加预测汇总（按季度计算概率加权预期价值）、线索评分、轮询式线索分配。
• CRM 扩展型（与 Salesforce / HubSpot 并用） — 同步的客户 / 联系人 / 商机（从 CRM 只读）+ 用于记录 CRM 不擅长建模内容的原生 Airtable 表：交易审批请求、客户推荐数据库、产能 / 配额跟踪、销售工程资源分配、活动 / 会议记录同步。50 人以上销售组织中最常见的形态。 如需将数据回写到 CRM，则通过 Automations 实现双向同步模式。
• 企业级多 Base 扩展型 — 多 Base 中心辐射式架构；中央中心汇总各地区或项目的辐射端；通过 Automations 实现双向同步；通过 Interfaces 设置行级权限，让销售代表只能查看自己的客户，同时管理者可查看汇总数据。适用于需要各业务单元自主运营，且高管需要查看汇总数据的多地区或多项目销售组织。
• AI 原生精简技术栈（有意不采用传统 CRM）— 客户 + 联系人 + 商机 + 活动 + AI 密集型信息补全表，AI Field Agents 通过 LinkedIn、网络调研和外部信息补全 API 逐级补全记录（相当于 Clay 的模式，在 Airtable 中原生实现）。可添加 AI 起草的外联内容（先放入审核队列，不会自主发送）、AI 生成的客户简介，以及从同步的转录文本中提取 AI MEDDIC 字段。适用于选择 Airtable + AI 工具而非 Salesforce + 附加组件的 AI 优先型初创公司。详见 references/schema-shapes.md#ai-native-lean-stack。

垂直行业和专用形态 — 仅当范围相关答复表明需要时才展示（详见 references/vertical-shapes.md 和 references/schema-shapes.md）：

• 经纪 / 佣金 CRM（房地产、人才、抵押贷款经纪、财务顾问）— 行业专属定价 / 合同 / 佣金计算
• 房地产 CRM（住宅 / 商业；商机推进阶段、MSA、英亩数公式）
• 抵押贷款运营 CRM（客户 → 案例 → 计划、6 个月续期触发器、LOS 同步）
• 资本市场 / 投资银行（大宗交易生命周期、赞助方覆盖）
• 公共工程 / AEC 招标流程（商机分级、是否参与决策、利益相关方情报）
• 非营利 / 筹款 / 捐赠者流程
• 合作伙伴 / 渠道 CRM，支持外部协作者访问
• 交易审批 / 审批工作流 / 定价计算器中心（与 CRM 不同的产品界面）
• 客户推荐 / 拥护者数据库
• 销售工程活动与产能跟踪
• 支持销售代表级行权限的销售订单预测
• 含投标前情报的 RFP / 招标流程

不要给 3 人团队强加 7 张表的 CRM；也不要给有 5 个销售小组且已在使用 Salesforce 的企业组织交付 3 张表的入门版。应根据答复选择合适的形态。

按需介绍的值得关注的新兴模式：共同执行计划（MAP）/ 交易室 / 评估室 — 客户需求高，但实际交付较少。可以在商机表上搭建为子工作流，但应标注为新兴模式，而不是默认选项。

构建层决策

设置模式的技能可以在四个并行层之间组合使用（而非瀑布式）：

1. 架构层（始终通过 MCP） — 基础结构、类型化字段、关联记录、公式、种子数据。这是基础；每条路径都要经过这一层。
2. Airtable 原生 UX — 视图、Interface Designer 页面、Automations、表单、细粒度权限、同步设置向导。MCP 当前支持的内容使用 MCP；暂不支持的内容则通过 [click here] 移交。
3. Airtable Portals — Airtable 第一方品牌化外部协作者界面，基于 Interface Designer 构建，包含自定义登录页面（徽标 + 背景），每个基础一个门户，访客用户可拥有只读、评论者或编辑者权限。付费附加组件（Team 和 Business 层级；Enterprise 功能）。适用于用户希望为外部协作者快速提供品牌化登录体验，且 Interface Designer 的组件集能够满足工作流的情况。
4. 自定义应用层（REST API + Agent 构建的 UI） — 部署在 Vercel 上的 Next.js / React 应用、Slack / WhatsApp / Discord / Teams 机器人、定时脚本、嵌入用户现有产品的界面。适用于用户希望完全掌控设计、在现有产品中嵌入界面、使用聊天驱动的渠道、进行服务器端计算，或实现超出 Interface Designer 组件集能力的 UX。

对于面向外部的界面，应同时展示 Portals 和自定义 Vercel 两种方案，交由用户选择。 两者都不是默认方案，都是合理选择。若 Portals 的组件集符合需求且附加组件的成本可接受，它能节省构建时间；如果用户有能力构建和托管，自定义 Vercel 则能提供完全的设计控制权，并免去附加组件费用。用户比技能更了解自身的限制（预算、设计需求、工程能力、上线时间）。

如果用户只说 “我想跟踪交易” / “管理客户”，而没有指定任何面向外部的界面，则优先采用 Airtable 原生方案。提到外部协作者时，应同时介绍 Portals 和自定义应用两种选项，并遵循用户的选择。

具体模式请参阅 references/build-shapes.md，了解这两种路径。

工作模式：操作现有基础

当用户针对已有基础调用此技能时——“分诊本周的潜在客户”、“准备季度业务回顾预测”、“标记有风险的续约”、“为这些入站 RFP 评分”——应识别用户需要的子工作流，通过 MCP 执行（筛选、评分、更新、汇总），然后使用 show-airtable-link 移交结果。

潜在客户子工作流

十二种子工作流模式涵盖了大多数调用场景。每种模式都在 references/sub-workflows.md 中提供了完整操作指南——按需加载相关章节。

1. Pipeline 分类与阶段推进 — 按阶段、资格字段、时长、负责人筛选商机；识别停滞交易；更新阶段／下一步／概率。这是最常见的 Work-mode 调用。
2. 线索路由与分配 — 为入站线索评分／分类；通过轮询或基于规则的分配方式路由给 AE／SDR；通知 Slack。自动化链路足够紧凑时，可在一分钟内完成接手。
3. 预测审查 — 按季度／负责人／细分市场／垂直领域汇总 Amount × Probability；识别预测风险；导出到 BI。Pipeline 覆盖率和预测准确度是核心指标。
4. 客户研究与客户简介生成 — 汇总 Accounts／Opportunities／Activities／外部来源（LinkedIn、新闻、网络研究）中的背景信息；生成会议准备简介。在权限允许时可借助 AI 辅助。
5. 续约 Pipeline／风险监控 — 识别即将续约的客户；汇总使用情况／互动信号；标记风险客户；触发 CSM 行动。这不同于原始 Pipeline；这是售后商务环节。
6. 销售到服务的交接 — 验证 Closed-Won 商机是否达到必填字段要求（PO、金额、发货日期、条款）；在运营／安装／项目表中创建下游记录；通知交接团队。Pipeline 不会在“Closed-Won”时结束。
7. Deal desk 审核 — 对 Deal Support Requests／定价例外／合作伙伴例外请求进行分类；路由给审批人；以满足 SOX 审计要求的方式跟踪审批状态；关联回商机。
8. 合作伙伴／渠道 CRM 运营 — 合作伙伴 Pipeline 审查、渠道注册、联合客户规划、合作伙伴主导的 Pipeline 汇总、交易注册审批。为外部协作者提供界面，让合作伙伴登录 Airtable 更新自己的记录。
9. RFP／招标 Pipeline 运营 — 投标前情报分类、是否参与决策跟踪、投标提交状态、按层级分析赢单率，以及面向 AEC／公共工程／企业 B2B 的争取与竞标策略。
10. 客户推荐／拥护者数据库运营 — 将客户需求与可用推荐客户匹配；根据合同中的条款检查权利／许可；记录使用情况以跟踪过度请求风险。
11. 数据丰富瀑布流（等同于 Clay） — 对每条记录进行多源 AI 数据丰富（LinkedIn → 网络研究 → 外部数据提供商 → 从非结构化来源提取结构化字段的 AI Field Agents）。逐条记录的瀑布流逻辑：先尝试主要来源；若缺失，则尝试次要来源；最后通过网络研究补充。Airtable 中的原生模式；大多数团队无需单独订阅 Clay。
12. AI 辅助外联草稿（副驾驶模式，而非自主模式） — 利用 AI Field Agents，根据客户和联系人的背景信息，为每位收件人生成外联草稿（电子邮件、LinkedIn、多渠道序列）。草稿进入审核队列；发送前由人工批准。关键点：这是经过验证的模式——完全自主的 AI SDR 工具在市场上流失严重，而副驾驶模式（AI 起草 → 人工审核）则能持续发挥作用。

另外，当用户明确在构建 Agent 驱动的工作流时，值得展示一种可选模式：

13. Agent 活动日志模式 — 当用户描述 Agent 驱动的工作流（定期分类、多步骤计划、自动监控）时，展示可选的 Agent activity log 模式，并组合 agent-activity-log skill 来搭建和运行。不要内联重新实现其架构。

更广泛的 Work-mode 子工作流参考资料位于 references/sub-workflows.md — 垂直领域特定工作流（抵押贷款续约结案、经纪佣金结算）、专门工作流（销售工程产能汇总、销售预订预测快照、空白区域映射、季度销售规划）、新兴模式（共同执行计划／交易室），以及其他 AI 副驾驶模式（AI MEDDIC 提取 → 人工验证、带自动路由的 AI 入站分类器、基于网络研究的 AI 客户简介）。当需求涉及这些内容时加载。

组合使用

此技能与三个同级技能配合使用；不要重复实现它们负责的功能。

• show-airtable-link — 每个 Setup 模式的构建计划都以一个 base 链接结尾；每个涉及记录的 Work 模式操作都以一个记录 / 表 / 页面链接结尾。必须组合使用。传递工具调用已确认可以访问的最具体 URL。
• airtable-filters — 当 Work 模式操作需要筛选记录（例如分类队列、“查找 30 天内没有活动的 Enterprise 账户”、容量汇总）时，通过此技能组合筛选语法，而不是重新推导。
• airtable-overview — 仅当用户对基本数据模型概念（base / 表 / 记录 / 界面页面）表现出困惑时才加载。大多数用户不需要它；默认加载会浪费令牌。

感知权限的行为

MCP 用户的身份验证决定了用户实际可以打开哪些 URL。请遵循工具调用已确认的访问范围：

• 仅限页面访问的用户（通过 Airtable 的权限模型仅能访问界面）— 仅传递界面页面 URL。用户无法打开的 tbl_* URL 对他们来说是无效链接。
• 表级访问权限 — 表 URL 可以安全使用。
• 工作区级访问权限 — 工作区 URL 可以安全使用。

规则：如果工具调用未确认访问范围，就不要提供该链接。如有疑问，将具体程度降低一级。传递 URL 时，show-airtable-link 技能会执行此规则。

构建计划输出

根据适用的层级，可采用四种输出形式。选择与用户实际需求相符的形式——不要过度构建（用户只说_“跟踪我的交易”，就不要创建自定义合作伙伴门户），也不要构建不足（用户要求“品牌化的合作伙伴注册页面”_，就不要只列出 UI 操作步骤）。

在列出下方任何 Configure in Airtable 或 Configure Portal 区块中的项目之前，请检查 mcp.airtable.com/mcp 上的实时 MCP，确认当前支持情况——如果 MCP 现在可以创建你原本准备交由用户操作的界面（视图、Interface 页面、Automation、Form 等），请改用 MCP 路径。MCP 的能力边界正在快速变化；今天需要交由用户操作的界面，明天可能就能由 MCP 驱动。

纯 Airtable（最常见——用户希望使用原生体验）：

✅ Built (via MCP):
  - [Base name] with [N] tables, [N] fields, linked records, [N] seed records
  - View in Airtable: [base link]

🎨 Configure in Airtable:
  - [Specific Kanban / calendar / gallery view, e.g. "Kanban on Opportunities grouped by Stage"] — [click here]
  - [Specific Interface page for the right stakeholder audience, e.g. "Forecast dashboard for sales leadership"] — [click here]
  - [Specific form / automation, e.g. "Form for inbound lead intake" or "Round-robin lead assignment automation"] — [click here]

Airtable + Portal（用户选择此路径时）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🌐 Configure Airtable Portal:
  - Enable Portal on the [base] — [click here]
  - Branded sign-in page (logo + background — Business/Enterprise) — [click here]
  - Share the [partner-facing Interface] to portal guests at [permission level] — [click here]

🎨 Configure in Airtable:
  - [Admin Interface page for sales-team triage of incoming portal activity] — [click here]
  - [Automation, e.g. "Slack notification when portal guest submits a form"] — [click here]

Airtable + 自定义 Vercel 应用（用户选择此路径时）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🛠️ Custom app:
  - [Next.js app at vercel-deploy-url]
  - Reads / writes [tables] via Airtable REST API
  - PAT scoped to [scopes]
  - Source: [github-repo-link]

🎨 Configure in Airtable:
  - [Admin interface page for sales-team triage] — [click here]
  - [Automation tying app to base events] — [click here]

Airtable 扩展 Salesforce / HubSpot（规模化场景中的主流模式）：

✅ Built (via MCP):
  - [Base name] with [N] tables for what the CRM doesn't model — Deal Desk, Reference DB, etc.
  - Synced from [Salesforce/HubSpot]: Accounts, Contacts, Opportunities (read-only via native sync)
  - View in Airtable: [base link]

🔄 Configure CRM sync (see references/integrations.md for current mechanics):
  - Native sync from [Salesforce/HubSpot] — [setup wizard]
  - Write-back path (Salesforce Automation Actions for SFDC; REST API for HubSpot) for [specific writeback fields]

🎨 Configure in Airtable:
  - [Specific Interface page for Deal Desk / sales-team triage] — [click here]
  - [Automation for stage-change push-back to the CRM] — [click here]

选择影响最大的 1–3 个 UI 操作交接；不要罗列所有可能的视图。执行时查询当前同步限制、计划层级限制和支持的对象——各工具对应的框架（原生同步、Automation Actions、适用于超大型数据集的 HyperDB 同步、REST API、MCP）请参见 references/integrations.md。

反模式（不要默认采用的做法）

这些是反复出现的失败模式——默认采用数据并不支持的假设。

• 不要默认采用科技 SaaS 的 GTM 框架。 这一类别的行业多样性占主导地位。房地产、抵押贷款、保险、资本市场、医疗相关行业、公共部门、非营利组织、教育、人才 / 媒体等领域都在 Airtable 中运行销售运营。默认的「销售运营客户」是 SMB 或中端市场的非科技客户，而不是采用 Salesloft+Gong+Outreach 技术栈的科技初创公司。先广泛了解情况，再做假设。
• 不要假设用户想要替换 Salesforce。 已部署的配置中，大多数对 Salesforce 的提及都是扩展而非替换。提到 CRM 时，默认考虑扩展。替换对于小型 / 中型客户和特定行业来说是可行的方案，但要先询问。
• 不要假设现代销售技术栈已就位，但也不要忽视它。 占主导地位的 Airtable 销售运营客户没有采用 Outreach / Salesloft / Apollo / Gong / 6sense / Demandbase / CaptivateIQ / Spiff / Xactly；他们通过 Airtable + Mailchimp / SendGrid + Slack 开展外呼，在 Airtable 中原生跟踪佣金，并在 Airtable 中构建 CPQ 逻辑，而不是购买相关工具。因此，不要自动推荐客户很可能并没有的工具集成。但是，有一批真实且不断壮大的受众，是刻意构建在新技术栈上的 AI 原生初创公司——采用 Clay 风格的数据丰富、AI SDR 副驾驶、Granola / Fathom 对话情报、Agent 化潜在客户开发。对于这些客户，Airtable 的作用不同：它是数据底座，能原生承载 Clay 等价的瀑布式数据丰富、AI 起草的外呼内容和 AI 客户简报（类型化记录 + AI Field Agents + Automations + REST API）。如果用户的措辞体现出 AI 原生倾向（「我们还没有 CRM，」 「基于 Clay / Apollo / Granola / Bardeen 构建，」 「AI 优先的 GTM」），就要调整表述：Airtable 是他们可以在其上构建技术栈的开放层，而不是缺少工具的团队所用的替代方案。参见 references/integrations.md#ai-native-stack-clay-equivalents-ai-sdrs-conversation-intel 了解相关模式。
• 当前 MCP 支持什么就用什么，不支持的功能就交由 UI 处理——并将其视为能力缺口，而非质量选择。 查询实时 MCP（mcp.airtable.com/mcp）以了解当前工具范围，不要依赖此处任何硬编码列表，因为工具范围仍在演进。对于 MCP 目前能创建的界面，使用 MCP 路径——速度更快、结果确定，并由 Agent 驱动。对于 MCP 尚不能创建的界面，通过指向 Airtable UI 的 [click here] 链接交由 UI 处理。无论哪种情况，想自行调整的用户都可以使用 UI 路径；不要把这种交接说成质量上的选择，因为这只是用户点击一下就能跨越的能力边界。
• 不要把 CPQ 作为集成方案来推荐。 客户会在 Airtable 中构建 CPQ——包括定价表、分层公式、DocuSign 发送流程——而不是购买 Salesforce CPQ / DealHub / PandaDoc-as-CPQ。在 Airtable 中帮助构建定价逻辑；不要推荐外部 CPQ 工具。
• 不要推荐佣金工具。 CaptivateIQ / Spiff / Xactly / QuotaPath 在 Airtable 的实际应用中很少出现。人才 / 经纪 / 抵押贷款 / 销售合作伙伴等垂直领域会直接在 Airtable 中跟踪佣金——公式 + 关联记录即可完成。
• 不要低估「为子团队打造轻量级 CRM」这一场景。 一种真实的典型情况是，3–5 人的 GTM 团队在组织的主 CRM 旁构建「轻量版 CRM」/「迷你 CRM」。客户的自我描述包括：「轻量版 CRM」、「迷你 CRM」、「特种服务线 CRM」。不要向他们强推规范的多表架构。
• 不要高估企业规模下替换 Salesforce 的可行性。 大型销售代表团队反复提出要全面替换 Salesforce，但很少真正落地。规模化时更现实的做法是「减少许可证」模式——将 Airtable 作为只读为主的界面，供无法证明按席位购买 CRM 许可证合理性的利益相关方使用。
• 不要承诺 MEDDIC AI 提取具有很高准确率。 录音转写的实际内容往往很杂乱。客户会提出这类需求；实际部署通常只能部分实现 / 需要人工核验。介绍这种模式时要说明：AI 起草 → 人工审核，而非自主运行。
• 不要通过 Airtable Automations 自主运行外呼邮件序列。 投递能力和 CAN-SPAM / CASL 相关影响最终会促使客户转向 Outreach / Salesloft。正确模式是 AI 生成草稿 → 人工审核。
• 不要承诺完整的 PRM 技术栈（合作伙伴冲突解决、由合作伙伴主导且带 MDF 的销售管道编排）。Airtable 能很好地支持合作伙伴 CRM——合作伙伴目录、联合账户规划、交易注册——但大规模合作伙伴冲突解决属于 PRM 供应商的核心业务领域。
• 不要在最大的 GTM 组织中替换 Anaplan 来管理区域和配额。 大规模区域规划需要运筹学级别的重新平衡。小团队在 Airtable 中跟踪配额没有问题；大型组织的区域优化则不适合。
• 除非用户有此需求，否则不要推荐 REST API 方案。 原生 Airtable 能很好地处理大多数销售运营场景。只有当用户需要品牌化体验，且超出 Interfaces / Portals 的表达能力；需要在现有产品中嵌入界面；需要聊天驱动的工作流；或需要多租户模式时，定制应用才是合适方案——对于「帮我搭建销售管道」这类需求，它并非默认选择。
• 不要假设 AI 功能可以使用 Claude 或 OpenAI。 受批准供应商限制的大模型确实存在（仅限 Gemini、部分受监管企业禁用第三方大模型）。在推荐绑定特定供应商的 AI 集成之前，先询问。 不确定该走哪条路时，就提问。问两个范围问题只需十秒；重建错误的结构却要花一小时。