Grok Bot SDR 指南:Cursor 写调研与草稿,Bot 做查重与待发分流

五步拓客流程、五个岗位,以及 CLEAR/FLAG 怎样把机械操作和销售判断分开。

作者:Stefan Markarian10-10 · 约 12 分钟

Grok Bot 的 SDR 指南展示了一套两种工具合作的拓客流程。销售开发代表 Stefan Markarian 让 Cursor 云 Agent 从 Hex、Salesforce 与 Gong 准备账户研究和首封邮件,再让 Grok Bot 检查跨系统状态、创建记录、安排未发送序列并维护表格。

联系人状态清楚时继续准备;遇到暂停、早期商机或身份疑点时进入 FLAG,留给销售判断。邮件由人审阅发送;无附言的 LinkedIn 申请则由专门的 John Ford Bot 按限制处理。


双引擎分工:作者如何搭配 Cursor 与 Grok Bot

许多团队在尝试用大模型改造销售流程时,最容易犯的错误就是「大包大揽」——试图写一段极其冗长的提示词,让一个 AI 助手既查资料、又写文案、还去系统里点按钮发信。结果往往是:要么 AI 在中间某一步出现幻觉而中断,要么就是把格式错误的垃圾邮件直接轰炸给了核心客户。

Stefan 的方案核心在于:彻底切分「重认知与文本合成」与「跨系统浏览器脏活」,分别交给最适合的工具。

┌────────────────────────────────────────────────────────┐
│            夜间后台:Cursor 深度合成引擎                 │
│  Hex (足迹) + Salesforce (商机) + Gong (录音)          │
│                       ↓                                │
│       输出:账户调研档案包 (Research Packet)             │
│            + 注入个人语气风格的破冰首封草稿            │
└──────────────────────────┬─────────────────────────────┘
                           │ 移交数据包
┌──────────────────────────▼─────────────────────────────┐
│          清晨常驻:Grok Bot 专职智能体分流矩阵          │
│                                                        │
│  ┌────────────────┐  分流准入   ┌───────────────────┐  │
│  │   Josh Allen   │ ─────────► │ CLEAR:免打扰预排  │  │
│  │ (幕僚长 Bot)   │  跨系统查重 │ FLAG :人工决策池  │  │
│  └───────┬────────┘            └───────────────────┘  │
│          │ 并行派发                                    │
│   ┌──────┴──────────────┐                              │
│   ▼                     ▼                              │
│ Contact Man (表格守门)  John Ford (领英拓展)          │
└──────────────────────────┬─────────────────────────────┘
                           │ 整理汇总
┌──────────────────────────▼─────────────────────────────┐
│            清晨上班:人类 SDR 掌控最终控制台             │
│  1. 快速审核 1 封无争议的 CLEAR 邮件并点击发送         │
│  2. 集中精力裁决 34 个 FLAG 复杂边缘个案               │
│  3. 邮件由人发送;LinkedIn 空白申请由 John Ford 按规则处理  │
└────────────────────────────────────────────────────────┘

1. Cursor:深度研读与个性化草稿的「离线大脑」

  • 负责环节:调研(Research)、选人(Prospect)、写信(Draft)。
  • 核心优势:依托本地或云端代码编辑器级的工作流,Cursor 具备极强的长上下文整合能力。它通过专门的销售研究技能(Skills),直接深入 Hex 提取产品遥测用量、翻查 Salesforce 历史丢单记录、提炼 Gong 的通话要点,合成一份结构化的「账户调研档案包(Research Packet)」,并在清晨前把第一封破冰信(First-touch)按业务代表的真实口吻写好。
  • 交付物:不是直接发出的邮件,而是带着明确事实证据的高质量半成品草稿。

