Almost nothing in a misconfigured GoHighLevel instance produces an error. The forms submit, the dashboard fills, the contacts appear — and the thing you believed was happening is not happening. Every failure below is one we have personally found and fixed in a live instance.
When the scenario behind a webhook is deleted, the endpoint keeps accepting posts and answering normally. The payload goes nowhere — not even queued. Nothing errors, nothing retries, and the only symptom is leads that never arrive. We found one of these in our own stack and could not date when it had died.
"Form submitted" only fires for GHL's own forms. Point a custom site form at the API instead and the workflow sits in Draft forever, enrolling nobody, looking completely correct in the builder. The fix is a tag-added trigger, and you only find it by testing a real submission and watching whether anyone gets enrolled.
Snapshots and imports leave behind near-identical custom fields — "Email Opt In" beside "Email Opt-in". One is written to, one never is, and both appear on the contact record. Whoever reads the wrong one draws the wrong conclusion about consent.
Declining to join a marketing list is not a request to be left alone. An automation that sets DND when a box is unticked marks somebody who filled in your contact form asking you to get in touch as do-not-contact — and attributes it to them. We have made this exact mistake and reverted it the same day, which is why we know where it hides.
None of those are exotic. They are the normal state of an instance that was configured once and never exercised, and they are invisible from the dashboard by design.
01
Every form, custom field, workflow, pipeline stage, tag convention and integration, written down with what it does and whether it currently does it.
Webhooks tested for DELIVERY, not for a 200. An endpoint that accepts and discards is the single most expensive failure in this product and the hardest to see.
Duplicate and orphaned fields identified, with a recommendation on which to retire — a permanently blank field next to a populated one is an invitation to read the wrong one.
02
Forms wired to the fields and tags that automations actually read, with explicit consent capture where you are collecting it.
Workflows on triggers that fire for the way your site really submits, which for a custom form is almost never "Form submitted".
Pipelines and stages that match how your team already talks about deals, rather than the template's idea of a sales process.
03
Every path exercised with a real submission — including the refusal paths. The case where somebody declines SMS consent is a path, and it is the one that is wrong most often.
You get the test log: what was submitted, what appeared on the contact, which workflow enrolled them.
An automation nobody has watched complete is a hypothesis. This is the difference between the instance working and the instance looking like it works.
04
Monthly: changes you need, new workflows, deliverability and a re-test of anything touched. A courier that quietly stopped showing up is survivable only if somebody checks.
Or a documented handover to your own team, which is a legitimate end state and we will not make it awkward.
Either way the map of what fires is yours and stays current.
Four things that are standard in this market and that we do differently, each for a reason we paid for.
A fixed-scope build or repair first, then month to month if you want us running it.
If the audit finds an instance that is already configured correctly, you will get that in writing and an invoice for the audit only. We would rather lose the build than manufacture a reason for it.
Thirty minutes, screen shared, on your instance. You will leave knowing at least one thing in it that is not running.
Because the failures are marketing failures, not IT ones. A workflow that enrols nobody and a webhook that discards leads both present as "marketing is not working", and the people usually asked to fix them are not the people who can see that the trigger is wrong. We do this because we had to learn it on our own instance first.
Yes, and the audit is often the cleanest way to start — it produces a written map that anybody can act on, including them. We will not use it to argue for replacing somebody who is doing the work well.
No. You hold your own account and you can end this at any time without losing your CRM. An agency that owns the licence owns your contact database, and that is not a position we would accept ourselves.
Changes you ask for, new workflows and forms, deliverability attention, and re-testing anything that was touched. Not a fixed hour count — but if a month passes where you needed nothing, we will say so rather than inventing an improvement.
The audit is about a week. A repair depends entirely on what it finds, and we will not quote the build before the audit, because the only way to produce that number in advance is to guess at it.
It connects to it, and it stands alone. A correctly instrumented CRM is what makes attribution and testing possible later — but this is sellable and useful on its own, and we will not make the retainer a condition of it.
Thirty minutes on your own instance, screen shared. If we cannot show you something in it that is not doing what you think it is, there is nothing here to buy and we will tell you that.