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

Owned by Jerry

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

Provider Support & Training

135 contributions to GHL Command
Look for Dependents Before You Delete
Command note: Deleting is easy. Finding out what depended on it is the expensive part. Lesson learned: we once removed a tag we thought was dead. Two workflows still keyed off it, and both quietly stopped firing. Nothing errored. We noticed a week later when follow-ups went missing. The rule: nothing gets deleted until you know what points at it. What quietly depends on other things: • Tags that trigger or filter workflows • Custom fields used in templates and merge fields • Pipeline stages referenced by automations • Trigger links and forms that feed a workflow • Calendars tied to booking confirmations Do it now: 1) List what you plan to delete — one line each 2) Search every workflow, template, and smart list for each name 3) Write down every hit and who owns it 4) Repoint or retire those dependents first 5) Archive or rename before you delete, then wait a week 6) Delete only when nothing has complained A deleted item never sends an error. It just stops doing its job.
0
0
Look for Dependents Before You Delete
Write the Stop Rule Before the Start Rule
Command note: Every automation knows how to begin. Few know how to end. A start rule says when something fires. A stop rule says when it must never fire again. Write the stop rule first, and most runaway workflows never get built. Where stop rules matter most: • Follow-up sequences that should end when the lead replies • Reminders that should end when the appointment is booked • Win-back campaigns that should end after a set number of touches • Anything that sends, charges, or assigns on a repeat Do it now: 1) Pick your three longest-running workflows 2) For each, write one sentence: "This stops when ___." 3) Check that the exit condition exists in the workflow, not just in your head 4) Add a cap on total sends or total days as a backstop 5) Test the stop on a single contact before you publish If you cannot finish the sentence in step 2, that workflow is not ready to run. That is also the fastest way to find the ones already running without a brake. AI makes it easy to build the start in minutes. That speed is exactly why the stop has to be written down first. A workflow without a stop rule is not automation. It is a loop with a budget.
0
0
Write the Stop Rule Before the Start Rule
Say the Caveat Once
Command note: a warning repeated on every line stops being read. It becomes wallpaper. We hit this in our own connection guides. Every step carried the same "not yet checked on a real screen" note, and the page turned into a wall. The fix shipped in 3.88.1: when every step of a system is unchecked, the guide says it once for that system instead of on every step. Where this applies in your client work: • Handoff docs that repeat "draft, needs review" on every section • Client reports with the same disclaimer under every chart • SOPs where every step says "be careful" • Onboarding emails that flag five things as urgent Do it now: 1) Find the one caveat you paste everywhere. 2) Move it to the top, stated once, in plain words. 3) Keep a step-level warning only where that step is actually different. 4) Reread the page. If everything still shouts, cut again. A caveat you say once gets read. A caveat you say everywhere gets skipped.
0
0
Say the Caveat Once
This week: no more ownerless automations
Last week I kept running into the same problem wearing different outfits: - A webhook still firing at an integration that had been dead for months - An automation nobody could actually claim - A user I'd disabled but never fully pulled out of a workflow None of it was loud. Nothing crashed. It was just still running, quietly, because closing it out wasn't specifically anyone's job. The fix turned out to be the same boring thing every time: put one name, not a team, on every live automation and integration. If nobody's name is on it, it isn't owned; it's just forgotten and still running. So that's my focus this week. Going account by account and doing the unglamorous part: - One named owner per live workflow, no exceptions - Every outbound webhook checked against whether the other end still exists - Anything nobody will claim gets flagged for a real decision instead of being left alone It's not exciting work. It's also the difference between finding these things yourself and having a client find them first. What's running in your accounts right now that nobody would admit to owning if you asked them directly?
0
0
Find the Trigger Links Nobody Uses
Command note: a trigger link nobody remembers is a behavior nobody is watching. Trigger links pile up fast. One per campaign, one per test, one copied from an old snapshot. Months later, nobody knows which ones still fire something. Prompt to run today: "List every trigger link in this sub-account. For each one, tell me which workflow (if any) uses it, which emails or texts contain it, and flag any that nothing references." What you are looking for: • Links no workflow listens for • Links still sitting inside live templates • Duplicates with near-identical names • Links from old tests or old snapshots Do it now: 1) Pull the full list of trigger links for one account. 2) Match each link to the workflow that reacts to it. 3) Mark every unmatched link as keep, fix, or retire. 4) Retire the unused ones only after a human confirms. 5) Rename what stays so the name says what the click does. AI can read the whole list in seconds. Deciding what is safe to retire is still your call. A link with no listener is a promise that goes nowhere.
0
0
Find the Trigger Links Nobody Uses
1-10 of 135
Jerry Relth
3
35 points to level up
@jerry-relth-2483
Helping clinics help more people!

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