How to use Grok Bot for lead response without letting it make promises.

In a lead-response workflow, Grok Bot is a preparer. It can read inquiries that reach it, classify them against written rules, look up the business's own facts, draft a first reply and a follow-up, and put the draft in front of a person to approve. Its documentation describes no telephone or text messaging, no unattended email sending, no trigger for a web form or a business inbox beyond its own address and webhooks, and no documented CRM capability. Scheduled routines run at most every five minutes.

That shape suits a business whose bottleneck is the time it takes to write a careful first reply, not the time it takes to notice the inquiry. A business that needs an instant automated text to every missed call needs a phone or messaging system for that part, with Grok Bot preparing what comes next.

Each item below was checked against Grok Bot's documentation and Cursor's help pages on the date at the end of this article. Where the documentation is silent, that is recorded as silence, not as a capability.

• CALLS AND TEXTS

  No placing or answering phone calls and no sending or receiving text messages is documented. Voice chat is a live conversation between a user and their own Bot.

• UNATTENDED SENDING

  Email prepared by routines and background work always waits for a person to press Send. The two official sources currently differ on email requested directly in chat, so the design here assumes a person sends.

• CRM

  The documentation describes no CRM capability. Updating a CRM means supervised browser work or a custom integration.

• FORMS AND INBOXES

  No trigger is documented for a web form or for a Gmail or Outlook inbox. A routine can start from email sent to the Bot's own agent address, or from a webhook another system calls.

• INSTANT RESPONSE

  Schedules are at least five minutes apart; event-triggered runs have hourly limits and no documented response time.

An inquiry has to reach the Bot before the Bot can do anything with it. The table lists the documented doorways and what each requires; anything marked custom is integration work, not a product feature.

A good first reply depends on facts the Bot does not have unless someone writes them down: the services offered and not offered, the area covered, the hours, what happens out of hours, the information needed to quote, and the things it must never say. The article on rules for an AI assistant that replies to new inquiries sets out that facts sheet and the intake questions in detail, independent of any tool.

Keep the facts sheet as a document the Bot reads each time, not as something it remembers. The documentation is explicit that memory is not an authoritative source, and prices, hours and service areas change. Record each inquiry in the business's own system of record as well, whether that is a CRM or, to start, a spreadsheet; the Bot's conversation is not a record anybody else can rely on.

Classification is where an AI assistant earns its place: it reads the free-text message nobody filled in properly and works out what it is. Write the categories and the escalation rules as a skill, so every inquiry is sorted the same way. The categories below are an illustration for a home-service business; the exact set should match the business.

• URGENT

  A safety or active-damage situation: gas smell, flooding, no heat in freezing weather. Goes to a person immediately by the business's own phone process; the Bot's job is only to flag it.

• NEW JOB

  A request for work the business does, inside its area.

• QUOTE REQUEST

  Asks for a price; the reply asks for the information needed and never states a price.

• EXISTING CUSTOMER

  Refers to a past or current job; routed to whoever owns that job.

• OUT OF SCOPE

  A service or area the business does not cover; a polite decline is drafted.

• NOT AN INQUIRY

  Vendors, spam and solicitations; listed, not answered.

The drafting skill should produce a short reply that thanks the person, confirms what they asked for, asks the fewest questions that let a person act, and says what happens next and when. It should not quote a price, diagnose a problem, promise a time slot or claim anything the facts sheet does not support. Those are commitments, and commitments belong to a person.

For a routine, the draft is the output. A routine that classifies the morning's inquiries and drafts replies can finish its work while nobody is watching, and the drafts wait for a person to review and send. That fits a documented limit: approvals raised by unattended work expire if nobody answers, on docs.x.ai after about ten minutes and on Cursor's help pages after thirty minutes, and the action does not run. Design for drafts that wait, not approvals that expire.

The person who approves needs to see the inquiry, the category and the draft together, and be able to send, edit or discard in one place. The documentation describes prepared email and Slack messages appearing for review with the recipients and body visible and a Send or Discard choice. Notifications can route to a phone when a Bot needs input, which makes approving between jobs realistic.

Two practices keep this safe. Reply from the business's own address rather than the Bot's agent address, so the customer's answer lands where the business already works; the Gmail app can draft in that mailbox. And do not save an Always allow rule for sending to customers. Allow once keeps every first reply in front of a person, which is the point of the design.

Cursor's help pages describe a Google Calendar app that can read and create events, check free time and respond to invitations. A Bot can therefore propose available slots in a draft, and a person confirms the booking. For follow-up, a daily routine can list inquiries that have not had a reply or a booking after an agreed time and draft a follow-up for each, waiting for approval like everything else.

Follow-up by text or phone brings federal rules into play. Under the FCC's rules, autodialed or prerecorded calls and texts to a mobile phone need the recipient's prior express consent, and marketing ones need prior express written consent; telephone solicitations are limited to between 8 a.m. and 9 p.m. at the recipient's location. Commercial email has its own requirements under the CAN-SPAM Act, including an honored opt-out. Whether a particular follow-up counts as marketing is a legal question for the business and its counsel, not for the Bot; honor any request to stop promptly.

Every classification skill needs an unclear category that sends the inquiry to a person, and every routine needs the documentation's three design habits: a policy for missing or stale data, retries that are safe to repeat, and a stated place to report partial completion. No automatic retry or failure alert is documented for routines, and a run that hits a rate limit is not retried, so somebody should check the run history every day in the first weeks.

Avoid broad triggers. The documentation warns against listeners such as every new message, and Cursor's help pages note that a busy trigger can use a week of usage in a day. Narrow the trigger to the source that carries inquiries, and keep spam out before it reaches the Bot.

The following is a hypothetical arrangement written for this article, not a client's system. A two-truck plumbing company sends its website form to a workflow platform, which records the inquiry in a spreadsheet and calls a Grok Bot routine's webhook. The routine reads the inquiry and the company's facts sheet, classifies it, drafts a reply in the owner's Gmail and reports a one-line summary in its own conversation. Urgent categories are flagged for the owner's phone process, which handles them directly.

Between jobs, the owner opens the drafts, edits where needed and sends. At 16:00 each weekday a second routine lists inquiries without a reply or a booking and drafts follow-ups. Calls and texts stay with the company's phone system. Nothing in the design depends on Grok Bot sending, phoning or updating a CRM by itself, which is what keeps it inside the documentation.

Based on the Grok Bot documentation at docs.x.ai as checked on 26 October 2026. Details attributed to Cursor's help pages come from cursor.com/help/grok-bot, checked the same day. The product changes often; check the linked pages before relying on a specific limit. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. Grok Bot can read, classify and draft first replies and follow-ups; a person approves and sends.
2. No phone calls, texts, unattended sending or CRM capability is documented, and schedules run at most every five minutes.
3. Inquiries reach a Bot through its own email address, a scheduled read of a connected Gmail mailbox, a webhook another system calls, or Slack.
4. Keep the business's facts in a document the Bot reads, and the inquiry in the business's own record.
5. Design routines to leave drafts waiting for review, because unattended approvals expire.
6. Texting and calling leads raises consent rules under the FCC's regulations; leave those decisions to the business and its counsel.