Working notes, prepared ahead of our call

Why leads die in the CRM, and the first 30 days of fixing it

A root cause read on the six problems described in the role, plus how I would sequence the first month across eight pipelines.

For ACE CPAs From Paul Gregorio Date August 2026 Status Pre-call notes, not a proposal

The six symptoms, and what is actually causing them

Every item below was named in the role description. None of them are hygiene problems. Each one is a structural problem that produces a hygiene symptom, which is why cleanups keep undoing themselves.

Symptom	Root cause	Structural fix
Opportunities sit in stages they left months ago	Nothing computes age in stage, so nothing can alert on it. GoHighLevel does not expose days in stage as a filterable field, so staleness is invisible until someone scrolls.	A days_in_stage field recalculated nightly, a maximum age per stage, an automatic nudge to the record owner at threshold, and a Stale by Stage view for every pipeline.
Missed appointments never get moved, so rebook never fires	The recovery sequence is triggered by a stage change, which is a human action. The automation is waiting on the exact behaviour that is missing.	Trigger on appointment status instead: no show, or ended without an outcome recorded. The automation sets the stage. It never waits for one. Recovery then fires whether or not a card was touched.
Duplicate contacts appear across pipelines	Usually three causes at once: duplicate contacts permitted at location level, imports arriving without an email so there is no match key, and phone numbers stored in inconsistent formats.	One declared unique key, phone normalised to E.164 before every import, upsert rather than create on all inbound sources, duplicate detection at form submit, and a weekly duplicate report with counts.
Last contact dates are keyed to stage changes	There is no field that records real activity, so a stage change date was repurposed as a proxy. It measures CRM housekeeping, not conversations.	One last_real_contact field written only by activity: inbound and outbound calls, texts sent and replied, email replies, and dialer dispositions. Nothing else is allowed to write to it.
Automations broke quietly and nobody noticed	GoHighLevel gives you no alert when a workflow simply stops enrolling. Failure is silent by default, so detection depends on somebody eventually noticing an absence.	A canary record runs each critical path on a schedule. If it does not reach the final step, Slack gets told. Alongside that, a weekly enrollment count per workflow, so a drop from four hundred to three is caught in days.
Attribution reporting is impossible	Lead source, campaign and owner are optional at creation, so a meaningful share of records are missing them and every report silently excludes or misassigns them.	Stamp source, campaign and owner at creation from the UTM, form or webhook payload. No opportunity is allowed to exist without all three. Cost per showed call by channel then becomes a join instead of a manual assembly job.

The pattern

Five of the six failures share one shape: an automation is depending on a human action that does not reliably happen. Stage changes, manual field updates, somebody remembering to check. The fix is not more discipline from the team. It is inverting the dependency so the system observes the event and updates the record, and the humans read the result instead of feeding it.

First 30 days

Sequenced so that nothing new breaks while the backlog is being cleared. Monitoring goes in during week one, before any rebuilding, because you cannot safely change what you cannot see failing.

Week 1See everything, stop the active bleeding

Audit all eight pipelines: stage inventory, record counts by stage, age distribution, and which stages have no defined exit criteria.
Workflow inventory with last enrollment date for each. This alone usually surfaces the silent failures within hours.
Duplicate scan with actual counts, not an impression, plus the specific mechanism creating them per source.
Clear the Missed Appointment and reschedule backlog to zero manually, once, so recovery volume becomes measurable.
Put canary monitoring on the five highest value workflows first.

Deliverable A written state of the CRM with numbers attached, and a ranked list of what is costing the most money.

Week 2Repair the data layer

Build the real last contact field and wire every activity source into it, dialer dispositions included.
Make lead source, campaign and owner mandatory at creation across paid forms, permit imports, Apollo lists and inbound reply routing.
Phone normalisation and upsert logic on every import path, then a controlled merge pass on existing duplicates with a documented merge rule.
Reconcile the do not contact list and state exclusions across every system, not only the CRM.

Deliverable Attribution becomes possible and last contact becomes trustworthy. Reporting after this point is defensible.

Week 3Rebuild the recovery paths

