Command note: if your funnel promises "we reply in 5 minutes," your automation better actually reply in 5 minutes. Marketing copy makes response-time promises constantly — instant confirmation, same-day callback, 24/7 support — and almost nobody checks whether the workflow behind it actually delivers. Where this breaks quietly: • A form says "instant confirmation" but the confirmation email only fires on a nightly batch • A page promises "text back in minutes" with no business-hours gate, so a 2am lead gets nothing until 9am • A chatbot claims "always available" while its workflow silently pauses on a holiday calendar Close the gap in three passes: 1) Pull every time-based promise out of your funnels, forms, and ad copy. 2) Walk the matching workflow with a clock running — time it for real, don't estimate. 3) Fix the automation to match the promise, or rewrite the promise to match the automation. Never leave the gap standing. A promise your workflow can't keep isn't a marketing win. It's a complaint waiting for a trigger.

Command note: "it's built" and "it's done" are not the same claim, and treating them as one is how obvious gaps make it to launch. Every build needs a definition of done written down before you touch the account — not a feeling you check for at the end. What "done" should name, in writing, before you start: • Which objects must exist — pipeline, stages, fields, tags, calendars, workflows • What each one must actually do, not just that it exists (a workflow that fires vs. one that's merely published) • Who signs off — you, a second set of eyes, or the client • What a passing check looks like for each piece, specifically Do this on the next build, before you open the account: 1) Write the definition of done on one page — one line per object, plainly stated 2) Build against that list, not against memory or a template you half-remember 3) When you think you're finished, read the account back against the same list 4) Only call it done when every line checks out — not when the build finished without an error A build that ran without errors and a build that's actually done are two different claims. Decide which one you're promising before you start, and you'll stop mistaking the first for the second.

Command note: A dead webhook doesn't throw an error — it just keeps firing into silence, forever. Every sub-account accumulates webhooks nobody remembers wiring: a lead-scoring tool the client swapped out, a Zapier zap someone rebuilt under a different URL, a vendor that shut down last spring. GoHighLevel never checks whether the other end is still listening. It sends the payload and moves on. Nobody notices until a client asks why a system "stopped getting leads" and the honest answer is a webhook that's been failing quietly for months. Where this hides: • Webhooks wired during onboarding to a tool the client has since replaced • One-off campaign webhooks that were never removed after the campaign ended • Webhooks pointed at a personal Zapier/Make account an employee who left set up • Duplicate webhooks left behind when a workflow was cloned and repointed Run this today: 1) List every webhook configured on the sub-account 2) For each one, check the target: does that tool or integration still exist, and does anyone here still use it? 3) Confirm the endpoint is actually receiving — ping it or ask the vendor 4) Delete anything pointed at a dead system; "it's not hurting anything" is how these pile up 5) Log what survives: what it's for, who owns the receiving end, when you last verified it A webhook doesn't fail loud. It just quietly stops mattering, and nobody tells you.

Command note: we deactivated a teammate's GHL login the day she left, and three new leads sat unassigned for two days before anyone noticed. The login was gone. Every place that still pointed to her wasn't. Where a user ID keeps working long after someone's gone: • Round-robin lead assignment • Task and follow-up assignees inside workflows • Calendar ownership on a live booking link • "Notify user" steps buried in older automations None of those fail loud. They just quietly keep routing to someone who can no longer see the notification. Before you deactivate anyone, do this: 1) Search every workflow and pipeline for their name, not just their login — the reference outlives the account. 2) Reassign round-robins and calendars to someone active before you flip the switch. 3) Send a real test lead through and confirm who actually gets it. 4) Deactivate, then check again a week later. The account doesn't know someone left. It only knows what you told it to do with their name, and it will keep doing that forever if you let it.

Command note: an automation nobody owns doesn't fail quietly — it just fails in front of the client first. Every live workflow, integration and scheduled send is running whether or not anyone is watching it. "The team owns it" means nobody does. When something breaks, everyone assumes someone else caught it. Where this shows up: • The workflow that's been live for eight months and nobody remembers who built it • The integration sync nobody checks until a client asks why a lead didn't show up • The daily report that's been silently empty for a week • The AI action running client-facing tasks with no one reviewing its output Fix it with one rule: every automation gets one name attached to it, not a team. Do it now: 1) List every live automation across the account — workflows, integrations, scheduled sends, AI actions 2) Assign exactly one owner to each — a person, not a role 3) Give that owner one job: a monthly glance, or a same-day response when it's flagged broken 4) Write the owner's name next to the automation in whatever log or doc tracks your builds An automation with a name on it gets checked. One that belongs to "the team" gets discovered — usually by the client, usually too late.