How to run customer support with Grok Bot
Shayan, Founder17 min read
Running customer support with Grok Bot works best when you treat the Bot like a new support hire on their first week. Have it sweep your inbox on a schedule, check your docs, and save draft replies as internal notes so you can read them before anything goes out to a customer.
When you first get an always-on agent with its own cloud computer, it's tempting to connect your help desk, tell it to clear the queue, and close your laptop. Every team I looked at that actually likes their Grok Bot setup started the opposite way. They kept the Bot in draft-only mode at first, and they put anything involving money or customer replies behind hard approval rules. Simon Lackowski at xAI summed up the rule he uses for his own support Bot:
Never auto-send... Every message a customer reads, I read first.
The people who got burned skipped that step or didn't pay attention to how scheduled routines eat through usage. One developer asked a Bot to read a single tweet and watched it run a write command instead, publishing a post straight from their account. Another turned on on-demand billing, left a Bot working unattended, and came back seven hours later to a $1,500 overage bill.
If you dig through the docs and forum threads while setting yours up, you'll see three names used for the same platform: xAI builds Grok Bot and signs its pages as SpaceXSI, the Bots themselves run on Cursor's cloud infrastructure, and Cursor staff answer the forum threads. Here is how to wire a Bot into your support inbox, write instructions it won't ignore, and put the right guardrails around approvals and usage.
What Grok Bot is
A Grok Bot is a persistent AI teammate with its own chat thread, working memory that builds up over time, and a dedicated cloud computer with a browser, terminal, and file system. Because the Bot lives in the cloud rather than in a local terminal tab, its scheduled jobs keep running after you close your laptop. There's no complex settings screen when you spin up a personal Bot. You create one, explain its job in plain English in chat, and grant access to tools as it asks for them.
One architectural detail matters before you hand a Bot customer conversations or production keys: every Bot on your account shares the same cloud computer. Creating a Support Bot and an Engineering Bot gives you separate chat threads with separate jobs, not separate virtual machines. After running thirteen Bots for ten days, Zack Proser at WorkOS pointed out that Bot roles organize who owns a task, but they don't isolate files, active sessions, or credentials on the underlying machine. Never treat separate Bots on the same account as a security boundary.
Grok Bot is included with paid Cursor plans, Cursor Teams, and X or SuperGrok subscriptions starting at Premium for $30 a month, Super at $100, and Ultra at $200, as well as Teams and Enterprise seats. The $8 Plus plan doesn't include it. Instead of charging you per ticket resolved, your Bots draw from the same weekly usage pool you use in Cursor and the Grok apps, which is why your routine schedule matters much more than the base subscription price.
The first job: sweep the inbox and draft
Start with a Bot that only reads and drafts. On a fixed schedule, it checks your support inbox for new or updated conversations, looks up the answers in your documentation, ranks what came in, and leaves a private draft note for you to review.
You don't need webhooks or a custom script to set up the timer. You just ask the Bot in chat to check your inbox on a schedule, and Grok Bot saves that request as a routine. Routines can fire on a clock or when an event happens, like an incoming Slack message, an email, or a webhook call. When you create a new scheduled routine, it waits for its next scheduled slot rather than running immediately.
Be careful with how often that schedule fires. A routine set to run every few minutes wakes the Bot roughly a hundred times a day, and each run loads context and calls your tools. Forum users on the $200 Ultra plan have emptied an entire week's usage pool in three days doing that, and attaching a trigger to a busy Slack channel drains usage just as fast. Treat hourly sweeps as the top of the safe range, not the default. ChatPRD's Claire Vo runs her support Bot on an hourly sweep across Intercom and email:
I migrated our ChatPRD customer support agent, Holly Helpdesk, over to Grok Bot... In the past week, I've had multiple customers ask where they can leave a review for our exceptional support.
For most software teams, sweeping the inbox twice a day is a much safer place to start. Lackowski's inbox Bot checks support email twice a day, tags each conversation, ranks priority from P0 down to P4, drafts a reply in his voice, logs feature requests, and escalates P0 bugs right away.
Paste this routine prompt into your Bot's chat to set up a twice-daily sweep. It tells the Bot to save drafts as internal notes inside your support tool rather than posting draft cards in chat, which prevents your drafts from expiring before you read them.
Every weekday at 9:00 AM and 2:00 PM, check our support inbox for customer conversations that changed since your last completed run. For each one, draft a reply from our docs and save it as an internal note on the conversation, then assign the conversation to me. Don't send anything to a customer. If nothing needs me, don't post a summary.Connect Grok Bot to your support tool
A Bot can reach your support queue in one of three ways: through a built-in OAuth connector, by signing into your help desk in its cloud browser, or through a remote MCP server.
Whenever a built-in connector exists under Connect apps in the sidebar, use that first. Zoho Desk and Intercom both have first-party connectors, and Gmail and Outlook cover email queues. With a connector, OAuth tokens stay managed on Cursor's side so the Bot can call the tool's API without holding your login credentials, and structured tool calls are much more reliable than having a Bot click around a web interface.
Help desks like Zendesk, Help Scout, Freshdesk, and Front don't have native connectors yet, so the Bot works those queues by signing into the web app in its browser. If you go that route, save the login in Grok Bot's Vault or a connected 1Password account so Vault fills the password field on the page without exposing the secret to the model. Never paste a password, a one-time login code, or a raw API key into ordinary chat, a shell command, or a plaintext file on the Bot's computer.
The third option is connecting a remote MCP server over HTTPS, which is how UserJot connects at https://api.userjot.com/v1/mcp. Because your Bot runs on Cursor's cloud computer rather than your laptop, it can't reach a localhost server, so the MCP endpoint has to be a public HTTPS URL.
There are two clean ways to give your Bot a UserJot API token without ever pasting the key into chat:
- Save the token in your Bot's Secrets. In UserJot, create an API token under
SettingsandAPI Tokens, then store it in your Bot's Secrets asUSERJOT_API_TOKEN. Tell the Bot to use the UserJot MCP server athttps://api.userjot.com/v1/mcpwith that secret. Because the Bot has a terminal on its cloud computer, it can call the MCP server directly using the secret environment variable, and the model never sees the raw token value in the conversation. - Add it as a custom plugin on a Team Bot. If you're on a Cursor Teams plan, you can publish the Bot to your team, click
Add pluginsandAdd custom, and enter the MCP server URL along with the secret values it needs right in the plugin configuration.
Write the Bot's instructions
A good support prompt does three jobs: it locks down which sources the Bot is allowed to answer from, it forbids guessing when the docs don't cover a question, and it lists the situations that must be handed straight to a human without drafting a customer reply.
The rule against guessing is the one that costs real money when teams leave it out. When Air Canada's support chatbot invented a bereavement refund rule that contradicted the airline's actual policy, Air Canada argued that the bot was a separate legal entity responsible for its own words. Tribunal member Christopher Rivers rejected that defense and ordered the airline to pay $812:
It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot.
Once a reply goes out from your support inbox, those are your company's words. If an answer isn't explicitly written down in your help docs, your refund policy, or your resolved conversations, you want the Bot to tell you in an internal note instead of improvising a policy.
You also want a clear escalation list so the Bot doesn't try to smooth over sensitive account issues. Operators like Liam, who writes as @liam_fallen, instruct their support Bots to immediately escalate refunds, billing changes, account deletions, angry customers, policy exceptions, and anything the Bot doesn't have permission to execute, while staying quiet when a routine run finds nothing new to report.
You can paste this instruction block as your Bot's opening prompt. It assumes your inbox supports internal notes and assignment, though if you run support out of Gmail you can change the escalation step to email you a summary instead.
You work our customer support inbox. Read new conversations, check our docs, and draft replies for me to review.
Sources: only answer from our help docs, our refund policy, and resolved conversations. Never make up an answer just to close a conversation. If the answer isn't in those sources, say so in an internal note and assign the conversation to me.
You may draft replies about documented features, workarounds, and how things work. When a customer asks for a feature, find the matching request on our feedback board and link it in the draft.
Escalate without drafting a reply when a conversation involves a request for a human, an angry customer, a cancellation, a refund, a billing change, a discount, account deletion, security, a bug, an outage, or an exception to our policy. On every escalation, assign the conversation to me with a two-sentence internal note saying what they want and what you'd do.
Never send a reply, an email, or a message to a customer. Drafts only, until I say otherwise.That final line sets the expectation in the prompt, but you can't rely on chat instructions alone to enforce it.
Approvals: what the Bot asks before it acts
Prompt instructions guide how a Bot behaves, but only an Auto-review rule actually stops an action from running. As a Bot's chat history grows over weeks of sweeps, Grok Bot only keeps the newest few thousand characters of standing instructions in active context, which means older rules you typed in chat eventually scroll out of view. If you want a hard guardrail that pauses the Bot every time, configure it under Settings, General, and Bot.
That setting is called Auto-review. It checks each action the Bot is about to take against your Custom Rules, where you can save up to 20 Allow automatically rules and 20 Ask first rules. Whenever an action matches both lists, Ask first wins and pauses the Bot with an approval card. On day one, add two Ask first rules: one for anything that sends a message or email to a customer, and one for anything that touches billing or moves money.
By default, Grok Bot already holds outgoing messages and routine emails as drafts until you click send. There is a setting to disable drafts for a Bot, and you should leave it off.
Even with approval cards enabled, there's a timing quirk with routines that catches people off guard. While an approval card raised inside a chat you started yourself waits until you get back to it, any approval card raised by a scheduled routine or an incoming event expires after 30 minutes. Sending a new message in that chat thread also closes any open card. If your afternoon routine runs at 2:00 PM while you're in a meeting and you check the Bot at 3:00 PM, those chat approval cards have already expired and nothing got saved. Having your routine write its drafts as internal notes inside your support inbox avoids the 30-minute timer completely, because the note sits on the customer thread until you're ready to review it.
Keep refunds behind the same approval gate. Give the Bot your written refund policy so it can check whether a request qualifies, and have it recommend the decision or trigger an approval flow rather than issuing the refund on its own. At ChatPRD, Claire Vo lets her Bot prepare refund requests that send her a notification with an approve button linked to the action in Stripe. If you eventually trust your Bot enough to handle small refunds automatically, enforce a hard dollar limit with an Ask first rule for any refund above $50 rather than relying on a line in the chat prompt.
Letting it reply to customers
When xAI's own support team rolled out Grok Bot across Plain and Linear, they started with internal notes and human approvals before letting the Bot talk directly to customers:
We took a crawl, walk, run approach... connecting it to a few core systems, including Plain for ticketing and Linear for issue tracking. We then had it act as though it owned tickets, while limiting it to internal notes and requiring human approval for every write action.
Because xAI handles thousands of tickets a day, a single day of reviewing every proposed draft gave them enough volume to spot gaps and start opening up direct replies, eventually absorbing a 175% jump in ticket volume without hiring more agents. On a smaller SaaS team, plan on spending a couple of weeks reading drafts before you relax the approval rule on routine questions. Use Lackowski's habit during that review phase: any time you have to give the Bot the same correction twice, save it as a standing instruction or fix the underlying doc page.
Once you let the Bot reply directly on documented questions, give it a strict loop limit. xAI flags any conversation that goes back and forth more than three times so a human can step in. A customer who has had to repeat themselves three times to a bot is about to cancel.
You also need to decide how the Bot introduces itself. Teams that try to pass an AI agent off as a human support rep routinely watch customers cancel the moment they realize they're talking to a bot. When you tell customers upfront that an AI teammate is answering and that they can ask for a human at any time, most people are happy to take the fast answer. Clear disclosure is also required in Europe under Article 50 of the EU AI Act, which took effect on August 2, 2026. While you're still reading and sending every draft yourself, send them under your own name. The day you let the Bot reply unattended, have it sign with its own name and offer a human handoff in the same message.
When the Bot is wrong
Because every Bot on your account shares one cloud computer and one set of connected apps, a mistake isn't limited to a clumsy sentence in a draft. When the developer behind VelvetShark tracked 67 real jobs on a Bot, 40 finished without help, but one failure showed why write access needs a gate: asked to read a single tweet, the Bot ran the write command instead and published a post from his account. Shane Mac at XMTP Labs ran into a similar problem when a finance Bot posted company bank details into a Slack channel and replied that it didn't mean to post anything. An Ask first rule stops a bad action before it runs, and nothing reverses an action once the Bot has already sent it.
Inbound customer email brings a second risk. After one founder shared that his support Bot and engineering Bot had teamed up to fix a bug from a customer email automatically, engineers on Hacker News pointed out the obvious security hole: if anyone on the internet can email your support address about a bug and trigger an agent that edits code, you've opened a direct prompt-injection path from your inbox to your repo. Let your support Bot search issues or pass a reproduction note to an engineering Bot, and keep a human review step between untrusted customer messages and anything that ships code or touches production data.
Batch replies are the third place where a small mistake turns into a big apology. A Bot that misreads one ticket is annoying, while a Bot that sends the wrong answer to 200 customers in ten minutes creates a support crisis of its own. Whenever you want a Bot to follow up on a batch of conversations, make the first prompt strictly read-only: ask it to find every conversation from the last three days asking the same question and show you the list and total count without sending anything. Review the list yourself before you let it draft or send the replies.
Watch the usage meter
Scheduled routines are what drain a seat's weekly usage pool, and turning on on-demand usage removes the ceiling. When one forum user left a Bot running unattended with on-demand billing enabled, it racked up $1,500 in overages in seven hours. There is no per-Bot spend cap today, only a monthly dollar limit on additional usage across your entire subscription. Leave on-demand usage turned off while you're setting up your support routines, and watch how much of your weekly pool a twice-daily sweep actually uses before you ever enable overages.
Keep an eye on uptime as well. Grok Bot shares status.cursor.com with Cursor, and when an outage delays scheduled routines or event triggers, failed runs aren't retried, missed schedule times aren't replayed once service comes back, and there's no missed-run alert yet.
That makes two habits worth keeping. First, always keep customer conversations inside a real support inbox rather than treating the Bot's chat thread as your only queue. Second, phrase your routine prompt so the Bot checks every conversation that changed since its last completed run rather than only checking the last hour. If a morning sweep gets skipped during an incident, the afternoon sweep picks up every thread from the morning without dropping a customer.
Give Grok Bot a support inbox it can work from.
UserJot's live chat and support inbox are free on every plan in beta. Connect a Bot through the MCP server on Starter and Professional.
Running Grok Bot with a UserJot inbox
When you run customer support in UserJot, your Grok Bot connects to your workspace through the MCP server at https://api.userjot.com/v1/mcp, available on the Starter and Professional plans. Create a dedicated API token for the Bot under Settings and API Tokens and save it in your Bot's Secrets as USERJOT_API_TOKEN. Because a token has access to the whole workspace, giving the Bot its own token lets you revoke it on its own at any time. Conversations, our live chat and shared inbox for widget messages and forwarded support email, is currently in beta, opt-in, and free on every plan while in beta.
You can pair Juno, UserJot's built-in support agent, with your Grok Bot in two ways depending on who you want answering first:
- Keep Juno on as the instant first line, and let Grok Bot handle the handoffs. Juno answers routine questions right away from your help docs and the websites you point her at, searches your public feedback board to file a request or add a vote once the customer confirms, and hands the conversation to your team with a summary when she isn't sure or when the customer asks for a person. Your Grok Bot then sweeps the inbox on its routine, picks up the conversations Juno handed off to the team, checks your codebase or internal tools on its cloud computer, and leaves an internal draft note or replies.
- Turn Juno off so your Grok Bot handles every conversation from the start. If you turn Juno off under
Settings,Conversations, andJuno, every new conversation goes straight to your team queue for your Grok Bot to pick up on its schedule, while Juno finishes any conversations she was already handling. Either way, once your Bot or a teammate replies in a thread, Juno stays out of that conversation unless you hand it back to her.
Because UserJot doesn't push new conversations out to Bots over webhooks, your Bot's scheduled routine polls the inbox, reads the thread history and customer details, leaves internal notes, assigns conversations to you, or replies as a named owner or admin once you allow it. And because the same MCP connection reaches your feedback board, roadmap, and changelog, your Bot can also add a customer's vote to a matching feature request and draft changelog posts linked back to the requests you ship. When you mark a request Completed, UserJot automatically emails everyone who posted, voted, or commented on it with an email on file.
Frequently asked questions
Can Grok Bot run customer support on its own?
Yes, it can sweep your inbox on a schedule, look up answers in your docs, and draft or send replies, though you should keep it in draft-only mode at first. Even xAI's own support team limited their Bot to internal notes and required human approval on every write action before letting it reply to customers directly.
How much does Grok Bot cost for customer support?
Grok Bot is included with paid Cursor plans, Cursor Teams, and X or SuperGrok subscriptions starting at Premium for $30 a month, Super at $100, and Ultra at $200, plus Teams and Enterprise seats, while the $8 Plus plan doesn't include it. The real cost to watch is your weekly usage pool, because a routine that fires every few minutes can burn through a week of included usage in a day.
Which help desks connect to Grok Bot?
Zoho Desk, Intercom, Gmail, and Outlook have built-in OAuth connectors under Connect apps. Zendesk, Help Scout, Freshdesk, and Front don't have native connectors yet, so the Bot signs into their web apps in its cloud browser using credentials stored in Vault or 1Password. Support tools with a remote MCP server, including UserJot, connect directly over HTTPS using an API token stored in your Bot's Secrets as USERJOT_API_TOKEN or added as a custom plugin on a Team Bot.
How do I stop Grok Bot from sending replies or refunds without approval?
Turn on Auto-review under Settings, General, and Bot, and add Ask first rules under Custom Rules for sending any message to a customer and for anything that moves money. Standing instructions in chat eventually scroll out of the Bot's active context window as the conversation grows, whereas an Ask first rule pauses the action and raises an approval card every single time.
Why did my Grok Bot approval card expire?
Approval cards raised by a scheduled routine or an incoming event expire after 30 minutes, and sending a new message in that chat thread also closes any open card. Only approval cards raised inside a conversation you started yourself wait indefinitely. That's why your support routine should save its drafts as internal notes inside your support inbox rather than waiting on a chat approval card.
What happens if a Grok Bot routine fails during an outage?
When an incident affects Grok Bot routines, failed runs aren't automatically retried, missed schedule times aren't replayed, and there's no missed-run alert yet. Keep your customer conversations in a real support inbox and write your routine prompt to check every conversation that changed since its last completed run so the next sweep catches anything that came in during the downtime.
