Command note: A form with zero submissions is not a form. It is a dead end with your logo on it. The forms you forgot are the ones quietly failing. Old embeds, retired offers, a page that got rebuilt and lost its form. Nobody complains because nobody ever arrives. Prompt to run today: "List every form in this sub-account with its submission count for the last 90 days. Flag any with zero. For each flagged form, tell me which workflow and which page it is attached to." What the answer tells you: • Zero submissions, still embedded on a live page: it is broken or buried. Fix the page. • Zero submissions, not embedded anywhere: it is orphaned. Archive it. • Submissions but no workflow attached: leads are landing and nothing follows up. • Two forms collecting the same thing: pick one, retire the other. Do it now: 1) Run the prompt on one active sub-account. 2) Submit each flagged form yourself with a test contact. 3) Confirm the contact lands, gets tagged, and triggers the follow-up. 4) Archive what is orphaned and write down what you kept and why. A quiet form is not a calm form. Check it before you trust it.

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.

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.

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.

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?