Command note: an account with ten dashboards and no owner metric is not measured, it is decorated. Every sub-account you run should have exactly one number that answers "is this working this week." Everything else is diagnostics you only open when that number moves. Pick it from what the client actually sells: • Local service: booked appointments that showed • Coach or consultant: qualified calls held • Product or ecom: first-time orders • Retainer client: leads answered inside 15 minutes Rules that keep the number honest: • It counts an outcome, not an action. Sends and opens are not it. • One number per account. Two numbers means no number. • It has to be readable inside GHL without a spreadsheet. Do it now: 1) Ask the client what they would count if they could only count one thing. 2) Find where that event already lives: a pipeline stage, an appointment status, an order. 3) Make the CRM record it every time, not sometimes. Fix the gap before you trust the number. 4) Write the number and this week's value at the top of your account notes. 5) Report it the same way every week, good or bad. The point is not the reporting. It is that one number tells you which workflow to fix next. Ten charts tell you to schedule a meeting about it. If you cannot name the account's one number, you are running the account blind.

Command note: every account collects custom fields nobody ever fills in. They pile up from snapshots, old campaigns, and forms that got rebuilt. Then your automations reference fields that are empty on almost every contact, and your AI reads them as signal when they are noise. The prompt I run: "List every custom field in this sub-account, then tell me how many contacts have a value in each one. Sort by lowest fill rate." What comes back: • Fields inherited from a snapshot that were never wired to a form • Duplicates: two fields collecting the same answer under different names • Fields with real data that no workflow actually uses Clean it up today: 1) Run it on your messiest sub-account, usually the oldest one. 2) Anything under 5% fill, check whether a form or workflow writes to it. If nothing does, it is dead. 3) Before you delete, search the field name across your workflows and forms. Removing a live field breaks things silently. 4) Merge duplicates into the one your forms actually write to. 5) Save the list of what you cut and why, so the next person does not add it back. A short field list makes every automation easier to write and every AI answer easier to trust. Empty fields are not harmless. They are noise your automations are reading as signal.

Command note: an automation that fires at the right hour in your time zone can still land at 3am in the client's. I learned this on a reactivation campaign. The sequence was set to send at 9am. It sent at 9am. Just not the client's 9am. The sub-account was still on the default time zone from when it was created, and nobody had touched it since. Where the mismatch hides: • The sub-account setting, still on whatever the template shipped with • The user profile time zone, which is separate from the account's • The calendar, which carries its own setting again • The contact record, which may have none at all Four places, one clock, and no warning when they disagree. The check I run now on every account before a single scheduled send goes live: 1) Confirm the sub-account time zone matches where the business actually operates, not where you built it 2) Confirm the calendar's time zone separately, because it does not inherit 3) Send one test to yourself with a wait step, and read the actual delivery timestamp instead of trusting the preview 4) For anything going out overnight, add a send window so a delayed step cannot drift into the small hours None of this is clever. It takes four minutes, and it is the difference between a campaign that looks professional and one that wakes somebody's customers up. The automation was never wrong about the time. It was wrong about whose time.

Command note: automations don't break on the day you build them. They break three months later, quietly, while nobody is looking. The account changes underneath the workflow. A field gets renamed. An offer retires. A booking policy moves. The automation keeps firing against a world that no longer exists. What rots fastest: • Seasonal or promo sequences nobody ever turned off • Workflows tied to a form or field someone edited later • Reminder timing set for a scheduling rule that changed • Templates naming an offer, a price, or a person who is gone Do this today: 1) Add a review date to every workflow name or description. "Review 2026-11-01" is enough. 2) Put the same date on your own calendar, one recurring block per client per quarter. 3) At review, ask three questions: does it still fire, does it still say true things, does it still end? 4) Kill anything you cannot justify. An automation you keep "just in case" is a liability you are not watching. Let AI do the first pass. Ask it to list every workflow, when it was last edited, and when it last touched a contact. Anything untouched for 90 days is either dead or dangerous, and you want to know which one before the client does. Automations do not age well on their own. Give every one of them a date it has to answer for.

Not "a limited one." None. We went looking on August 10. Eleven different routes across both of HighLevel's hosts, tried in two accounts, with credentials proven good by a working call in the same run. Every one came back 404. Webhook management is reserved for Marketplace OAuth apps. So we stopped asking for a webhook and built one out of what GoHighLevel does expose: the webhook action inside a workflow. That turned out better than the thing we were originally after: • It fires on any of GoHighLevel's 57 native triggers, not a short approved event list • It can be conditional. Send the data only when the deal is over 5k, or only for one pipeline • Your client can see it. It sits in their Automation list as a workflow they can read and edit, instead of invisible plumbing That last one is the part that matters after the engagement ends. The takeaway you can steal without our tool: 1) Anything you connect to a client's account should be visible inside that account 2) If the only record of an integration is your Zapier login, it dies with your access 3) Write down what it feeds, in the account, on the day you build it The written guide is open to everyone, no install needed: ghlcommand.com/skills/ and open "Send GHL data to another app." An integration your client cannot see is one you have to be around to explain.