2. Grok Bot:多系统之间搬砖与准入分流的「常驻工兵」

  • 负责环节:系统准入(Intake)、多平台查重、状态同步与跨工具执行。
  • 核心优势:常驻运行,即使笔记本电脑合盖休眠也在持续工作。它接手 Cursor 产生的内容,代替人类在 Nooks、Amplemarket、Salesforce 和 LinkedIn 之间来回核验。
  • 交付物:将联系人分流为「经核验可暂存预排(未发送)」和「存疑由人工裁决(FLAG)」两类,并同步各系统状态。

SDR 五步业务闭环:从数据碎片到发送确认

在真实拓客场景中,这套系统被严密锚定在标准 SDR 的五步递进链条中:

第一步:调研(Research)——从真实足迹拼出账户全貌

绝不从网上随便搜两句泛泛的新闻就去破冰。Cursor 云端智能体调取三处真实数据源:

  1. Hex 数据足迹:客户公司目前到底有多少工程师正在试用产品?活跃席位是在增长还是停滞?
  2. Salesforce CRM 档案:历史上是否有过沟通?上一次输单(Closed-lost)是因为预算不够、时机不对,还是缺少关键功能?
  3. Gong 通话录音:调出以往会议纪要,提取对方当年原话提到的业务堵点或特定技术选型。

第二步:选人(Prospect)——「足迹重于头衔」的规则

很多人做 Outbound 习惯一上来就搜 VP 或总监(Director)。但该体系执行严格的分级规则:

  • 存量与老熟人第一优先:如果之前在 Gong 里聊过的人还在公司,优先发起重联(Reconnect);
  • 冷启动需看足迹渗透:系统对比产品席位与软件工程团队规模;当产品足迹足够强时,根据 Golden List 触达总监及以上(Director+)且职责匹配的人选;若足迹尚浅,则触达经理及以上(Manager and above)。

第三步:起草(Draft)——开门见山展示业务信号

Cursor 严格遵循写作者的风格技能库(Writing Skills),拒绝套用「希望您周一过得愉快」之类的万能废话。邮件开篇第一句必须引用真实的账户事实——例如:“注意到你们基础设施团队最近在 Hex 上的遥测调用增长明显……”或是“翻看我们去年 11 月在 Gong 里的沟通,当时你们正准备把计算节点迁移到新集群……”。

第四步:准入分流(Intake)——CLEAR 与 FLAG 核心漏斗

这是整套体系最精彩的机制。所有来自线索挖掘库、Cursor 晨间档案或 ChatGTM 收件箱的联系人,必须接受 Grok Bot 的全面系统排查:

  • CLEAR(准入放行):经核验,该联系人未在 Nooks 中处于活跃序列、未在 Amplemarket 中处于暂停状态,且未关联 Salesforce 的 Stage 0 早期商机。通过检查后,Bot 会将草稿填入 Nooks 暂存并编排进序列,状态保持为 Unsent(已就绪但未发送),仅作为预排暂存而非无风险保证。
  • FLAG(等待裁决):对存疑情况予以拦截,等待人工决策。例如联系人在 Amplemarket 中处于暂停状态、在 Salesforce 中关联了 Stage 0 早期商机、或出现两个几乎相同的邮箱等边缘个案,均进入人工待办清单。

第五步:定夺发出(Finalize)——人工审核与发送

SDR 早上打开电脑,面对的是清晰的晨报:

  • 对标记为 CLEAR 的内容,由人类在 Nooks 中做出 KEEP(保留)决定并手动发送;
  • 纯白领英好友申请(不带留言备注)则由专属 Bot(John Ford)单独发出,这是自动化执行的例外;
  • 人类集中精力处理 FLAG 清单中的边缘情况并逐一裁决。

查清状态以后,再决定下一步

Cursor:研究与草稿Grok Bot:跨系统核对SDR:审阅并发邮件

以下比较依据原文的准入方式;不是客户记录,也没有填入未公开的使用量阈值。

CLEAR核查后没有待决定的疑点准备草稿、加入未发送序列人审阅并发送
FLAGAmplemarket 显示 Paused保持暂停,不直接跳过原因人决定怎样继续
FLAG早期商机、相似邮箱或主页不清列出疑点与相关记录人核对归属或身份
跳过已在其他工具活跃跟进避免重复处理该联系人保留原有接触安排

