官方 guide《Grok Bot for SDRs》专题（Stefan Markarian）：Cursor 做研究与文案、Grok Bot 做录入与暂存，CLEAR / FLAG 分流

1. 引Research：Cursor 云 agent 用 Hex、Salesforce 和 Gong 搭起账户故事：产品使用、已丢失的商机、过往对话。
2. 引Prospect：找出角色与这个故事相符的人；暖联系人和重新联系优先；只有当其实际职责相符时才对总监级别做冷触达。
3. 引Draft：Cursor 用一套写作与研究 skill，以作者的口吻起草第一次触达；邮件以真实的账户信号开头，不是通用模板。
4. 引Intake：潜在客户可来自管线生成清单、Cursor 的晨间资料包或 ChatGTM 收件箱；Grok Bot 检查每个人是否已在 Nooks 中活跃、在 Amplemarket 中暂停、或挂在 Stage 0 商机下。CLEAR 的联系人可以“未发送”地加入序列；FLAG 的等我决定。
5. 引Finalize：我在 Nooks 里保留（KEEP）并发送；空白的 LinkedIn 请求另外发送。任何东西都不自动发送。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-sdrs

引作者说 Josh 可以在同一批次里让 Contact Man 更新表、让 John Ford 处理 LinkedIn；他只看结果和需要他决定的事。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-sdrs

• 引Cursor 在他开工前已完成一份研究包和一批草稿；Josh 随后对照 Nooks、Amplemarket 和 Salesforce 检查每个联系人，每个人落入两个桶之一：

• 引对每个 CLEAR 联系人，Josh 拿 Cursor 的草稿对照写作规则检查，然后未发送地加入序列。6 人已在别处活跃，Bot 不去动他们；34 人有边缘情况，进入他的 FLAG 复核；1 人完全清晰，他复核后发出；John Ford 处理了空白 LinkedIn 请求。
• 引同一流程决定谁值得触达：把产品席位数与软件工程组织规模做对比；足迹够强时，从 Golden List 里瞄准总监及以上，否则做经理及以上。“CLEAR 的继续走，FLAG 的停下。”
• 引他只把时间花在边缘案例上（比如 Amplemarket 里暂停的联系人、Salesforce 里的早期商机、两封几乎相同的邮件），而不是在工具之间复制干净的数据。
• 引Bot 也修他平时会拖延的积压：有一次 24 个联系人的邮件在错误的序列里；Josh 完成现有序列步骤，把工程类职称移到“只发邮件”和“只打电话”的设置，并把第一批电话排在第二天下午；草稿和最终批准仍归他，但“24 个联系人一次清理完，跟进工作没有丢”。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-sdrs

1. 引Never auto-send：Bot 可以研究、起草、建记录、暂存工作；我复核并发送。
2. 引Warm history beats a cold template：如果 Gong 显示有过真实的先前对话，邮件从那里开始。
3. 引Footprint beats title：Hex 使用情况决定账户是否“配得上”总监级外联；光有高级头衔不够。
4. 引LinkedIn requests stay blank：如果 Bot 无法验证个人主页 URL，就标记联系人，而不是猜。
5. 引Repeated feedback becomes a rule：写作风格、研究流程、序列逻辑、邮件格式都存在 Cursor 与 Grok Bot 共用的 skill 里；同一个问题出现两次就更新指令。

引结论：Cursor 管研究和写作；Grok Bot 查系统、建记录、入序列、更新表、处理它们之间的浏览器工作；两者都不取代重要的决定——他仍然决定是否保留 FLAG 联系人、有真实 Gong 历史时怎么重新联系、两个相近联系人是否其实重复。给 SDR 的建议：连已有工具，把研究和草稿放在 Cursor，让一个 Bot 拥有晨间流程，最终发送留给自己；让它过夜跑，早上从“复核清单”而不是空聊天开始。

来源

• 官方 guide：https://x.ai/bot/guides/grok-bot-for-sdrs