TL;DR: Most AI voice agent problems I get asked to fix are not voice problems, they are CRM problems. The agent handled the call fine, but the outcome landed in GoHighLevel as a loose note, a random tag, or a duplicate contact, so nothing downstream fired. My setup is simple: decide the call outcomes first, store facts in custom fields and states in pipeline stages, keep tags for triggers only, write one structured result per call through a single entry point, and let GoHighLevel workflows react to that result. This is the structure I use for Retell agents wired into GoHighLevel, from building CallSetter AI at Tested Media and voice agents for clinics, garages and estate agents at Fortell AI.
When people picture an AI receptionist, they picture the call. The voice, the latency, the moment it books the appointment. That part matters, and I have written plenty about it, from how I build voice agents on Retell to function calling during the call.
But the business does not run on the call. It runs on what happens after it: the confirmation text, the reminder sequence, the follow-up for the lead who did not book, the report the owner reads on Friday. In the systems I build, all of that lives in GoHighLevel. If the CRM is structured badly, a perfect call still produces nothing.
Start from outcomes, not fields
The mistake I see most often is someone opening GoHighLevel, creating twenty custom fields for everything the agent might hear, and only then thinking about what the business needs to happen next.
I do it the other way round. Before touching the CRM, I write down every outcome a call can have and what should happen for each one. For an appointment-setting agent, the list usually looks like this:
- Booked: appointment created, confirmation sent, reminders scheduled.
- Qualified, not booked: the caller is a real lead but did not commit. Follow-up sequence starts.
- Not a fit: wrong service, wrong area, wrong budget. Logged, no follow-up.
- Needs a human: complaint, complex question, or explicit request. Staff task created, usually alongside a live transfer.
- Existing customer, admin request: reschedule, cancel, question about an existing booking.
- No outcome: hang-up, wrong number, spam, silence.
Six or seven outcomes covers almost every small business I have worked with. That list becomes the spine of the whole CRM setup. Every field, stage and workflow exists to serve one of those outcomes, and anything that does not serve one does not get built.
This is the same thinking I use in a scoping call. If the client cannot tell me what should happen after each type of call, the agent is not ready to be built yet.
Fields, stages and tags each have one job
GoHighLevel gives you several places to put information: contact fields, custom fields, tags, pipeline stages, opportunity values, notes. They overlap enough that every account I inherit uses them inconsistently. I keep a strict rule for each.
Custom fields hold facts
A custom field stores something true about the contact that the business will want to read or filter on later. Service requested. Preferred location. Vehicle make, for a garage. Pet name and species, for a vet clinic. Property type and budget band, for real estate.
A few habits keep fields useful:
- Use dropdowns wherever the answer is a category. A free-text "service" field ends up with "MOT", "mot test", "MOT please" and "annual check". A dropdown forces the agent's output into values the business can actually filter and report on. I map the caller's words to the allowed value in the pipeline, not in the prompt.
- Keep a small set of call fields that are overwritten every call. Last call outcome, last call date, last call summary. These always reflect the most recent conversation, which is what staff and workflows care about.
- Do not store what you will never read. If no workflow, report or human uses a field, it is clutter, and clutter is how the next person stops trusting the CRM.
Pipeline stages hold state
A pipeline stage answers one question: where is this lead right now? New lead, qualified, booked, showed, won, lost. The agent moves opportunities between stages, and the stage is what the business looks at on its board.
The rule I hold firmly is that the stage is the state. I do not also encode state in tags like "booked" or "qualified", because then there are two sources of truth and they drift apart within a week. When the owner asks "how many people booked from the agent this month", the answer should come from one place.
Tags are for triggers and segments only
Tags are where GoHighLevel accounts go to die. They are easy to add, there is no schema, and every automation someone has ever built leaves a few behind.
I use tags for two narrow things: marking where a contact came from (for example, that the AI agent created or touched them) and segmenting for campaigns. I avoid using tags to carry call outcomes or lead state. If a tag is needed to start a workflow, it gets a clear prefix and a name that says exactly what it does, so anyone reading the contact understands it without asking me.
One entry point for every call result
The second most common problem I see: the voice platform writes to the CRM from three different places. A function call during the conversation creates the contact, a post-call webhook adds a note, and some older automation adds a tag. When something goes wrong, nobody can tell which path did what.
My pattern is one entry point. During the call, the agent only does what has to happen live: check availability, book the slot, look up a returning caller. Everything else is written once, after the call, by a single step in n8n that receives Retell's post-call data and applies the result to GoHighLevel. If you have not wired that up before, I covered the basics in connecting Retell to n8n.
That single step does the same things in the same order every time:
- Find or create the contact by phone number, so the agent does not create a duplicate for someone already in the CRM.
- Write the call fields: outcome, summary, date, and any facts captured, mapped to the allowed dropdown values.
- Create or move the opportunity to the stage that matches the outcome.
- Add a short note with the summary and a link to the recording, written for a busy human, not a log file. I wrote about what makes those summaries actually get read.
- Fire the trigger that starts the right workflow, if the outcome needs one.
Because every call goes through the same path, I can test it, retry it when GoHighLevel's API has a bad moment, and trust that the CRM reflects reality. The failure modes in this step are sneaky, and I have a whole piece on post-call automations that fail silently.
Let workflows react, not decide
GoHighLevel workflows are good at sending messages on a schedule, creating tasks, and moving things along a sequence. They are less good at complex branching logic, and they are hard to version or test.
So I keep the decisions in the post-call step and let workflows react to clean signals. A stage change to "booked" starts the confirmation and reminder sequence. An outcome of "needs a human" creates a task for the right staff member. A "qualified, not booked" outcome starts a short follow-up sequence by text, which needs proper A2P 10DLC registration to actually be delivered in the US.
The workflow does not have to work out what happened on the call. It is told, in one field or one stage change, and it does its job. That split makes each side easy to reason about, and it means I can change the agent without rebuilding the client's automations, which is part of keeping the voice platform swappable.
Sub-accounts, naming and handover
A few structural choices save a lot of pain later.
One sub-account per client. For agencies running voice agents for several businesses, each client gets their own sub-account with their own fields, pipeline and workflows. Sharing one account across clients looks efficient until someone's data appears in someone else's report.
Name things so a stranger understands them. Field names, stage names, workflow names and tags should make sense to the client's office manager, not just to me. Prefixing everything the agent writes with a consistent marker makes it obvious which data came from the AI and which came from a human.
Document the outcome map. The list of outcomes, the field each one writes, the stage it moves to and the workflow it triggers fits on one page. That page is the most useful thing I leave behind when I hand a voice agent over to a client, because it lets their team change a follow-up message without breaking anything.
How I check it is working
Before launch, I place test calls for every outcome on the list and check the CRM after each one: one contact, correct fields, correct stage, one note, the right workflow started, nothing else fired. It sounds obvious, but this is where I find most of the bugs, and it belongs in the same regression suite as the conversation tests.
After launch, I watch a handful of numbers in the first weeks: contacts created per call (should be close to one for new callers and zero for returning ones), calls with no outcome written (should be near zero), and opportunities stuck in a stage longer than they should be. Those numbers tell me whether the CRM is telling the truth, which matters more than any single call recording. The first two weeks live are where these issues show up.
The short version
- Write the list of call outcomes before you create a single field.
- Custom fields hold facts, pipeline stages hold state, tags only trigger and segment.
- Use dropdowns for anything you will filter or report on.
- Write every call result once, through one post-call step, in the same order every time.
- Keep decisions in the pipeline and let GoHighLevel workflows react to clean signals.
- One sub-account per client, clear names, and a one-page outcome map.
A voice agent is only as good as the system it feeds. The call is the part people notice. The CRM structure is the part that decides whether the business actually gets the bookings, follow-ups and reports it paid for.
I build AI voice and chat agents on Retell, wired into GoHighLevel and n8n so every call turns into something the business can use. If you want an agent built, or an existing setup cleaned up, more about my background here, or book a call.