No show and reschedule recovery rebuilt on appointment status, not stage changes.
Speed to lead alerting on paid form fills, with the response time measured rather than assumed.
Stale opportunity nudges per stage, addressed to the owner, with escalation when ignored.
Routing rules so a new lead lands on the right pipeline, the right setter and the right calendar without a human deciding.

Deliverable Recovery and follow up fire on events. A missed appointment starts working itself the same day.

Week 4Standardise, then report

Apply one pipeline standard across all eight, so a rule that exists in one exists in every one.
Weekly reporting pack version one: pipeline movement, stage to stage conversion, stuck deals, hot deals, activity by rep, lead source health.
The views that are missing today: stale leads by stage and pipeline, booked against showed against closed, and closed deals traced back to the setter who sourced the lead.
Define what the dashboard team needs to render, and what has to be true in the data for those numbers to be honest.

Deliverable A reporting pack that runs weekly without assembly, and a definition of correct that someone else can build against.

Eight pipelines means the deliverable is a standard, not eight cleanups

Cleaning eight pipelines individually produces eight versions of the same fix, and drift returns within a quarter because there is nothing to check new work against. The durable version is a written pipeline standard, then automations built with the pipeline as a variable rather than copied and hand edited.

What the standard defines, per stage

Entry and exit criteria. What has to be true for a record to arrive, and what has to be true for it to leave. A stage with no exit criteria is where records go to die.
Maximum age. Past which the record is stale by definition and the owner is nudged, not asked.
Required fields. Enforced at entry, so incomplete records cannot advance and quietly break reporting later.
Owner and dated next step. Every open opportunity has both, always. Unowned records are treated as a system fault, not a person's oversight.

Inbound paid, outbound permit, setter pipelines and the buy side and sell side engagements will not share stage names, and they should not. They share the structure, the SLA logic and the automation coverage. That is what makes the eight maintainable by one person.

How automations stop failing silently

This is the piece most CRM cleanups skip, and it is the reason cleanups have to be repeated. A workflow that stops enrolling produces no error, no alert and no visible change. It produces an absence, and absences are invisible until a month of leads has gone cold.

Layer	What it does	Catches
Canary record	A dedicated test record runs each critical path on a schedule. Reaching the final step writes a timestamp. No timestamp inside the expected window posts to Slack.	A broken path, within hours of it breaking.
Enrollment delta	Weekly enrollment count per workflow, compared against the prior period.	Degradation rather than failure. A workflow still running but receiving a fraction of the traffic it should.
Integration heartbeat	Last successful write per inbound source: dialer, email tool, lead forms, imports, call summaries.	An integration that authenticated yesterday and is silently dropping records today.
Scheduled audit	A standing review of workflow coverage against the pipeline standard.	Coverage gaps. A rule that exists in three pipelines and not the other five.

Why this matters most

Every other fix on this page can be undone by an unmonitored change. Monitoring is what converts a cleanup into a system that holds. It is the first thing I would build and the last thing I would remove.

What I would need on day one

Administrator access to the GoHighLevel account and every relevant sub account.
Read access to the dialer, the email sending tool, and the lead sources feeding the CRM.
Ad spend by channel, at whatever granularity exists today, for cost per showed call.
A Slack channel for alerts, and one named person per pipeline who owns its records.
Clarity on who else currently has permission to edit a workflow. Uncontrolled edit access is often the real cause of quiet breakage.

Open questions for the call

Of the eight pipelines, which one is losing the most money right now, in your read?
When a paid form fill lands, how quickly does the first human touch actually happen today, and is that number measured or estimated?
Who currently has permission to change a workflow?
Are setters credited or compensated on deals they sourced? If they are not, pipeline hygiene is partly a compensation design problem and worth treating as one.
Where is the line between this seat and the automation engineers: do I define and own correctness while they build, or is build work in scope too?
For month one, would you rather see the visible backlog cleared first, or the root causes fixed first? They compete for the same weeks and I would rather agree the trade before starting.

Working notes prepared ahead of an introductory call. Diagnoses above are inferences drawn from the role description, not from access to the account, and I would expect some of them to be wrong once I can see the build.