Agency Vault, internal

Calendar audit, day one

The deleted-calendar problem turned out to be rare, one account and nothing still live. The bigger thing is that three quarters of every working calendar is running on fallback rather than its own settings.

Finding 01Only 838 of the 1,530 are real

Nearly half the estate is not active. This is HighLevel's own status, not an inference from how recently something changed.

Worth knowing: 19 of the inactive ones changed within the last week, so accounts are still being deactivated now rather than this being a legacy pile. Signups run 40 to 65 a month with no decline, so the churn is happening after onboarding, not before it.

The audit runs against the 838. That is the honest answer to which are the real sub-accounts.

Finding 0270 members cannot take a booking

A calendar counts as unbookable only when HighLevel itself refuses to serve slots, tested live for the next fourteen days. Not read off its settings.

The split matters more than the total. 59 of the 70 simply never got a calendar, which is an onboarding gap and a repeatable fix. Only 11 had one that broke.

Of the 231: 161 are disabled, 41 have no user attached, 27 serve no slots at all.

Finding 031,005 calendars are one edit from silence

This is the one worth acting on.

These are not broken. Real bookable slots come back for every one of them. They work because HighLevel falls back when a calendar is underconfigured, which means they are a single edit away from going quiet. Reassign a user, or touch availability, and bookings stop with no error, no alert, and no ticket until a member notices the phone stopped ringing.

This held at scale and got worse. It was 66% on the first third of the estate and 76% across all of it.

Finding 04The setup gate never checks bookability

Gate G1 on the Factory Line checks the site is live and branded, the AI receptionist says the member's business name, the number works, A2P is submitted, and email and payments are connected.

It never checks that anyone can actually book an appointment. The auto-verify at station 4 that would catch this is marked on the map as not built.

So a member can pass G1 with a second person signing it off and still have no bookable calendar. Fifty-nine of them have no calendar at all.

Finding 05The deleted-calendar problem is rare

The brief described live workflows pointing at calendars that no longer exist, so the workflow runs, nothing errors, and the booking quietly never happens.

HighLevel does not let you see inside a workflow from anywhere except the builder itself, so there is no way to list which workflows reference which calendar across 838 accounts. The same failure is visible from the booking side instead: every appointment carries the calendar it belongs to, so if that calendar is gone from the account, something booked onto one that has since been deleted.

One sub-account, three appointments, all of them in the past. No member is currently waiting on a booking that will not arrive. The failure is real, it is just rare, and the affected account already appears on the cannot-take-a-booking list above. One account with compounding problems rather than a pattern.

NextWhat I would do

1. Give the 59 accounts with no calendar to a junior with a checklist. Same fix each time.
2. Decide whether the 1,005 get corrected proactively. Safe to do, and it removes a silent failure mode affecting three quarters of the estate.
3. Add a bookability check to G1. One live availability call per member at setup, pass or fail. This is the auto-verify already on the map as not built.
4. Fix the one account carrying appointments on a deleted calendar. Low urgency, nothing future-dated.