A useful GoHighLevel Conversation AI handover does five things together: it recognizes when the bot should stop, tells the customer what happens next, assigns a real person, pauses automated replies long enough for that person to act, and leaves a visible record for staff.

Human handover is not a prompt telling the bot to “be helpful.” It is an operating transition. If assignment, notification, pause behavior, and ownership are missing, the customer can receive a polite handover message while nobody actually takes over.

This article is about text-based Conversation AI. It does not describe Voice AI or a live-call transfer.

Check availability before designing around the feature

HighLevel’s June 2, 2026 Human Handover documentation says the action is released through Labs and may need to be enabled before it appears. A newer Bot Goals overview says available actions can vary by account, configuration, or release status.

Before promising the workflow, open the destination sub-account and confirm:

  • the bot type and response mode;
  • whether Human Handover appears under Bot Goals;
  • which scenarios and post-handover actions are available;
  • whether contact-level bot status controls are visible;
  • whether staff notification settings are accessible;
  • which channels the bot is assigned to.

If the account does not expose the documented feature, label any alternative as a proposed workflow design, not the same native Human Handover action.

Decide who the bot is allowed to answer

The safest handover begins before the first bot response. Define eligibility by customer state and conversation purpose.

Conversation state Suggested bot role Human boundary
New inquiry with a supported service question Answer only from approved information and collect limited intake Hand over on uncertainty, exception, or request
New inquiry ready to book Offer the approved booking path Hand over when scheduling needs judgment or the booking fails
Existing customer asking about an active job Do not assume the acquisition bot owns the conversation Route to the service or office owner
Complaint, billing dispute, safety concern, or sensitive issue Do not improvise a resolution Stop and escalate immediately
Spam, abuse, or opt-out Follow the account’s stop and compliance rules Do not keep trying to qualify or book

Existing customers deserve special protection. A bot trained for new-lead qualification can annoy a customer who is asking about today’s appointment or an invoice. Use contact state, open opportunities, tags, assigned user, or another reliable signal to keep acquisition automation out of service conversations.

We would not make the bot eligible for every inbound message merely because it can answer quickly. The first decision is whether automation belongs in that conversation at all.

Configure the native handover scenarios

In the documented prompt-based setup, go to AI Agents → Conversation AI, open the bot, choose Bot Goals, and select Human Handover under actions. HighLevel documents three prebuilt scenarios:

  1. Human Requested: the contact explicitly asks for a person. You can add example phrases.
  2. Lack of Information: the bot cannot find relevant information.
  3. Failed to Resolve Issue: repeated attempts do not resolve the request.

Enable only the scenarios the team is prepared to own. Add realistic phrases for explicit requests, including short versions such as “agent,” “person,” “call me,” or “someone real,” but confirm them in the bot’s test panel. Do not hide the human option behind a particular exact phrase.

Lack of information should cause humility, not invention. The bot should say that a team member will help, then execute the handover. A generic “I don’t understand” loop without escalation is not a recovery path.

Configure what happens after handover

HighLevel’s current action can combine several post-handover steps:

  • assign the conversation to a selected user;
  • skip reassignment when the contact already has an assigned user;
  • send a final bot message;
  • pause the bot for a configured duration;
  • create a contact task due 24 hours after the trigger;
  • add a tag, with human_handover documented as the default.

Treat each as a separate acceptance requirement.

Preserve an existing owner when that reflects reality

“Skip assignment if the contact already has an assigned user” is useful only when existing ownership is trustworthy. If assignments are stale or generic, preserving them can route handovers to nobody who is watching. Define whether the current owner, a service queue, or a handover specialist should receive each conversation.

Write a final message the team can honor

The final bot message should identify the transition and set a realistic expectation. It should not promise an exact response time unless staffing supports it. It should not say a technician, manager, or specialist is assigned unless that action actually occurred.

Set pause behavior around human capacity

A short pause can wake the bot while a person is still typing or waiting on customer information. An indefinite pause can leave a conversation abandoned after the human step ends. Choose a duration and a resume rule together.