CLEAR:准备并入未发序列,等待人审阅发送。

作者展示的一次晨间批次

6 人已活跃,34 人有疑点,1 人清晰可供审发。这一批次强调需要审查的情况,不能代表通用通过率。

634

LinkedIn 无附言申请由 John Ford 专岗处理,并检查每日上限、待接受量与主页链接;它与邮件的人工发送步骤分开。


专职智能体战队:为什么必须「一 Bot 一职」?

在这套架构中,Stefan 没有制造一个什么都懂的超级 Bot,而是切分出 5 个职责明确的专职小智能体:

智能体代号 业务角色定位 真实输入(Inputs) 执行动作(Actions) 交付成果与交接(Deliverables)
Josh Allen 幕僚长 (Chief of Staff) Cursor 调研包、线索生成名单、Nooks 与 Amplemarket 实时状态 逐一运行 CLEAR/FLAG 准入检查;纠正错误序列;追踪 Demo 预约跟进 生成晨间更新并汇总待办;将 CLEAR 草稿以 Unsent 状态录入 Nooks;向 Contact Man 和 John Ford 协同派工
Contact Man 表格维护员 (Prospecting Sheet) 拓客表格、Josh Allen 的编排状态指令 维护保留名单(keeper list),记录已排入序列的联系人,跟踪已暂存(staged)行 及时更新表格状态,避免对同一个人重复触达
John Ford 领英拓展员 (LinkedIn Requests) 联系人个人主页链接、每日配额计数器 检查每日申请限额与待处理(Pending)请求数;核验 Profile URL 准确性 发送不带附言的领英申请;若链接无法验证则标记 FLAG
SFDC Create CRM 联系人创建员 (Contact Creation) CRM 异常记录与联系人数据 当常规 CRM 路径受阻或复杂时,负责联系人创建 保证 CRM 记录准确录入,不因常规路径异常中断
Sequencer 序列调度员 (Sequence Changes) 序列配置规则、联系人分组信息 当常规 CRM 路径复杂时,处理序列变更与调整 协助理顺序列规则,确保联系人进入匹配的触达轨

多智能体自主协同的边界

这些 Bot 之间可以直接协作,无需人类充当中间传话人:例如 Josh Allen 完成一批联系人的 CLEAR 甄别后,可以在同一批次中要求 Contact Man 更新表格,同时通知 John Ford 处理领英好友申请。

在这套准入流程中,CLEAR 可继续暂存预排,FLAG 等待人工决定;已有活跃接触的联系人保持原状,避免重复触达。CRM 纠错与序列修复则按各岗位职责另行处理。


晨间示例分流:41 个联系人的处理样本

原文以作者最近一个早晨的实际批次为例(该批次合计 41 人,为 6 + 34 + 1 的样本汇总,并非官方披露的总量或普遍通过率):

晨间批次处理清单(本例合计):

  • 本例合计联系人:41 人
  • 已在其他工具活跃(保持原状不处理):6 人
  • 存在边缘情况转入 FLAG 待审:34 人
  • 完全符合条件预排(CLEAR):1 人(由作者审核后发出,John Ford 处理领英空白申请)

这一流程把不同状态交给不同的处理步骤:

  1. 避免重复触达:识别出 6 人已在其他工具处于活跃状态,Bot 保持原状,不再重复打扰;
  2. 边缘个案留给人决策:这 34 个被 FLAG 的联系人均属于边缘情况,包括在 Amplemarket 中处于暂停状态、在 Salesforce 中关联了早期商机、或出现两个几乎相同的邮箱等。系统将这些情况汇总供人类裁决,无需人工逐一跨系统排查;
  3. 批量修正序列配置:例如曾有 24 位联系人的邮件被排入错误序列,Josh Allen 一次性接管并收尾既有步骤,按工程师职位分别归入「仅邮件」或「仅电话」配置,并将首次通话安排在次日下午。由人工把控草稿与最终审批,确保跟进动作不遗漏。

