On this page
Key facts at a glance
| Question | Answer |
|---|---|
| What are the signs? | Duplicate contacts, 2am workflows, messages that stop while the dashboard stays green, leftover automations nobody owns. |
| Why the duplicates? | A form, a lead ad, a calendar and a Zap each creating a contact for the same person. |
| Why 2am emails? | Wait steps, leftover tags, and cloned workflows from authors who have left. |
| Why is messaging quiet? | A2P, Twilio or domain authentication can refuse traffic while campaigns still show sent. |
| What do you do first? | Grant read access, do not add another automation, decide from the written list. |
What are the signs your GoHighLevel account needs an audit?
Your GoHighLevel account needs an audit when the CRM has started lying: a lead in two pipelines, a campaign that shows sent with nobody receiving it, or a team afraid to turn anything off because they do not know what still depends on a tag from 2022.
Those are not “HighLevel bugs”. They are what happens when the account grew faster than its naming conventions, and nobody catalogued what was live. Adding another workflow on top is how the next 2am fire starts.
A typical inbound shape: an agency, three contractors over two years, Facebook lead ads plus a Zap plus a calendar each creating contacts, and Twilio gone quiet. Nobody can say which path is canonical. That is an audit, not another snapshot.
The homepage already carries a published review from Kelly Williamson on a HighLevel account that had stopped sending. This article does not repeat that quote. The GoHighLevel account audit exists to produce a written list you can use whether or not you hire anyone to fix it. The initial review is free. If the list says the next job is past the native builders, that is when you want what a GoHighLevel developer actually does.
You do not need a dramatic outage to justify the look. A slow leak is enough: conversion down, the team arguing about which pipeline is real, and a contractor who left without a handover. Waiting until Twilio is banned just makes the written list longer.
Why do duplicate contacts and split conversations happen?
Duplicate contacts happen because more than one create-path is still live: a form, a Facebook lead ad, a calendar booking and a Zap can each write a new record for the same person.
HighLevel then looks busy. Your team looks at three records for one person and sends the same SMS twice, or none at all because the “open” conversation is on the empty duplicate.
The audit question is not “do you have duplicates?”. Almost everyone does. The question is whether the create-path is still live, whether merge rules exist, and whether workflows key off the wrong record. Until that is written down, every new integration makes it worse.
This is usually still admin-and-architecture work, not a custom app. It becomes developer work when the duplicates are being written by an outside system with no native connector, or when two systems are allowed to edit the same contact without a source of truth. That is the line described in how engagements run: read first, then decide which hat the next slice needs.
Why do workflows fire at 2am?
Workflows fire at 2am because a wait step, a leftover tag, and a cloned workflow are still enrolled, often written by people who are no longer on the team.
A timezone setting can be part of it. More often it is a tag that still applies, a second workflow that re-adds the tag, and a third that was cloned and never switched off. The owner sees a complaint. The account has three authors.
Turning the noisy one off without a map is how you also turn off the booking confirmation. The audit catalogues triggers, enrolment conditions, and which pipelines still use those tags. You get a list of what is safe to disable, what must be rebuilt, and what is already dead but still consuming execution.
If the “workflow” is actually a Zap or a Make scenario that HighLevel did not author, the same symptoms show up in a different bill. At volume, that is the story in the Zapier to self-hosted n8n write-up: the CRM looks fine, the side engine is the thing waking people up.
Why do SMS and email stop while the dashboard still looks green?
SMS and email stop while the dashboard stays green because the carrier, A2P registration or domain authentication can refuse the traffic after HighLevel has already marked the campaign as sent.
Workflows complete. The inbox is quiet because the registration never allowed the traffic through. A2P, 10DLC, a banned number, a mis-declared use case: these are the failures clients describe, and they are on the audit checklist for a reason.
This is not a “buy more credits” problem. It is a compliance and identity problem sitting under HighLevel. The audit looks at numbers, registration, and whether workflows are still trying to send on a path that has already been refused. Fixing it may be paperwork and configuration. It may also be rebuilding the send path so the next campaign does not inherit the same declaration.
Email has its own version: domain authentication that was never finished, a dedicated IP that nobody warmed, or a workflow blasting a list that should have been a nurture. The symptom is “nothing lands”. The cause is almost never the template colour.
A related sign: the account has been sitting unused for months because every screen felt overwhelming. That is still an audit. Silence in the CRM is not the same as a healthy CRM.
What counts as an orphaned automation?
An orphaned automation is one left over from a process that no longer happens: a tag for a webinar that ended, a calendar that still accepts bookings for a service you no longer sell, or a workflow that still enrols contacts for a pipeline that was renamed.
Every HighLevel account that has been live for more than a year has a graveyard. Custom fields for a pipeline that was renamed. Snapshots applied on top of snapshots.
Orphaned does not mean “delete everything unused tonight”. Some of it is the only record of a legal conversation. Some of it is still quietly enrolling contacts. The audit's job is to name the orphans so you can choose: archive, rebuild, or leave with a note. Guessing in the UI is how the next duplicate path gets born.
If you have never had a second pair of eyes on the account, this is the most common finding: not one dramatic break, but fifty small leftovers that make the next change unsafe. That is why nothing touches live customer data until you have signed off the phase.
How does an audit sort working, broken, and orphaned?
An audit sorts what is live into three buckets you can act on: working (leave and document), broken (staged fix), and orphaned (switch off only after the map says nothing else depends on it).
| Bucket | What it means | What you do |
|---|---|---|
| Working | Live, correct, and still serving a process. | Leave it. Document why it exists so the next person does not “clean” it and break booking. |
| Broken | Actively harmful: double sends, wrong pipeline, dead number, webhook that 401s. | A staged fix, not a weekend of heroic clicking. |
| Orphaned | Left over from a process that no longer happens. | Switch off only after the map says nothing else depends on it. |
That list is useful if you fix it in-house. It is also the scope for a developer if the broken bucket is OAuth, a Marketplace app, or Voice AI that has to book into the same CRM. You do not have to decide that on the first call. You decide after the writing exists.
What should you do before you hire anyone?
Before you hire anyone, grant read access for a written audit, do not add another automation while you wait, and decide the next slice from that list rather than from a sales call.
If the inbound shape is already the one above (agency, several contractors, lead ads plus Zap plus calendar, Twilio quiet), start with the form. Do not clone the noisiest workflow “just for now”.
- Get audit access. Read-only is enough. You keep the account.
- Do not add another Zap, snapshot or cloned workflow while the list is being written.
- Do not give a freelancer admin without a written map.
- Decide from the three buckets: fix in-house, hire an admin, or hire a developer for the slices past the menus.
Those three panic moves (clone, snapshot, unmapped admin) are how a recoverable account becomes a rebuild. The audit is cheaper than any of them.
FAQ
Is the audit really free?
Yes. You grant read access, I go through the account, and you get a written list back. If you take it away and fix it yourself, that is a fine outcome.
Is the review read-only?
Yes. Read access is enough. Nothing is changed until you have a staged plan and you have signed off the phase.
What if the account has been sitting unused?
That is still an audit. The written list is how you find out whether the next step is a tidy, a rebuild, or a developer ticket. Silence in the CRM is not the same as a healthy CRM.
When does this become a developer job?
When the broken bucket cannot be fixed in the native builders: OAuth, webhooks, a Marketplace app, or Voice AI that must write into HighLevel. That is hire-a-developer territory, after the list exists.
Do I have to hire you after I get the list?
No. The list is yours. If you fix it in-house, that is a fine outcome. If the next slice is past the menus, you already have the scope for a developer engagement.
Related reading
What a GoHighLevel developer actually does · GoHighLevel account audit · All articles
Next step
Tell me what is going wrong
Two minutes in the form, a written answer inside two working days. You keep the account throughout.
Gareth Richardson
HighLevel Verified Developer Partner and Certified Admin.
I audit and rescue HighLevel accounts, then build the slices the menus cannot do: API v3 integrations, Marketplace apps, and Voice AI that writes into the same CRM. You keep the sub-account and the data throughout. More on the about page.