The situation
The business needed more than a database replacement.
When a company moves CRMs, it is tempting to think of the project as contacts, fields, and pipelines. In practice, the old system has usually accumulated years of operational assumptions: where a lead goes, when production takes over, how a balance is tracked, which numbers management relies on, and what happens when the data is incomplete.
My role was to help translate those real workflows into a GoHighLevel-based system that connected the front end of sales with the post-contract operation and reporting layer.
What I built
Three core pipelines for Sales / New Lead, Production / Post-Contract, and Completed Jobs, with opportunity stages, custom fields, tags, and ownership logic reflecting the actual process.
Lead and opportunity automation, follow-up logic, internal notifications, stop-on-response behavior, duplicate suppression, and consent-aware communication rules.
Sales, Production, Balance Due, Job Cost, and Commission dashboards, plus later dashboard refinements including service revenue visibility.
Google Sheets, Make.com, Apps Script, and GoHighLevel API logic used where native reporting or data access needed additional structure.
Python-based health checking and troubleshooting for missing records, reporting mismatches, bad field updates, duplicates, and incomplete data that could affect the dashboards.
An 87-step onboarding SOP and supporting documentation so the build could be understood, repeated, maintained, and handed over without relying on memory.
A reporting problem is often a data problem in disguise.
One recurring lesson from the dashboards was that reporting accuracy depends on operational discipline upstream. For example, a completed job could disappear from a date-based report simply because its completion-date field had never been filled in. Rather than treating that as “the dashboard is broken,” I added diagnostics that made the missing source data visible.
That distinction matters. A dashboard should not quietly turn incomplete operations into confident-looking numbers.
Compliance had to be part of the system design.
The migration included older contact records, so communication logic could not be treated as an afterthought. I helped redesign opt-in, opt-out, DND, and consent-related workflows, pause unsafe communication paths, remove duplicate triggers, and make response behavior more controlled.
The result was a cleaner operating approach where communication rules were tied to consent state rather than simply whether a contact happened to exist in the CRM.
What changed operationally
- Sales and post-contract workflows were represented in one connected system instead of being fragmented across the old CRM and external reporting.
- Management gained practical visibility into sales, production, balances, costs, and commissions.
- Data issues could be diagnosed instead of silently distorting reporting.
- Workflow and consent logic became more deliberate and easier to audit.
- The system could be handed over with repeatable documentation rather than living only in the builder’s head.
Why this project represents how I work
The strongest part of this project was not any single workflow. It was working across operations, CRM architecture, reporting, integrations, troubleshooting, documentation, and compliance without losing sight of the business process underneath them.
That is the kind of work I want to keep doing: making the backend less fragile and giving the team a clearer way to run it.