保障业务体质健康的五条规则

在将这套系统沉淀为日常标准作业程序(SOP)的过程中,团队总结出五条不可逾越的规则:

  1. 绝不自动外发(Never auto-send) 智能体可以去查数据、拟草稿、建对象、在 Nooks 里排好序列,但最后的「发送」按钮,必须由人类销售亲手点击。人类的眼睛是防止品牌资产被 AI 幻觉毁坏的最后一道闸门。
  2. 旧交情重于冷模板(Warm history beats a cold template) 只要 Gong 的通话记录中哪怕只有半年前的一次沟通,第一封信就必须围绕那次通话中的真实细节切入,严禁用标准产品的推销模板把老熟人当陌生人洗。
  3. 产品足迹重于头衔级别(Footprint beats title) Hex 上的用量和席位深度,决定了一家企业是否配得上 SDR 投入精力去接触总监甚至 VP。光有一个光鲜的高管头衔,如果底层技术团队连试用都没人试用,贸然直奔高层只会引来反感。
  4. 领英申请一律留白(LinkedIn requests stay blank) 作者将 LinkedIn 申请配置为不附留言;原文没有比较不同留言方式的通过率。John Ford 只发纯粹的好友申请;而且只要个人主页链接存在哪怕一丝歧义,宁可挂起打 FLAG,也绝不靠大模型概率去“猜”某个人是不是目标客户。
  5. 同样的反馈重复两次,立刻沉淀为技能规则(Repeated feedback becomes a rule) 当人类在审核草稿时,连续两次发现 AI 写的段落过于啰嗦,或者某个特定职位的人不该被排进电话轨,不能仅仅口头改掉这封邮件,而是必须立刻把这条限制写入 Cursor 或 Grok Bot 的长效 Prompt/Skill 规则文件中。

实战资产:可直接改写的提示词与规则模板

要将上述思路落入自己的业务环境,你不一定需要一模一样的工具栈(例如在国内,Hex 可以对应为您自己的数据仓库或用户行为分析系统,Salesforce 可以是纷享销客或销售易,Gong 可以是飞书妙记或钉钉闪记,Nooks 可以是自建的呼叫中心或邮件外发系统)。

核心在于提示词中的判定逻辑与边界约束。以下是我们依据原文工作流编写的两套配置示例,原文未公开这两段完整 Prompt。4–5 句话等长度要求属于可调整的编辑建议;SKIP 是这里为“保持原状不处理”设置的说明标签。

资产一:Cursor 调研与首封邮件起草规范(Markdown 格式,可作为 Skill 规则)

# 角色与目标
你是一名服务于企业级技术产品的资深 SDR 研究助手。你的任务是综合客户的产品使用足迹、CRM 历史和历史通话录音,输出结构化的账户背景包,并为 SDR 撰写一封高转化率的破冰首封草稿。

# 输入数据约束
必须读取并引用以下三个事实源,严禁捏造未经证实的数据:
1. [用量足迹]:分析目标客户的实际活跃席位数与渗透趋势;
2. [CRM 历史]:确认是否有历史输单(Closed-lost)原因、已离线联系人或历史竞对讨论;
3. [通话档案]:提取以往通话中对方明确提及的技术痛点、组织架构变更或阻碍议题。
# 触达级别决策规则 (Footprint vs. Title)
- 对比产品使用席位数与软件工程团队规模(按 [团队确认使用量和组织比例] 判定):
- 若产品足迹较浅(未达门槛):
  * 触达目标锁定为经理及以上(Manager and above);
  * 总监级冷触达需另核对实际职责与足迹条件,不能只凭头衔升级。
- 若产品足迹足够强:
  * 从 Golden List 中筛选并触达总监及以上(Director+)且职责匹配的人选。
  * 邮件诉求:从宏观研发效能与商业化安全角度切入。