HighLevel’s October 12, 2026 contact-level bot status guide documents Active, Inactive, and Sleep/Snooze states for supported Suggestive or Auto-Pilot configurations. It also says manual messages can trigger auto-sleep when global settings are configured that way. Confirm this behavior in the account; do not assume every manual reply automatically pauses every bot.

Notify a person, not just the CRM

Assignment does not guarantee attention. HighLevel instructs teams to enable staff notifications for conversation assignment and task assignment under Settings → My Staff → [user] → Notification Settings.

Decide the fallback when the assigned user is unavailable. A useful handover record should expose:

  • why the handover occurred;
  • the current contact and opportunity state;
  • the last customer request;
  • who owns the next reply;
  • whether a booking was completed, offered, or still needs help;
  • when the bot may resume.

Conversation history can provide context, but the staff member still needs a clear next action. HighLevel also documents conversation summaries and workflow notifications in some configurations, but their availability and timing should be verified separately before relying on them.

Keep lead state and conversation state aligned

A handover should not automatically mean “qualified,” “booked,” or “sales ready.” It only means human attention is required.

Use a small state model:

Handover event Contact or opportunity change What not to assume
Customer asks for a person Record handover reason and owner The lead is qualified
Bot lacks information Flag the unanswered topic The business can provide the requested service
Bot fails repeatedly Stop further automated attempts The customer is at fault or uninterested
Booking completes Record the actual appointment A separate sales outcome occurred
Booking fails or needs exception Assign scheduling help The appointment is confirmed

This follows the wider lead-to-booking workflow map: a system event should update only the state it proves. A bot action is not evidence of a business outcome.

Design stop, pause, and resume as different decisions

These terms are easy to blur:

  • Stop: the bot should not continue this conversation under the current rules.
  • Pause or sleep: the bot is temporarily inactive and may wake after a defined period.
  • Inactive: the bot remains off for this contact until reactivated.
  • Resume: automation becomes eligible again only after an explicit condition or time.

For an existing customer complaint, inactive until manual review may be safer than a timed pause. For a new lead who asks one scheduling question, a short pause plus a staff-owned task may be reasonable. The decision depends on the risk of an unwanted automated reply compared with the risk of leaving the conversation unanswered.

We would not use one universal wake-up timer for every handover reason.

Test controlled conversations before launch

Use the bot test panel for intent recognition, then use controlled contacts on every live channel to prove assignment, pause, and notifications.

Test message or condition Expected bot action Expected staff evidence
“Can I speak to a person?” Final message, handover, and pause Correct owner, task or notification, reason visible
Unsupported service question No invented answer; lack-of-information handover Staff sees the unanswered topic
Repeated misunderstanding Handover after the configured limit One handover, not a loop
Existing customer asks about active work Bot stays out or routes immediately Existing owner or service queue receives it
New lead completes booking Booking is recorded once Assigned staff sees the appointment state
Booking cannot be completed Bot does not claim success Human owns the scheduling exception
Staff sends a manual reply Bot remains paused as configured Bot status and audit event are visible
Customer replies during pause Message is received; bot stays silent Human sees the reply
Pause duration expires Bot resumes only under approved rule Status change is visible and no duplicate reply occurs
Contact opts out Bot stops according to channel rules DND or opt-out state is visible

Also test the failure path: remove the assignee in a safe test configuration or use a test user without notifications. HighLevel says an unassigned handover remains unassigned until claimed. The team needs a queue or alert that exposes that condition.

The service boundary on GHL Conversation AI is intentionally narrow: approved information, intake, routing, booking support, and human handoff. Edex does not claim a verified deployed client bot implementation in the current proof inventory. The eligibility model, state table, and tests here are operating principles and proposed decision rules, not disguised client results.

Release criteria

Do not launch until the team has shown that:

  • the feature exists in the target account;
  • new leads and existing customers have different eligibility where needed;
  • explicit human requests always work;
  • uncertainty and repeated failure stop guessing;
  • assignment preserves the right owner;
  • the final message matches actual staffing;
  • notifications reach the intended person;
  • bot status remains quiet during takeover;
  • resume behavior is intentional;
  • booking and pipeline states change only when proven;
  • audit evidence explains each handover.

The goal is not to keep the bot talking. It is to end automation cleanly when a person is the better next step.