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

Owned by Jerry

Contour Secrets 🤫

105 members • Free

Your #1 Go-To Resource for Starting, Building, & Growing Your Contour Business!

Provider Support & Training

Clief Notes

48.5k members • Free

🏛️ Coaching Academy

5.1k members • Free

AI Video Bootcamp

28.1k members • $9/month

The Video Dept.

6.3k members • Free

AI Automation Vault

37.8k members • Free

The Iron Forge Brotherhood

52.3k members • Free

AI Automations by Jack

3.4k members • $87/month

Agentic AI for Founders

3.7k members • $97/month

CEO Lab (Marketer School)

1.2k members • $197/month

121 contributions to GHL Command
Reconcile Every Price You Still Charge
Command note: the price in your checkout and the price in your head stopped matching months ago. Product catalogs rot quietly. Nobody deletes the old offer, they just stop selling it. Then a stale price page takes an order, an expired coupon still applies, and a subscription bills an amount nobody on the team recognizes. Run this on one sub-account: "List every product in this location with all of its prices, plus every coupon. Then pull the last 90 days of orders, invoices and active subscriptions. Show me: prices no order has ever used, products with more than one active price, coupons still redeemable past their intended end, and any subscription billing an amount that does not match a current price. Group it by product." What it surfaces: • Old price points still live on a funnel nobody audits • Two active prices for one product, with buyers hitting the cheaper one • Coupons with no end date quietly discounting every sale • Subscriptions on legacy amounts you meant to migrate Do this today: 1) Run the read, it only lists, it changes nothing 2) Archive every price with zero orders in 90 days 3) Close or date-bound every open-ended coupon 4) Decide per legacy subscription: honor it or migrate it, then write the decision down 5) Buy your own offer once at full price and watch the amount land You do not have a price list. You have whatever your checkout said last.
0
0
Reconcile Every Price You Still Charge
Never Reuse the Same Test Contact
Command note: the automation passed every test and failed on the first real lead. The test was the problem. We checked a new intake sequence on the contact record we always use for testing. It ran clean. The first actual lead got nothing. That record was carrying things a new lead never has: • Tags left over from earlier tests, one of them an exit condition • A previous enrollment in the same workflow, so re-entry rules applied • DND switched on during a test months ago • Fields already filled, so a "field updated" trigger never fired • An assigned user, so the assignment step had nothing to do None of that surfaces as an error. The workflow quietly skips a step, exits early, or takes a different branch, and still reports success. Do this on the next test: 1) Create a brand new contact — never reuse an old one. 2) Give it a real address you can open (plus-addressing works fine). 3) Enter it through the actual door — submit the form, do not add the tag by hand. 4) Read the enrollment history, not just your inbox. Confirm which steps ran. 5) Delete it when you are done, so it never becomes next month's dirty test record. A contact that has been through your account is not a new lead. It is a veteran, and veterans get treated differently.
0
0
Never Reuse the Same Test Contact
Teach the Client One Screen
Command note: a client who cannot find anything in the CRM goes back to their phone, and the record you built dies the week after handoff. Adoption is a design problem, not a training problem. Nobody learns a whole CRM. They learn one screen. Pick their one screen — the single view they open every morning: • A smart list of contacts waiting on them • The pipeline filtered to the stage they own • Today's calendar with the contact attached • The conversations inbox, and nothing else Do this in the first week: 1) Ask what they check now — the notebook, the phone, the inbox tab they never close. 2) Build the one view that replaces it, inside their sub-account. 3) Hide every menu item they do not need yet. Clutter reads as complexity. 4) Walk them through it once, in five minutes, on a live record. 5) Check at day 14 — if they have not opened it, the view is wrong, not the client. The test is not whether they were trained. It is whether they open it unprompted on a Tuesday. Train them on the whole CRM and they will use none of it. Give them one screen and they will keep the record alive.
0
0
Teach the Client One Screen
Never Count a Draft as Live
Command note: a tool that reports "done" is quoting its own request, not the account. We shipped v3.84.2 today. It went through every place we report something as done, verified, ready or published and checked the claim against a second read of what GoHighLevel actually holds. Thirteen of them were repeating the write's own response back to us. The sharpest one: • A build report said "Published N workflow(s) live" • The publish step had already read one back as a draft and said NOT LIVE • The build threw that answer away and counted it anyway The other one worth knowing: a workflow can save as "published" with every trigger still inactive. Status says published. Nothing enrolls anybody. We now name the inactive triggers and report the active count next to the step count. The habit works without our tool: 1) Never take "success" from the thing that did the work — read it back from somewhere else 2) For any workflow: confirm the status reads published, then confirm at least one trigger reads active 3) Enroll one test contact — a published workflow nobody can enter is a draft with better paperwork 4) When you cannot confirm it, write "unconfirmed" instead of "done" A green check is a claim. A read is evidence.
0
0
Never Count a Draft as Live
The fix that deleted itself
Small win from last week that I keep turning over. A guide in my member area had a wrong step in it, and the real correction wasn't going out until the next release. So I layered a patch on top. Temporary. The kind you promise yourself you'll pull later. The part I got right, honestly half by accident: I made the build compare my patch against the real source and complain every time they matched. Last week the corrected release landed. The build started complaining immediately. I deleted two patches: one had been unnecessary for a week and had been saying so the entire time. Every account I've built has these. The workflow paused "just for the launch." The tag added for one campaign. The manual step you took over when something broke and never handed back. None of it costs anything the day you add it. It costs six months later, when nobody remembers why it's there. So now, when I add a TEMPORARY ANYTHING: 1. I write the condition that makes it unnecessary 2. I put that condition somewhere that will nag me; not in my head 3. When it fires, I delete it. I don't "review" it A temporary fix with no expiry isn't temporary. It's just undocumented. What's the oldest temporary thing still running in one of your accounts?
0
0
1-10 of 121
Jerry Relth
3
36 points to level up
@jerry-relth-2483
Helping clinics help more people!

Active 2h ago
Joined Jun 2, 2026
Peoria, AZ