Most sales days still die in the same three places: finding the right people, writing outreach that does not sound like every other sequence, and scrambling for an engineering answer while the buyer is on the line. Updating Salesforce next steps and hunting a quote from a 45-minute webinar sit right behind those.
Grokbot for sales is the Space XAI go-to-market team’s answer to that grind. Christa Letts and Mark Wright treat it as a staff function: a small team of bots, each with one job, each with its own computer running when you are not at the laptop. You give an objective—build pipeline, get a meeting, leave a discovery call with next steps—and the bot goes and does the work.
You will set up specialized bots, connect the systems you already live in, and run a review-before-send loop on email, decks, and CRM. The method is simple: one bot, one job, then delegate full workstreams instead of chatting.
Key takeaways
- Build a team of Grokbot specialists (chief of staff, pipeline, discovery follow-up, customer expert, engineer), not one general chat.
- Connect Salesforce, Slack, Notion, Gmail, Gong, Granola, and the X API before you expect useful work. Grokbot is an orchestration layer over where data already lives.
- Tell each bot who you are, how you work, and what “good” looks like. Memory is the point; onboard them like colleagues.
- Share an objective and let the bot figure out the path. If it hands you links to watch yourself, push it to watch, extract, and draft.
- Personal hooks from X beat generic company news. Train writing style from Gmail, Slack, or X so outreach does not read like a generic model.
- Review email cards and Salesforce updates before anything sends or pushes. Human in the loop on customer-facing work.
- Run routines once or twice a day. A routine every 15 minutes burns tokens and creates noise.
- Use shipped MCPs (Gong, Granola, Salesforce, and others) first. Save computer use for tools without a good MCP.
Who this is for (and who should skip it)
This is for an AE, BDR, founder-led seller, or sales ops lead who already works in Salesforce plus Slack or Notion, and who can get Grokbot connected to those tools. You do not need to write code. You do need to message bots the way you would message a colleague, review drafts, and decide what “done” means for each job.
Skip it if you will not connect your stack, if you want a single chatbot that you prompt all day, or if you plan to auto-send outreach and CRM updates with no review. Token spend is real and highly personal; the speakers gave no list prices, only the advice to use fewer routines and specialized bots. Team rollout is optional: start by building for yourself, then share templates.
Connect the stack Grokbot needs to run sales work
Time to value comes from connections, not from a clever first prompt. Mark’s first instruction to customers is to look at the tools you already use all day and connect them directly in Grokbot. Christa’s working set is Salesforce, Slack, Notion, Gmail, Granola, Gong, the X API, and—for product answers—the codebase, with Cursor available when she wants cloud agents spun up.
Prepare access the same way you log into those apps yourself. The bot uses the tools you can use. It has its own VM, so you do not leave a laptop cracked open for it to keep working overnight.
Use native MCPs when they exist. The speakers said Gong, Granola, Salesforce, and more already shipped. Computer use is the fallback when a sales tool has a weak or missing MCP—not the default.
Good looks like this: when you ask for next steps, account context, or a customer-facing product answer, the bot can pull from calls, mail, Slack, Notion, and CRM without you naming the source every time. Failure looks like a bot that can only chat, or a knowledge mess you try to rebuild in one new database. Neither speaker recommended moving everything into a single store. Meet the company where the knowledge already sits. For them that is Notion, Slack, and Salesforce, with Databricks in the mix when needed. Grokbot sits on top and fetches.
Give each Grokbot one job and onboard it like a teammate
The interface is meant to feel like iMessage: type, send, go. The operating model is not one thread. Create a bot per specialty. Christa customizes them (Olive, her chief of staff, is named after her dog) and treats them the way she would Slack a BDR or an engineer.
Onboarding is not optional. Tell the bot a lot about you and your function at the start. Give it the materials an expert in that job would need. Share bots and templates across the team; that is how Space XAI got moving faster after Christa, a power user, passed templates around.
A chief of staff is the usual starting point. Olive preps Christa for the day and for 9:00 a.m. meetings—useful on a bus when Slack and email are moving and the laptop is not open. It drafts replies as email cards she can edit, send, or discard. Example: a customer asks for a one-pager; the bot drafts it; she changes it or kills it.
The same bot can run a morning inbox scan as a routine. Christa runs routines once or twice a day on purpose. More than that gets noisy and expensive in tokens. Mark likes set-and-forget automations more; he also asks Grokbot for optimization tips when spend climbs. Both agree the chief of staff can orchestrate other bots (pull account data, call a deck specialist). Christa still prefers working in the specialist bots directly because she finds it cheaper and cleaner.
Have one bot with one job. Like this is your focus.
That rule is the whole org chart. Pipeline generation, travel and expense, engineer, customer expert—each is a teammate you hire for a field, not a personality you dump every task on.
Grokbot for sales pipeline: personal hooks, not funding news
Pipeline is the use case both speakers put first. Christa’s PG bot runs a marketplace PG skill against her book in Salesforce. She usually gives it five accounts (you can give it the list, or let it choose; she said you can go as high as 100, but she runs five). It then picks five contacts per run.
The research bar is personal, not corporate. Funding announcements and basic firmographics are what every other seller’s model already used. She wants hooks such as a CTO posting on X about building a software factory, or a CEO posting a product launch. She recommends connecting the X API for that reason: leaders post there, news is recent, and LinkedIn company data, in her view, goes stale.
The bot should also pull intent-style signals she cares about—growth, job openings, whatever you specify—rank who to contact, and watch podcasts and webinars instead of summarizing a title. Before Grokbot, she could not scale listening to a 45-minute webinar for one usable line from a CTO. The bot watches, pulls quotes tied to how you actually help, and drafts messaging in Gmail as cards she edits.
Before any of that mail goes out, she has Grokbot scan Gmail, Slack, or X for writing she is proud of so the voice is hers.
I don’t like the generic LLM type style writing.
Her phrase for fixing that is to “deslop” the copy by teaching the bot her style. She attributes more meetings with executive buyers to understanding what those people have posted, not to volume alone.
Mindset check: the first time she used the platform like a chat box, it returned links for her to watch. She pushed back and told it to watch the webinars and draft the email. Treat bots as colleagues with their own computers. Overnight prospecting on a long list, with drafts waiting in the morning, is the intended pattern. Then add about 20% more work each day—LinkedIn replies, ten more people—so the bot’s scope grows with use.
What good looks like: a sheet of personal hooks and ranked contacts, webinar quotes that map to your offer, drafts in your voice, still unsent until you approve. What failure looks like: “your company raised funding” mail, out-of-date facts, and model-speak.
After the call: Echo, Salesforce next steps, and the customer expert
Echo exists so a discovery call produces next steps and the use cases the customer actually said, not a generic recap. Christa runs discovery, stops Granola, and runs Echo. Echo pulls the Granola transcript and updates the deck. She quoted about two minutes; give yourself that window. She also asks it to translate slides on the fly (Japanese, in her example) for international customers.
Gong is in the same workflow but slower after the call—it can take a couple of minutes to load—so she treats Gong as better for the next meeting or the follow-up send, and Granola as the live path. There is no separate “stream the transcript into the bot during the call” setup in what she showed. Stop the recorder, run Echo, let it pull automatically.
Salesforce next steps are the unloved twin of that process. The bot listens to Granola and Gong, pulls relevant contacts and outcomes from email and Slack as well, and writes next steps in a format she specified: her initials, the date, customer outcomes, next steps. She reviews, then pushes to Salesforce. If you enjoy typing those fields by hand, you are the exception in the room.
For a few strategic accounts, she runs a customer expert on Notion as the account-plan database. After every call it updates the plan: signals, renewals, stakeholders, call history, projects. She pulls usage (example: top 20 power users to talk to before renewal or a new feature). It watches noisy Slack for customer-related items and, when a changelog ships, matches features to requests from a month ago so outreach feels like “we built what you asked for.” The point is more time with customers, less time searching Notion or pinging an engineer for status.
Forecasting was named as a one-click or routine job once systems are connected. The workshop did not walk through the fields or cadence, so do not invent a forecast SOP—wire CRM first, then automate the update the same way you automate next steps.
Answer product questions on the call with an engineer bot
Sales gets engineering questions. The old path is “let me get back to you,” then a Slack to the SE. Christa’s engineer bot is connected to the codebase. Live on a call she asks for a customer-facing answer plus proof from other accounts. Mark said the same pattern has sped up next steps on his deals because the answer happens on the call.
She often pastes into Slack, so the bot already returns paste-ready copy. Good output is steps the customer can follow plus outcomes from named customers (she used Amplitude and Fair on cloud agents). Failure is still parking the question for a human engineer when the bot could have answered from the repo and prior account work.
If you use Cursor, you can tell Grokbot in natural language to spin off cloud agents there, with the Cursor account connected. You do not have to leave Grokbot, restate the spec, and build by hand unless you want to.
Sales use cases at a glance
| Use case | Bot / tool | Input needed | Output | Owner |
|---|---|---|---|---|
| Day prep and inbox | Chief of staff (Olive) | Calendar, email, Slack; 1–2 daily routines | Meeting prep; email cards to edit, send, or discard | AE |
| Pipeline / outbound | PG bot, marketplace PG skill, Salesforce, X API | Book or named accounts; writing samples | Hooks, ranked contacts, webinar quotes, Gmail drafts | AE / BDR |
| Discovery follow-up | Echo, Granola (Gong for after-call) | Stopped recording, existing deck | Updated slides, next steps, optional translation | AE |
| CRM next steps | Grokbot + Granola, Gong, mail, Slack, Salesforce | Your next-step format | Draft updates to review, then push | AE |
| Strategic accounts | Customer expert, Notion, Slack, usage data | Calls, channels, changelog, renewals | Live account plan, power users, feature-request pings | AE |
| Product / SE questions | Engineer bot, codebase; optional Cursor | Live question; customer examples | Paste-ready customer-facing steps and outcomes | AE on the call |
| Forecasting | Grokbot + CRM (routine or one-click) | Connected systems | Forecast moved forward; details not demoed | AE / manager |
Prompts, bot instructions, and workflows
The workshop showed jobs and examples more than a prompt library. Use these as copy-ready starters. Do not skip the review step they used on every customer-facing artifact.
Engineer bot, as Christa asked on a call:
Send me a customer-facing answer on how to set up cloud agents. Also send me a few outcomes that Amplitude and Fair achieved.Reconstructed from the speaker’s description — Echo after Granola:
Pull the Granola transcript from this discovery call. Update the deck with the use cases the customer discussed and the next steps. Keep it ready for me to review.Reconstructed from the speaker’s description — Salesforce next steps:
Listen to my Granola and Gong calls and pull relevant contacts and outcomes from email and Slack. Write Salesforce next steps in this format: my initials, the date, customer outcomes, next steps. Show me the draft to review before pushing to Salesforce.Reconstructed from the speaker’s description — PG run:
From Salesforce, pick five accounts in my book (or use this list). Pick five contacts. Pull personal hooks from X, not basic funding news. Include intent signals I care about (company growth, job openings). Rank who to reach out to. Watch relevant podcasts and webinars, extract quotes that relate to how we help, and draft Gmail outreach in my writing style.Reconstructed from the speaker’s description — voice, overnight, and pushback:
Scan my Gmail, Slack, and X for writing I am proud of and match that voice. Do not use generic LLM style.
Work overnight on this long prospect list. Have the email drafts ready for me in the morning.
Do not give me links to watch. Watch the webinars yourself and draft the email.
Based on this customer webinar with the CEO, draft outreach (or messaging for my CEO) to set up a meeting on their three key objectives and how we can help.Reconstructed from the speaker’s description — customer expert:
After every call, update the Notion account plan: signals, renewal timing, stakeholders, calls, projects, and next steps. Flag Slack items I need to act on. When we ship a changelog, match it to feature requests this customer raised and tell me who to reach out to. Show the top 20 power users so we can get feedback before renewal.Marketplace skills (including the PG skill) can be downloaded and edited. Steal a teammate’s template, customize it, and share yours. New Grokbot instances can ask for role and pre-load templates; advanced teams push a power user’s five sales bots into each AE’s instance on day one.
What “working” looks like (no fake metrics)
The speakers did not give hours saved, dollar cost, or conversion rates. Judge the system the way they did.
Christa said she has booked a lot more meetings with executive buyers because outreach is tied to what those people posted. Mark said the engineer bot speeds deals by answering on the call instead of “I’ll get back to you.” Christa’s qualitative bar for the customer expert is time spent with customers instead of searching Notion or asking an engineer. Overnight PG work is working when drafts are waiting in the morning and you can add another 20% of tasks the same day.
Token use is the cost checkpoint they did discuss. A routine every 15 minutes is the anti-pattern. Christa cuts noise by running routines once or twice a day and staying in specialist bots. Mark runs more chief-of-staff routines, spends more, and asks Grokbot how to optimize. They also noted that first-party models help keep cost down, without numbers.
Handoffs that used to go to an SE, a BDR, or “I’ll update Salesforce later” should show up as bot drafts you accept or reject. If you are still the one watching the webinar and typing next steps, the bot is still in chat mode.
Pitfalls and guardrails
- Chat mindset. Asking for research and accepting a pile of links is the failure mode. Push the bot to watch, extract, and draft.
- One mega-bot. Mixing pipeline, expenses, engineering, and every customer in one brain fights the “one job” rule. Preference applies only to how you slice accounts (one expert vs. a bot per major customer), not to mixing unrelated jobs.
- Generic voice and generic hooks. Untrained copy sounds like a model. Funding-only research sounds like everyone else. Load real writing and connect X.
- Auto-send. Email cards exist so you edit, send, or discard. Salesforce updates exist so you review, then push. Keep a human on anything a customer sees.
- Routine spam. Inbox scans a couple of times a day. Not every 15 minutes.
- Computer use as a habit. Prefer MCPs. Computer use is for gaps in the sales tool stack.
- Wrong recorder for Echo. Granola stop-then-run is the live deck path. Gong’s post-call delay makes it a poor fit if you need slides before you leave the room.
- Knowledge hoarding. Do not wait for a perfect wiki. Orchestrate Notion, Slack, Salesforce, and the warehouse you already have.
- Token surprise. Chief-of-staff orchestration and heavy routines cost more. Ask the bot to optimize if spend bothers you.
Think of them like colleagues who have their own computers.
Colleagues still do not send as you without a glance. Neither should these.
7-day implementation plan
Day 1. Open Grokbot, create a chief of staff, and tell it your role, how you work, and what a good day looks like. Connect the two or three systems you cannot sell without—usually Salesforce plus Slack or Gmail. Run one meeting-prep or inbox-scan request. Review the email card; send nothing you would not have written.
Days 2–3. Stand up the PG bot. Install or copy the marketplace PG skill if you have it. Connect the X API. Paste writing you are proud of from Gmail, Slack, or X. Run five accounts and five contacts—not 100. Edit drafts for voice and hook quality. Reject anything that only cites a funding round.
Days 4–5. Wire Granola and/or Gong. After one discovery call, stop Granola and run Echo on the deck. Write your Salesforce next-step format (initials, date, outcomes, next steps) into the bot and practice review-then-push. If you own a handful of strategic accounts, point a customer expert at Notion and the Slack channels that actually matter.
Days 6–7. Connect the engineer bot to the codebase and test one customer-facing question you usually bounce to an SE. Set routines to once or twice a day, not a tight loop. Queue one overnight PG list. Steal a template from the marketplace or a teammate and customize it. If you are rolling this to a team, share the five bots an AE should have on day one rather than making everyone invent the org chart. Add about 20% more scope to a bot that already completed yesterday’s job.
Get one workstream off your plate
The point is not more chat. It is a staff of specialists that can build pipeline, leave a call with a deck and CRM that match what the buyer said, keep a few strategic accounts straight, and answer product questions while the meeting is still going. Connect the stack, hire each bot for one job, and keep yourself on review. Start with one specialized bot—chief of staff or PG—and the two tools you already live in.
FAQ
Do I need Grokbot if I already use Gong and Salesforce?
Gong and Salesforce stay in the picture. Grokbot sits on top as the orchestration layer: it listens to Gong (and Granola), writes next steps, and pushes to Salesforce after you review. Gong alone does not run overnight outbound or answer codebase questions on a call. If you refuse to connect those systems, Grokbot for sales will not do what the speakers showed.
One specialist bot vs. one bot per major client?
Preference. Christa keeps separate bots for the few strategic customers she runs deeply; she would not assume that for an AE with hundreds of accounts. Mark delegates customer bots plus a chief of staff that directs them, and a separate intent/demo bot. If you are unsure, ask Grokbot whether to split or merge before you spawn another bot.
Grokbot vs. using it like a normal chat interface?
Chat is the old rung on their maturity curve: ask, get a reply. The sales pattern is to delegate a workstream—watch the webinar, draft the mail, update the deck. If the bot returns homework for you, you are still in chat mode. Push it to do the task on its own computer.
MCP vs. computer use: which should I use?
MCPs first. Gong, Granola, Salesforce, and others were called out as shipped. Computer use is for sales tools with no good MCP. Using computer use everywhere is the expensive, brittle path they told you to avoid.
How do I keep Grokbot token usage under control?
Run fewer routines (once or twice a day, never every 15 minutes). Prefer specialist bots over a chief of staff that orchestrates everything, if spend bothers you. Ask Grokbot to optimize the workflows. Spend is personal; Mark’s routine-heavy chief of staff costs more than Christa’s setup. No dollar figures were given.
Can I customize marketplace skills and share them?
Yes. Download sales templates from the Grokbot marketplace, edit them, and share with your team or on X. That steal-and-customize loop is how they want people to start. You can also build your own and pass them to new users so an AE shows up with a prebuilt set.
Granola vs. Gong for Echo decks?
Granola for the live path: stop recording, run Echo, get slide updates in about two minutes. Gong takes a few minutes to load after the call, so use it for later follow-up or the next meeting, not for walking out of the room with a revised deck.
How should a company roll this out to a sales team?
Start with everyone in Grokbot building for themselves. What they are seeing next is role-based templates on first run, and advanced companies cloning a power user’s bot set (five for sales, a different five for marketing) into each new instance. Share from Grokbot; you do not have to stand this up through Cursor unless you want cloud agents in Cursor.