# 首封邮件撰写规则
1. 严禁开篇废话:禁止使用「希望您一切都好」「打扰了」「冒昧给您写信」等套话;
2. 第一句必须且只能是:基于真实事实的触发点(如 Gong 中的上次遗留问题,或用量脉冲);
3. 全文控制在 4-5 句话以内,语气专业、直接、克制,带有技术同行的探讨口吻;
4. 行动号召(CTA):提出一个具体的低阻力交流建议(如询问某个具体功能体验),不强行推销 Demo。

# 输出格式
- 【账户诊断】:(用量概况 / 历史包袱 / 破冰切入点)
- 【推荐目标】:(姓名 / 职位 / 匹配理由)
- 【邮件草稿】:(主题行 + 正文)

资产二:Grok Bot / 幕僚长跨系统准入与分流规则(CLEAR vs FLAG)

# 角色:早间拓客准入审查官 (Chief of Staff Agent)
你负责守护外呼系统的清洁度与品牌信誉。接收来自上游的联系人名单后,跨各系统进行刚性比对,并将每个联系人归入 CLEAR 或 FLAG。

# 判定流程
对列表中的每一个联系人,按以下两组规则检查:

1. [系统排查]:
   - 检查联系人是否已在 Nooks 中处于活跃状态?若已在活跃接触中,归入 【SKIP】(保持原状,不重复打扰)。
   - 检查联系人是否在 Amplemarket 中处于暂停状态(Paused)?若处于暂停,归入 【FLAG】(暂停状态须停下等待人工决策,严禁归入 SKIP 或自动忽略)。
   - 检查 Salesforce 中该联系人是否关联 Stage 0 早期商机?若存在关联,归入 【FLAG】(交由人工判断)。
   - 检查是否存在两个几乎相同的邮箱等存疑边缘情况,若存在归入 【FLAG】。

2. [领英申请合规性]:
   - 检查当日已发出好友申请是否达到限额(Daily Cap);
   - 检查待处理的 Pending 申请数量;
   - 核验领英 Profile URL。若无法验证,归入 【FLAG】(不猜测,直接拦截等待确认)。

# 执行动作
- 针对 【CLEAR】:
  * 仅表示检查后可暂存,不作无风险保证;
  * 将草稿录入 Nooks 编排进序列,状态严格保持为「Unsent(未发送)」;
  * 由表格维护 Bot 更新表格记录已暂存状态,防止重复处理;
  * John Ford 在限额内核验后发出不带附言的领英好友申请。
- 针对 【FLAG】:
  * 遇到任何疑点或暂停状态一律停止后续动作,严禁自动发信,将联系人及具体情况归档至 SDR 晨间待办。

把 Agent 用进真实工作的启发

这套 SDR 实践对于想要在真实业务场景中落地 Agent 的团队,提供了一个非常清醒的范式:

  • 自动化不是为了替代人类决策,而是为了把人从「打杂」推进到「关键判断」的位置:销售得以从机械繁琐的跨系统搬运中抽身,将精力投入到关键判断中:例如面对有历史沟通记录的客户,应该以怎样的切入点重新建立联系。
  • 把「停下来的权利」留给 Agent:真正工业级的 Agent 系统,评判标准往往不是它跑得有多快、发了多少封信,而是在遇到异常数据、撞单风险、信息模糊时,它能不能敏锐地停下来,举起一面小旗(FLAG),请人类看一眼。

让模型在夜间整合多源数据并起草内容,让常驻智能体在后台处理跨系统核查与流转,最后由人类把握最终发送与关键决策——这构成了复杂业务场景下人机协同的务实分工。

原文提供的模板入口

以上为原文提供的入口。安装后仍需连接自己的账户、资料与工具;本次核查未执行安装或验证登录后的模板状态。

来源
Grok Bot for SDRsStefan Markarian·查看主材料
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。