Sooner or later every client asks for "the AI bot." They saw a demo, a competitor has one, and they want leads answered at 11 at night. In GoHighLevel the request is easy to satisfy. You can have a Conversation AI bot replying to real contacts inside an hour.

That is the problem. The part that takes an hour is the prompt, and the prompt is not what decides whether this goes well. What decides it is everything around the prompt: which channels the bot answers, what it is allowed to know, how many messages it can send, when it hands a conversation to a person, and which of the client's existing workflows are already texting the same contact.

This is the order I configure those things in, for a client sub-account, before the bot is ever allowed to send on its own. Feature names below are taken from HighLevel's current help center. Where a default matters, check the live settings panel rather than any article, including this one.

The three switches HighLevel gives you

Every bot has a status, and the status is the whole safety boundary. HighLevel's Conversation AI overview defines three. Off: Conversation AI does not respond. Suggestive: it drafts reply messages for incoming conversations but does not send them, so a team member reviews and sends each one. Auto-Pilot: it replies automatically based on the bot's training, settings, goals and instructions.

The setup guide adds two details worth knowing. New bots may be set to Off by default, so a bot that "is not working" is sometimes just a bot nobody switched on. And there are three ways to build one from AI Agents, Conversation AI, Create Bot: a Guided Form for simple lead capture, booking or Q&A, a Prompt Based bot for people who want to write detailed instructions, and a Flow Based builder for branching, multi-step conversations.

1. Give the bot one job

The most common failure I see is a bot asked to do everything: answer pricing questions, qualify, book, reschedule, handle complaints and chat about the weather. A bot with five jobs is impossible to test, because you cannot write down what "correct" looks like.

Pick one. For most client accounts it is either "answer common questions and capture contact details" or "get a qualified lead onto the calendar." The Guided Form literally asks you to choose between General Q&A and Appointment Booking, which is a useful nudge. If the client needs both, that is an argument for two bots with a transfer between them, not one bot with a longer prompt.

Write the job down in one sentence. It becomes the test you run before every status change.

2. Channels and the primary bot

A bot only answers on the channels assigned to it. HighLevel lists SMS, Email, Facebook, Instagram, WhatsApp, the chat widget and live chat among the options. Assign only the ones the job needs. A booking bot that suddenly starts answering Instagram comments on a post about a staff holiday is a channel mistake, not a prompt mistake.

Then decide which bot is primary. The setup guide describes the primary bot as the one that handles general inbound messages on its selected channels. A non-primary bot is reached through a workflow or another routing method. This matters most on email. HighLevel's email channel article says that for the bot to answer general inbound email it must be the primary bot, have Email assigned as a channel, be set to Auto-Pilot, and have an active connected inbox and From Address. If you were planning to run email in Suggestive mode for a while, plan on reviewing those drafts some other way.

3. A small knowledge base, not the whole website

The instinct is to point the crawler at the client's homepage and let it read everything. HighLevel's own bot training guide says not to. It recommends the smallest set of clear, relevant sources that covers the questions the bot should answer, and says to exclude outdated, duplicated, navigation-only, legal boilerplate and unrelated pages because they can weaken retrieval quality.

For a typical service business that means the services page, hours and location, booking and cancellation policies, and a short list of approved FAQ answers written by you and signed off by the client. Old promotions are the trap: a crawled page about last spring's offer is still quotable.

The same guide makes a distinction that is worth building your testing around. The Knowledge Base Retrieval Tester checks whether source content can be found. Bot testing checks the whole conversation, including instructions, goals, actions and response behavior. A bot can retrieve the right paragraph and still answer badly, so you need both. In the refreshed interface the centralized knowledge base lives under AI Agents, Knowledge Base, and web sources can be set to re-crawl daily, weekly or monthly. A client who edits their site is then editing the bot.

For a clinic client, one more line belongs in the instructions: the bot does not give clinical advice and routes those questions to staff. That is a scope decision you make, not something the platform makes for you.

4. Limits, delays and sleep

These are the settings that decide how much damage a confused bot can do in one thread. HighLevel's advanced settings article covers them.

  • Maximum messages per conversation. Any value from 1 to 100, with 100 as the default for new bots. Only bot-generated messages count. Human replies, workflow messages and the contact's own messages do not.
  • Sleep. The bot goes to sleep immediately after its final allowed message. Marking the conversation as Read resets the counter and wakes it, and a workflow can do the same with the Update Conversation AI Bot and Status action.
  • Response delay. A minimum delay, with HighLevel suggesting 2 to 5 seconds to mimic reading time, and a maximum delay so the contact is not left waiting.
  • Auto-escalation. Assigns the conversation to a human after the bot hits its limit or detects frustration.

A default of 100 bot messages in one conversation is generous for a lead-capture bot whose job should be done in a handful of exchanges. I set it low for a new client bot and raise it once I have read real transcripts. Note the side effect of the Read rule, too: a team member who habitually marks conversations read is also habitually waking sleeping bots.

There is also a per-contact control. HighLevel's bot status article describes Active, Inactive, and Sleep or Snooze with an optional reactivation time, set from the status icon in the message composer. Show the client's front desk where that icon is on day one. It takes the bot out of one awkward conversation without touching the account.

