Activity
Mon
Wed
Fri
Sun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
What is this?
Less
More

Memberships

GHL Command

5 members • Free

ES
Entrepreneur Speaker

171 members • Free

AI Agency Bootcamp

76 members • $9/month

AI Automation Vault

17.2k members • Free

Bell Well Joy Academy

103 members • Free

PointsOS Vault

59 members • $397

AI Creator Studio

2.9k members • Free

TS
The SLD TRIBE

4.7k members • Free

LuxxeLevelConversationMastery

3 members • $97/month

4 contributions to GHL Command
The form that thanked people while their leads evaporated
Found a bug in our own funnel this week that I guarantee is live in someone's account reading this. A form posts to a GoHighLevel inbound webhook. The webhook fires. The workflow runs. The thank-you page shows. And no contact is ever created. The lead is gone. No error anywhere. Here is why: GHL inbound-webhook workflows run contactless. Unless the workflow has a Create or Update Contact action with the payload fields mapped, GHL executes the whole thing into the void. Tags fire on nobody. Emails send to no one. The execution log shows green. The test that catches it takes ninety seconds. Submit your own form with a real email. Wait a minute. Search Contacts for it. If it is not there, your form has been a paper shredder. This is one of seven silent failure modes I put into a free checklist, all from real broken accounts: get.ghlcommand.com/checklist. Work through it on your own account this week. Most agencies find at least one.
1 like • 11h
Lessons learned from the using the public funnel QA pass: 1. Funnel UI is not proof. We had live cases where the frontend could report failure while GHL still created or matched the contact. Thank-you states, success toasts, and workflow fires are not enough to verify a funnel. 2. Duplicate-contact behavior must be tested explicitly.Both Apex /audit and /weekly-workflow-waste-finder had duplicate-contact false-failure behavior. If duplicate handling is not tested on purpose, a broken production funnel can look “mostly fine” until real traffic hits it. 3. Custom-field writes should not rely on guessed keys.The Weekly Workflow Waste Finder was silently dropping core worksheet answers because the handler was writing ambiguous field keys instead of verified Apex field IDs. Contact creation alone is not enough; field persistence has to be checked directly. 4. Production host of record matters.A fix is not done when code is patched locally or deployed “somewhere.” It is only done after deploy to the actual production host and live retest on the branded public URL. 5. Public form QA needs a minimum standard.For any GHL-connected public funnel, the baseline should be: 6. Booking wrappers need their own proof standard.A live wrapper page and reachable widget URL are not enough. A booking surface should not be called verified until there is at least one confirmed burner appointment or equivalent authenticated booking proof. What changed from this: - Apex /audit now passes happy path, validation, and duplicate-contact retest - Apex /weekly-workflow-waste-finder now passes happy path, validation, and duplicate-contact retest - backend GHL truth now matches frontend behavior on both forms - one remaining gap: Apex /booking still needs authenticated burner booking proof We turned this into a reusable rule by creating the ghl-funnel-qa skill so this process can be repeated instead of rediscovered.
What today taught us, and what it changed
Build-in-public note, because that is the deal in here. Here is what today actually taught us and what it changed. Lesson 1: not everyone in this group owns the tool, and writing as if you all did was a mistake. Some of you are running GHL Command already. Some of you joined to look before you buy. We had been writing lessons as if everyone had the tool connected, which quietly leaves half the room out. So we fixed it. Nothing in here is locked. Every module is open. If you do not own the tool yet, the lessons now tell you what the screen would show and how far the free path gets you, so you can follow along and decide for yourself. The free assets, the second brain kit, the silent-failure checklist, the prompt swipe file, are yours either way. Lesson 2: the most useful on-ramp is not the advanced stuff, it is the mess. The people this is built for are not short on ideas. They are short on a system. Brilliant, scattered, ten tabs open, building instead of selling. So today we shipped a new module, The Scattered Founder's Operating System. It is the real story of turning a pile of plain-text files and an AI that actually reads them back to you into something that runs your day. If you have ever ended a busy day unsure what you actually moved, start there. Lesson 3: a thin prompt gets you a thin answer. Most prompt lists you have seen are one-liners. A one-liner gets a one-liner back. A real prompt briefs the AI the way you would brief a great hire on day one: who to be, what it is looking at, what good looks like, what to hand back. So we built an operator prompt pack to that bar. Not vending-machine prompts, full briefings you fill in with your details and run. It is going into the resources here. What is getting tested next: The comment-to-client module is built and gets its real test this weekend. Not a builder full of green checkmarks. An actual cold run, someone comments the keyword and we watch the whole thing fire end to end. If it breaks, you will hear exactly how, same as every war story in here. We do not call it working until it works in a stranger's hands.
1 like • 5d
What's the one GHL thing that eats your week or quietly breaks on you? Content scheduling. I had a CSV load into GHL that fired every post at once — no warning, no error, just gone. Everything published simultaneously instead of on schedule. That incident became a hard rule in my system: never push content to GHL via API without a draft-first step, always test with one post, and always verify the schedule list after. The silent failures are the expensive ones. If you could watch it build one thing live, start to finish — what would it be? The intake-to-build pipeline. Client fills out a form, answers get structured into a brief, Claude generates the full asset package — funnel outline, email sequence, SMS follow-up, pipeline recommendation, workflow logic — human reviews it, then it stages into GHL. I've got the concept mapped. I want to see it run end to end, from first question to live build, without me touching anything in between. Where are you with AI right now? Using it daily. Claude is running across my content workflow, my second brain, and my GHL automation planning. I'm not experimenting with AI — I'm building with it. The MCP connections are live, Notion is the hub, and the Claude-to-GHL bridge is an active project, not a future idea. What do you actually want to understand about Atlas? I haven't got there yet. Format — short and frequent, or long and deep? Short sprints, deep reference. I work fast and focused. Give me the thing I need right now, built to the standard I'd expect, and make sure it's documented well enough that I can hand it off or come back to it six months later.
Start here — Welcome to GHL Command
Welcome in. You're a founding member, and I don't take that lightly. Quick on what this is. GHL Command is the room for agency owners who use AI to actually run their operations, not just market with it. I run a healthcare agency on this exact stack every day: the GHL Command MCP, Claude, and a small team of named agents. This is where I build it in public, drop the prompts and templates I'm using, and answer your GoHighLevel questions directly. What your membership includes, plainly: - The GHL Command tool (your license) at the founding rate of $97/mo, locked as long as you stay subscribed. - This community: the build-in-public room, the prompts and templates, and me answering questions. - Every new tool we ship, automatically, at no extra cost while you're a member. Billing lives in your account, not here. You can manage or cancel anytime. If you cancel, the license and your spot here wind down together. Simple. Your first 20 minutes: 1. Open the Start Here course in the Classroom. It gets GHL Command installed and gives you a real win in about 10 minutes (point Claude at one of your sub-accounts and have it tell you what's silently broken). 2. Come back and introduce yourself below: who you are, how many sub-accounts you run, and the one GHL task you're most tired of doing by hand. 3. Read the first war story I pinned: "The $5,000 pipeline ID mistake every GHL agency owner makes." It's the bug that started all of this. That's it. Get the tool running, get your first win, then tell me what you want me to build next. This thing grows around what you actually need. — Jerry
1 like • 5d
Thank you @Jerry Relth, I like what I see!
The $5,000 pipeline ID mistake every GHL agency owner makes
True story. This happened to me on one of my own projects, not a client. An intake workflow was working perfectly. Lead form fires, contact created, tagged, opportunity opens in the sales pipeline. Smooth. Then I renamed the pipeline. New name, same purpose. I updated the workflow's create_opportunity action. Two days later I noticed something off in my daily numbers. Leads coming in, no opportunities showing up. I checked the workflow execution history. It was running. Every step showed green. Forms firing, contacts created, tagged correctly. But no opportunities. Took me three hours to find it. The pipeline ID I'd entered didn't exist. The pipeline existed, but I'd typed one character wrong. GHL didn't error. The workflow didn't fail. The create_opportunity action just silently dropped. And here's the killer: every action after it in the workflow ran on the assumption the opportunity was created. Tags fired. Notifications sent. Internal Slack said "you have a new opportunity." But the opportunity didn't exist. I lost about 38 leads over 72 hours. By the time I caught it, the sales window on a couple of them was already gone. Approximate value: $5,000 in lost revenue. Not catastrophic, but the kind of mistake that gives you ulcers and makes you question every other workflow you've ever deployed. The rule I wrote for myself after that: "Verify ALL IDs (pipeline, stage, field, workflow) exist before deploying. Invalid IDs silently kill all subsequent actions." That rule lives in my CLAUDE.md to this day. This is the class of bug Vera catches automatically. Before any workflow deploys, Vera resolves every ID against the live GHL account. Mismatch means halt, alert, suggest the closest match. No more invisible failures. That's what we're building this week. If you run GHL workflows and you DON'T have something checking your IDs before deploy, you have this bug. You just haven't been bitten by it yet. See the attached screenshot. It's Vera catching exactly this class of bug in 345ms.
The $5,000 pipeline ID mistake every GHL agency owner makes
1 like • 5d
Thank @Jerry Relth this happened to me before and I ended just starting over from scratch! I just made the update
1-4 of 4
Carlos Boyd
1
1point to level up
@carlos-boyd-6290
AI consultant for service businesses owners. I stop revenue leaks from missed calls and slow follow-up with The Consistency System.

Online now
Joined Jun 14, 2026