What to actually delegate to a GHL VA

The questions, in the order people ask them

What is a GHL VA?

A GHL VA is a virtual assistant trained specifically in GoHighLevel, working inside your sub-accounts on the operational tasks a build needs after it goes live. It is a description of a skill set rather than a job title, and the skill set is the entire point of hiring one.

The ordinary version of this role builds and repairs workflows, edits campaigns, tidies pipelines, files registrations, chases the ones that bounce, keeps custom values current and reports back in writing. None of that is glamorous. All of it is the reason an account either keeps working or quietly stops.

Why does this role exist at all?

Because GoHighLevel rewards attention and punishes neglect, and the work arrives in pieces too small to schedule. A calendar that needs a buffer changed. A form field nobody maps to the contact record. A campaign still sending the January offer in March. Each one is fifteen minutes. Collectively they are the reason a receptionist books into a slot the technician is already committed to.

Nobody hires a full-time person for fifteen-minute jobs, so the jobs wait. Then somebody decides to hire a GoHighLevel VA and discovers the backlog was never one big task; it was forty small ones with no owner.

What genuinely belongs to a GHL VA?

Work that lives inside GoHighLevel, is repeatable, and has a definition of done.

• Building and amending workflows, pipelines, forms, surveys and calendars.
• Campaign edits: seasonal wording, offer changes, retiring a sequence that has served its purpose.
• A2P and 10DLC filings, and the resubmission when a carrier rejects the brand or campaign wording.
• Domain authentication, sender reputation and the follow-up when a mailbox provider starts filtering.
• List hygiene: merging duplicates, correcting tags, removing contacts who should never have been added.
• Reporting, in a written note short enough that somebody reads it.
• Rolling a working configuration into a second and third sub-account without the drift that comes from doing it by hand each time.

The common thread is that a competent person can verify the result. If you cannot tell whether a job was done, do not delegate it; specify it better first.

What does not belong to one?

Three categories, and being honest about them saves everyone a quarter.

Strategy is the first. A GoHighLevel virtual assistant can execute a nurture sequence and should not be the person deciding what your business says to a lapsed customer. That decision needs someone who knows your margins.

Development is the second. Joining GoHighLevel to a practice management system, a dispatch board or an accounting ledger is engineering work with failure modes, retries and alerting, and it belongs with integrations and custom development rather than on a task list. A VA can chase, test and configure a documented connection. Building one that does not exist yet is a different discipline.

Anything that risks your sending reputation is the third. Cold outreach into bought lists, scraped numbers, aggressive re-permissioning of contacts who never opted in. A good VA declines that work, and the reason is self-interested as well as ethical: the domain and the numbers they are protecting are the same ones your whole system runs on.

How do I brief one so the work actually lands?

Write the outcome, not the click path. “New enquiries from the storm damage form should sit in their own pipeline stage and never enter the general nurture” is a brief. “Go into workflows and add a condition” is you doing the thinking and paying someone else to type.

Then add three things to every request: what triggers it, what the customer receives, and what should happen when the condition is not met. The third one is where most briefs are silent, and silence in a brief becomes a branch that fires at the wrong moment.

Keep one visible list rather than a thread of messages. Priority order is yours to set. If the list is consistently longer than the hours available, that is a capacity conversation and it should be had openly rather than absorbed.

Is a retainer the same as the free installation hours?

No, and confusing the two is the most common misreading on this site.

Installation is free with every edition in this library and is a fixed allowance: eleven hours of installation time, to be booked and used within nine days of purchase. It exists to get one edition live in one account. It is eleven hours of work, not nine days of standing by, and when the hours are used or the window closes, further work is quoted.

A retainer is ongoing. It is monthly capacity against a live account that keeps changing, month after month, with a named person who holds the context. One is a launch; the other is maintenance. You can see both priced honestly on pricing.

When should I not hire one?

When there is a single defined piece of work. Ask for a fixed quote instead; a retainer for one job is a worse deal for you than a quote, and any decent supplier will say so.

When the account has never been installed properly in the first place. Paying monthly for someone to work around an import that dropped half its assets is expensive archaeology. Get the installation done correctly first, then decide what ongoing capacity you need.

And when the volume has genuinely outgrown a retainer. Past a certain point the monthly figure stops being cheaper than a salary, and the honest answer is to say so rather than keep billing.

What does good look like after three months?

The backlog is short and visible. Registrations are approved rather than pending. The weekly note is boring. Nobody in your office says the phrase “I think that automation is still switched off”. That is the whole return, and it is worth more than any single build.