5. Handover and stop rules

HighLevel's bot goals overview lists the actions a bot can take: Appointment Booking, Trigger Workflow, Contact Info (collect missing details into contact fields), Human Handover, Stop Bot, Auto Followup and Transfer Bot. It also notes that available actions may vary by account and release status, so confirm what your account actually shows.

Before the bot goes anywhere near Auto-Pilot, define in writing:

  • When it hands over. Complaints, billing disputes, anything clinical, any request for a named person, and any question it cannot answer from the knowledge base.
  • Who it hands over to. A real user who exists in this sub-account and who will see the notification. If the account was inherited, check that, because users do not transfer with a sub-account.
  • When it stops. The contact books, opts out, or says they are already a patient or customer and just need the front desk.

If you plan to use Transfer Bot, HighLevel's transfer action article says both bots must be active on the same channel and both must be in Auto-Pilot. That rules out the comfortable plan of leaving the second bot in Suggestive while you watch it.

6. The workflows already talking to this contact

This is the step almost everyone skips, and it is the one that produces the embarrassing screenshot. The client's sub-account already has workflows that text and email new leads. Turn on a bot that also answers new leads, and the contact gets a workflow message and a bot message within the same minute, saying slightly different things.

Before you enable the bot, list the published workflows that send to the same audience on the same channel, and decide which one owns the first reply. Usually that means removing or delaying the first SMS in the nurture workflow, or using the bot's Trigger Workflow action so the bot hands off to the workflow rather than racing it. Read the workflow settings while you are there, because Allow Re-entry and Stop on Response change how a workflow behaves once a contact starts replying to a bot. We walked through reading those settings in the 30-minute health check for an inherited sub-account.

Booking bots have one more dependency. The Appointment Booking action points at a calendar, and that calendar points at team members. If the calendar or the assigned user is wrong, the bot will cheerfully offer times that nobody owns. It is the silent failure covered in how invalid IDs kill GHL automations.

7. Snapshots and billing

If you deploy bots through a snapshot, read HighLevel's bot snapshot article. Bot settings, prompts, actions, crawler URLs and custom bot responses come across. The imported bot only becomes primary if the destination has no primary bot already, and HighLevel says to always test the imported bot in the destination sub-account. The calendar and workflows its actions reference are separate assets, so they are exactly the references to check after a load. Our longer piece on why snapshots break covers that pattern.

Then settle the money before the client sees a bill. HighLevel's AI tools article describes plans with defined allowances, an unlimited plan subject to fair use, and pay-per-use metering, and it warns that messaging charges can be separate from AI plan coverage. Check which applies to this sub-account and how you rebill it before you quote anything.

8. The rollout: Off, then Suggestive, then Auto-Pilot

With the above in place, the rollout is boring on purpose.

  • Off, with the test panel. HighLevel says to test the bot from the setup panel before setting it live. Run the one-sentence job, the questions the client gets every week, a question the knowledge base cannot answer, a booking, a request for a human, and an opt-out. Turn on the email notification for questions the bot cannot answer.
  • Suggestive, with the client's team. Real conversations, drafts only. This is where you find the answers that are technically correct and wrong for this business. How long to stay here is a judgment call. My own rule is not a calendar date but a reading: I stay until I have read enough real drafts that I would have sent most of them unedited.
  • Auto-Pilot, on one channel. Start with the channel you watch most closely, keep the message limit low, and read transcripts for the first week. Add channels one at a time.

Where this gets hard across a portfolio

Doing this once, for one client, is an afternoon. The hard part is step 6 across fifteen sub-accounts: knowing, for each account, which published workflows send to the same contacts the bot will answer, and what calendars and users those bots and workflows point at. That reading does not scale through the interface one account at a time, the same argument we made for running a portfolio from one console.

GHL Command is what I use for that on my own accounts. From Claude, I can list a sub-account's bots, knowledge bases and published workflows side by side and read what each workflow actually sends before a bot goes live, across every client I manage rather than one login at a time. It runs on your own machine, so client credentials stay on your computer. It is a flat $97/mo, every sub-account included, never billed per account.

See what else is texting the contact before the bot does. Flat $97/mo.

Read the published workflows, bots and knowledge bases in every GoHighLevel sub-account you manage, from one place, before you flip a client's bot to Auto-Pilot.

See how it works

Frequently asked questions

What is the difference between Suggestive and Auto-Pilot?
Suggestive drafts replies a team member reviews and sends. Auto-Pilot sends on its own. Email auto-replies on the primary bot and the Transfer Bot action only work in Auto-Pilot.

How many messages can a bot send before it stops?
HighLevel's current documentation allows 1 to 100 per conversation, defaulting to 100 for new bots, counting only bot-generated messages. Check the live settings panel, since these defaults have changed before.

Should I train the bot on the client's whole website?
No. HighLevel's guidance is the smallest set of relevant sources, excluding outdated, duplicated and boilerplate pages.

Do bots come across in a snapshot?
Settings, prompts, actions, crawler URLs and custom responses do. Test the imported bot in the destination, and check the calendars and workflows its actions point at.