Most SDR work with AI still looks like a chat window: paste an account, ask for an email, copy it into Gmail, repeat. That loop does not survive a real day—AE calls from yesterday, a product that changed last quarter, a hundred accounts with new job posts, and an inbox that does not rank itself.
Simon, an SDR on SpaceX’s AI go-to-market team, uses Grokbot as a staff, not a chatbot. One chief of staff holds the context. Specialized bots prospect, enrich, sequence, research, and draft. You talk to one bot; the rest talk to each other.
If you set this up in order—chief of staff first, connectors next, voice training, then routines—you can run an end-to-end Grokbot SDR workflow: new prospects in, context applied, drafts waiting in Gmail, and a ranked list of what to do this morning.
Key takeaways
- Treat Grokbot as the next step past copilots: not one task, but an end-to-end SDR job, with bots that hand work to each other.
- Build every other bot through a chief of staff. That bot should be the only one you message day to day.
- Give each bot its own memory. Train it on the work it owns—Gmail for voice, Salesforce and calls for account context, web search for public signals.
- Connect Gmail, Slack, calendar, and Salesforce. For tools with no clean API, show the workflow in the browser and record your screen.
- Run prospecting, enrichment, sequencing, and copy as one system. AE call context from yesterday should change today’s message.
- Weight recent positive replies when you train outbound copy. What worked three months ago is the wrong default.
- Share templates across the SDR team, then add your own tone and workflow on top. Prompt Grokbot to suggest what to keep and what to extend.
- Do not spawn a new bot for every idea. Prefer an existing bot, a routine, or a skill you can update when the ICP moves.
Who this is for (and who should skip it)
This is for SDRs, founder-led outbound, and GTM operators who already live in Gmail and a CRM and will connect those tools. It fits PLG motions especially well: power users, new signups, and product usage can feed the same daily scan. You do not need to write code, but you do need to sit through the messy prompting it takes to make an end-to-end system trustworthy.
Skip it if you only want occasional email drafts, you will not connect Gmail or Salesforce, or you are unwilling to review copy and give blunt feedback while the voice is still wrong. A single chatbot is enough for that job. This setup assumes Grokbot, a willingness to run parallel bots, and enough account volume that a daily or weekly prospecting routine is worth the tokens.
The AI maturity curve for SDRs
Simon maps SDR AI use in three stages. First, you prompt a chatbot: draft this email, clean this copy, research this account. You still paste the result into Gmail yourself.
Next come copilots—AI that can carry out a task. Instead of handing you copy, it hooks to a Gmail MCP or API and can send. That is still one task at a time.
Grokbot, as he uses it, is meant to automate the job: prospecting through outbound as one workflow, with a team of bots that can pull RevOps context, AE context, and account context without you ferrying it between windows. Bots keep context and memory at a per-bot level, so they improve as you work with them—if you actually train them on the right material.
What Grokbot is and why SDRs use it
In the product, bots sit in a list. You message them the way you message teammates. They can also message each other. Simon’s instance is set up so he almost never talks to anyone except the chief of staff; that bot holds the map of who does what and delegates.
The practical reasons he uses it:
- It is as straightforward as iMessage. You talk to bots in natural language.
- Bots are always on. Close the laptop. Prompt from your phone on a coffee walk, or start a long-running task and let it finish without you steering every step.
- It uses the same tools you use. Connectors, MCPs, APIs—and its own VM, so it can log into a browser.
- Hard workflows can be shown, not just described. Sign in, record your screen, walk the tedious path that has no open API.
- Templates are shareable. Import a teammate’s bot, then add your tone and the way you actually work.
You don’t have to walk around with your laptop open anymore.
Sharing is not a nice-to-have. At SpaceX, what works for SDRs now was not working three months ago, and three months before that it was something else. Templates let the team move the new motion across people without each SDR rebuilding from zero.
What’s working for us today was not working three months ago.
Set up a Grokbot SDR team through a chief of staff
The goal of this phase is a staff that can run in parallel without you context-switching across every bot. The failure mode is the opposite: too many bots, you talking to all of them, and no one holding the full picture.
Start with one bot you will actually talk to
Create the chief of staff first. Simon’s is named after him. Then create every other bot through that chief of staff so it knows each bot’s purpose and end goal. When you later ask it to complete a task, it already knows whom to delegate to, and when two bots need to talk, it can make that happen.
Do not skip this because it feels slower. Messaging five bots yourself is how you end up exhausted and dropping context.
Give each parallel function its own bot
Think in parallel work, not in “more bots are better.” Simon puts outbound in one folder and runs one bot per platform. Shakespeare owns email; he does not need a second email bot. He would add another outbound bot only for another channel, or a separate bot when call context needs its own home.
His roster:
- Chief of staff — the only bot he messages; routes work and holds the system.
- Shakespeare — meticulously trained on his email writing.
- Web search — public research, hooked to Exa; delegates to sub-bots when the account list is large.
- Simon soldiers — low-context sub-bots that take slices of a big research job (for example, 200 companies split into groups of 40) and report back to web search in an “army huddle.”
- Customer bot / voice of the customer — meeting context, what closed-won customers cared about, why deals closed-lost.
- PLG bot — Salesforce-tied usage, signups, closed-lost, product usage by team.
- Amplemarket — enrichment: emails, tests so addresses will not bounce and hurt deliverability.
- Company research — hooked to Sumble for tech stack, job postings, and org chart (for example, who leads the SDR team if you are selling into GTM).
- Inbox manager — ranks overnight Slack, new meetings, and external email.
- Sequencer — the prospect list and daily action queue, stored as a CSV Grokbot owns.
Color-code conversations so you can read the system at a glance. In Simon’s setup, orange means the chief of staff is on a research mission; messages to Shakespeare mean copy is in play; green means account research is being split across soldiers. You are not supposed to live inside every thread. You are supposed to see, in one look, what kind of work is running.
What “good” looks like: you send one request to the chief of staff, the right bots talk, and you are not hopping windows to re-explain the account.
Grokbot SDR use cases: prospecting, sequencing, research, and copy
These are the jobs Simon runs day to day. They are one system, not four side projects.
| Use case | Bot / tool | Input needed | Output | Owner |
|---|---|---|---|---|
| ICP and prospecting | Chief of staff, customer bot, Salesforce | Closed-won and stage-one deals, titles, industries | Who actually takes first meetings vs. who signs | SDR; early-stage teams can start here |
| List building and enrichment | Amplemarket, web search, Exa | Target accounts, job posts, funding news | Contacts, emails, bounce checks | Research bots; soldiers at scale |
| Account and PLG research | PLG bot, Sumble, customer bot | Usage, tech stack, org chart, closed-lost reasons | Ranked urgency and message angle | Chief of staff routes |
| Sequencing | Sequencer, Salesforce trigger, Gong/call context | CSV of prospects, AE notes, stage changes | Who to add, who to unsequence, today’s queue | SDR reviews; bot maintains the file |
| Outbound copy | Shakespeare, Gmail | Your sent mail, positive replies, account context | Gmail drafts with draft IDs, optional confidence score | SDR reviews until voice is trusted |
| Daily triage | Chief of staff, inbox manager, calendar | Slack, meetings, external email, prospect rankings | Ordered work and time blocks | SDR executes the block |
Prospecting and ICP
If you are early, have Grokbot reverse-engineer ICP from reality: titles on deals that closed or moved to stage one, the most responsive title, industry, and sub-industry for a first meeting, and how that differs from the economic buyer who signs. Simon’s personal north star is S1s—how many stage-one opportunities he can create—so the system is built backward from that.
On top of ICP, run the full flow: enrichment tools inside Grokbot, plus web search for job postings and funding announcements. Keep an ongoing prospect list. Simon’s lives as a CSV. Routines and automations keep it current so you are not rebuilding the list by hand.
Sequencing with live AE context
The sequencing nuance is multi-threading with yesterday’s call in today’s copy. If the AE spoke to the account and the pain was tool fatigue—too many tools, AI fatigue—that should shape the message the same day. If a Gong recording named a specific person on the AI team who is investigating the problem, that name should get sequenced, not lost in notes nobody actions.
Grokbot can prospect the person, drop them in sequence, and write from that meeting context. A Salesforce trigger runs in parallel: when account status moves (stage zero to stage one), unsequence people you no longer need to outbound. The CSV is, in Simon’s words, a hideous UI. You should barely look at it. It is Grokbot’s brain. Open it when you need to, not as a dashboard.
Account research, including PLG
For PLG, pull internal data: power users, who is actually using the product, what they use it for. Pull external signals on the whole company: fundraising, job postings, and how those should change the pitch. Internally, when a new product launches, have Grokbot retarget the outbound message by person and industry.
Company research via Sumble matters for a product like SpaceX’s: legacy tech stack, pain from similar buyers, job posts as a stack signal, and org chart so you can find the GTM or SDR leader—not just a random contact. Voice of the customer then ties it together. A closed-lost account that lacked a critical function can get reranked when the product now supports that function and recent closed-won deals prove it. Chief of staff should notice that and push the account up the sequence.
Web search hits a scale wall at 100–200 accounts with daily public updates. Simon’s fix is the army: web search splits the list, soldiers run in parallel, results come back to web search so he can spot-check accuracy. Scaling from five soldiers to twenty is easier when those sub-bots stay low-context and take orders from web search rather than from him.
Drafting copy that does not look like a template
Sync email as the starting point, then push past a naive sync. Filter to outbound you sent to external companies on Salesforce accounts where you are the assigned SDR. From that set, keep emails that got positive responses and drop negatives. Put a heavier weight on recent positive replies, and still let older mail teach the human part of how you write. For a company whose offering keeps changing, recent winners are the real style guide.
After the first pass, Simon’s copy still looked templated—same skeleton, swapped names and company IDs. The fix was not another filter. It was a critique loop: ask for example emails, say why each one is bad, and demand it break the standard format.
Not a single one of your emails should look like a template.
Drafts land in Gmail with draft IDs so you review them one by one. You can ask the chief of staff for a confidence score: is this accurate, is it solid, might they reply? Early on, look thoroughly and give feedback. Later, Simon trusts it enough to let it score itself—but that is after training, not instead of it.
Prompts, bot instructions, and workflows
These are reconstructed from Simon’s descriptions of what he actually tells Grokbot. Use them as starting instructions, then keep critiquing output.
Train outbound voice from Gmail (reconstructed from the speaker’s description)
Look specifically at my email copy sent to external or third-party companies that also match Salesforce accounts where I am the assigned SDR.
From that filtered list, only use emails that got positive responses, not negative ones.
Put a heavier weight on emails that recently received positive responses. Draft new copy more like those recent messages, but still pull inspiration from older messaging so you keep the human aspect of how I write.
Do not write emails that look like a template with the name and company swapped.ICP from deals that actually move (reconstructed from the speaker’s description)
For AEs who have closed deals or have deals that moved to stage one, what common title carries those deals through? What is the most responsive title, industry, or sub-industry for taking a first meeting? How does that differ from the economic buyer who signs off?
Reverse-engineer the ICP from that. Optimize for stage-one meetings.Import a teammate template, then add your nuance (reconstructed from the speaker’s description)
Look at this template my colleague shared with me. Given my own workflow, what would be a good addition to build on top of it, or how can I get more value out of it?Score a draft before you send (reconstructed from the speaker’s description)
Give me a score: how confident are you that this email is accurate, that it is solid, and that they might actually reply?Break templated copy (reconstructed from the speaker’s description)
Give me examples of these emails.
For each one I will tell you why it sucks and how to make it better. Break out of standardized formatting. Give a nuanced response in every single email. No two should look like the same template with different names.Fintech (or any vertical) pass-through (reconstructed from the speaker’s description)
This account is in the fintech vertical. Talk to the customer bot: which similar fintech companies closed-won recently, why were they interested, what pain points did they have, and which parts of the product were relevant? Pass that context to Shakespeare and use it in the email for this company.Closed-lost re-engage when the product caught up (reconstructed from the speaker’s description)
This prospect account is a closed-lost opportunity. Get the voice-of-customer context on why. If we now support the function they needed, and recent closed-won deals came in around that, rank this account higher and re-engage on that specific gap.Daily routines that assign the day’s work
The operating goal is to wake up already knowing the work. Simon treats assigned tasks at the start of the day as one of the most useful SDR habits in the setup.
His core routine: 50 new prospects every day, with internal rankings he trained. Five are first-touch priority—someone who contacted sales and never got a reply, or someone who downloaded content that matches live conversations on the account. Those five get actioned immediately. The chief of staff has calendar access, so it can see a free 15 minutes (he uses 9:00 a.m. as the example) and park the five there. The other 45 get a later block (he uses 1:00 p.m., about an hour).
Inbox manager runs a similar ranking on the Slack messages, meeting adds, and external emails waiting in the morning: what to action first, in what order.
On weekdays at 8:00 a.m., every account is scanned for net-new PLG signals: new signups, people who reached out, content downloads. Even a weaker signal is worth acting on while it is warm. Simon points to speed-to-lead as one of the most important habits, and says those daily warm feeds have produced some of his most receptive replies.
Skills sit under the routines for work that should stay flexible. He has a prospecting skill for one-off or mid-day net-new accounts (most of that work otherwise runs on routines). He also turned Grokbot ICP into a skill because the ICP is still being figured out. Skills can be updated as stage-one deals and voice-of-customer notes clarify who actually cares, and the rest of the system can call that skill without a rebuild. Outputs still orient around CSVs: titles, ICP persona, owners, why they fit, then Amplemarket, LinkedIn, location, and the rest of the profile.
What “good” looks like in the morning: five named people to hit now, a calendar block, Gmail drafts already sitting there, and a ranked inbox—not a blank sequence tool and a chatbot tab.
Measurement and business impact
Simon did not give time-saved percentages, win-rate lifts, or a dollars-per-day figure. The checkpoints he actually uses are operational:
- You wake up with ranked work instead of inventing the day.
- AE and Gong context shows up in the same-day sequence instead of dying in notes.
- Stage changes stop outbound that should have stopped.
- Daily PLG and inbound signals get touched while they are still warm.
- Copy starts generic after a Gmail sync; it is working when examples no longer look like mail merge.
- You can ask for a confidence score on a draft and treat that as a review aid, not a substitute for early feedback.
On tokens and cost, he would not quote a number. Usage depends on how many Gong calls you pull, how much context sits in a Databricks instance, how many prospects need fresh enrichment versus already live in Salesforce, and the scale you run. Fifty prospects a day may be too much. He suggested trying a weekly batch—250 on Monday, worked through the week—if daily volume is not practical. The way to find out is to prompt Grokbot about current token use and ask it how to slim the workflow.
Pitfalls and guardrails
Stopping at one task. Prompting back and forth, or letting Grokbot send a single email, is the easy version. The value he is pushing is the full path: prospect, enrich, apply context, outbound. That costs pain up front.
Talking to every bot. If you are messaging more bots than before, you have not offloaded work. You have added context switching. Route through the chief of staff.
Bot sprawl. New bots are fun. An army that duplicates jobs is chaotic and does more harm than good. Ask why the existing email bot cannot also manage the inbox, or why this should not be a routine that bot already runs. Build through the chief of staff so you feel the overlap.
Trusting copy too early. First Gmail syncs produce sameness. Stay in the example-and-critique loop until messages are actually different. Keep a human on Gmail drafts while you train. Confidence scores come after that, not before.
Living in the CSV. If you are staring at the sequencer file all day, you are using it as a UI. It is supposed to be the bot’s tracking layer.
Soldiers without a huddle. Parallel sub-bots need a place to return work (web search, in his case) so you can check that each slice is accurate before it hits your day.
Stale messaging. If you do not overweight recent positive replies, you will keep writing like last quarter’s product.
A human stays in the loop on: reviewing drafts (especially at first), checking soldier output when you scale research, deciding that a new bot is justified, and choosing daily vs. weekly volume when tokens get painful.
7-day implementation plan
Day 1. Create only the chief of staff. Connect Slack, Gmail, and calendar. Decide that this bot is the only one you will message. Describe your real SDR day to it at a high level and ask what should be a bot vs. a routine. Do not create the army yet.
Days 2–3. Through the chief of staff, add Shakespeare (or your email bot) and the customer / voice-of-the-customer bot. Run the Gmail filters: assigned Salesforce accounts, external outbound, positive replies, heavier weight on recent wins. Pull example emails and critique them until they stop looking templated. Add Salesforce if you have it.
Days 4–5. Stand up the prospect CSV and sequencer. Hook enrichment (Amplemarket in Simon’s stack) and bounce checks. Set the morning routine: a small first-priority set plus a later block for the rest, sized to your world—not automatically 50 if that is not practical. Add inbox ranking. If you are PLG, add the weekday signal scan. Add the Salesforce stage-change trigger so you unsequence when a deal moves.
Days 6–7. Add company research (Sumble, in his stack) and web search (Exa, in his stack) only if public signals and org/tech stack actually change your messaging. If account count makes sequential search too slow, add low-context soldiers and a huddle reporting to web search—not to you. Save ICP and one-off prospecting as skills you can edit. Import a teammate template if one exists; ask Grokbot what to layer on. Color-code threads so research, copy, and delegated research are obvious. Then prune: if two bots do the same job, delete one.
Go end to end, then keep iterating
The point of a Grokbot SDR workflow is not more chat windows. It is a staff that can take an account from signal to ranked follow-up in your voice, while you protect the hours that still need a human. Build it through one chief of staff, train the copy like you would train a new teammate, and share the templates so the motion survives the next product change.
Watch the walkthrough for the color-coded team, the army huddle, and the sequencer CSV in action.
FAQ
What is Grokbot vs. a chatbot or a copilot for SDR work?
A chatbot is back-and-forth prompting: you still copy the email into Gmail. A copilot can complete a task, including sending via a Gmail MCP or API. Simon treats Grokbot as the next step: bots with per-bot memory that run an end-to-end workflow and talk to each other, so prospecting, context, and outbound are one job instead of a pile of tasks.
Do I need a separate Grokbot for every SDR task?
No. Simon’s rule is parallel work, not bot count. One bot per platform is enough for outbound; do not create a second email bot. Question why the email bot cannot also run inbox ranking, or why the work is not a routine. He has had too many bots at times and says it gets chaotic and does more harm than good.
Should I talk to every bot or only a chief of staff?
Only the chief of staff, in his setup. Create the other bots through it so it knows each bot’s purpose. You avoid context switching; it delegates, including making bots talk to each other. Group chats still have a place for sub-bots—his soldiers report to web search so he can inspect outputs and scale headcount without routing every trooper through himself.
How do I train Grokbot on my outbound voice?
Sync Gmail, then constrain the training set: external mail on Salesforce accounts where you are the assigned SDR, only positive replies, heavier weight on recent ones, older mail only for the human texture. Then ask for examples and critique them. A raw sync will still produce templates with the names swapped.
Do I need Salesforce, Amplemarket, Sumble, and Gong to start?
You need Grokbot and, at minimum, Gmail if copy is the first win. Simon’s full system also uses Slack, calendar, Salesforce (including stage triggers and PLG usage), Amplemarket for enrichment and bounce checks, Sumble for tech stack, jobs, and org chart, Exa for web search, and Gong or call recordings for AE context. Start with chief of staff plus Gmail; add connectors when that data would change ranking or messaging.
How many prospects should a daily Grokbot routine produce?
Simon runs 50 a day—five immediate, 45 later—with calendar blocks. That is his preference, not a benchmark. Token use depends on call volume, warehouse context, and how many contacts are already in Salesforce. If 50 is too heavy, he suggests a weekly run (he used 250 on Monday) and asking Grokbot to read your usage and slim the workflow.
Why record your screen if Grokbot already has connectors?
Connectors cover Gmail, Slack, APIs, and MCPs. A lot of SDR work still lives in tools with no clean automation path. Grokbot owns a VM and can use the browser. You sign in, record the exact clicks, and give it the tedious workflow you cannot explain well in a prompt. That is what made Simon willing to let it run end to end.
How do I get a working setup fast if I do not already think in bot teams?
Do not start by inventing an org chart of bots. Talk to Grokbot about your actual workflow at a high level and let it help you split what should be a new bot, what should stay in one bot, and what should be a routine. Create the chief of staff first, then only add bots for work that must run in parallel.