HOME SERVICES
HOME SERVICES
REVENUE OPERATIONS
REVENUE OPERATIONS
Revenue Operations System for Home Services
Revenue Operations System for Home Services
Revenue Operations System for Home Services
The system was built around the client’s complete lead to job lifecycle, from lead intake and sales pipeline management to quoting, service delivery, reviews, and retention. I handled the architecture across GoHighLevel, Make.com, and Jobber, including webhook driven events, data synchronization, lifecycle logic, and reliability controls that made the operation run as one system.
The system was built around the client’s complete lead to job lifecycle, from lead intake and sales pipeline management to quoting, service delivery, reviews, and retention. I handled the architecture across GoHighLevel, Make.com, and Jobber, including webhook driven events, data synchronization, lifecycle logic, and reliability controls that made the operation run as one system.
The system was built around the client’s complete lead to job lifecycle, from lead intake and sales pipeline management to quoting, service delivery, reviews, and retention. I handled the architecture across GoHighLevel, Make.com, and Jobber, including webhook driven events, data synchronization, lifecycle logic, and reliability controls that made the operation run as one system.
Role
System Architecture, Automation & Integrations Engineer
SA, Automation & Integrations Engineer
LOCATION
Calgary, Alberta, Canada
Industry
Home Services
Stack
GoHighLevel, Make.com, Jobber




THE BUSINESS PROBLEM
THE BUSINESS PROBLEM
THE CLIENT WAS A CALGARY BASED HOME SERVICES COMPANY WITH A FRAGMENTED OPERATING PROCESS.
Lead generation, customer communication, scheduling, quoting, and service delivery were spread across multiple systems and depended heavily on manual coordination. Customer information had to move between GoHighLevel and Jobber, follow-ups were handled manually, and there was no reliable lifecycle connecting a new lead to booking, quoting, job completion, reviews, and repeat business. The challenge was to create a system that could synchronize these stages while reducing the operational work required from the team.
THE CLIENT WAS A CALGARY BASED HOME SERVICES COMPANY WITH A FRAGMENTED OPERATING PROCESS.
Lead generation, customer communication, scheduling, quoting, and service delivery were spread across multiple systems and depended heavily on manual coordination. Customer information had to move between GoHighLevel and Jobber, follow-ups were handled manually, and there was no reliable lifecycle connecting a new lead to booking, quoting, job completion, reviews, and repeat business. The challenge was to create a system that could synchronize these stages while reducing the operational work required from the team.
MY APPROACH
MY APPROACH
I BUILT THE SYSTEM AROUND THE CUSTOMER LIFECYCLE.
Instead of treating lead capture, quoting, reminders, reviews, and retention as separate automations, I mapped the complete journey a customer moves through and designed the system around those states. GoHighLevel became the customer and sales layer, Jobber remained responsible for operational delivery, and Make.com became the orchestration layer connecting events between them. This allowed pipeline stages to represent real business states and allowed each state to trigger the appropriate next action without relying on manual coordination.
I BUILT THE SYSTEM AROUND THE CUSTOMER LIFECYCLE.
Instead of treating lead capture, quoting, reminders, reviews, and retention as separate automations, I mapped the complete journey a customer moves through and designed the system around those states. GoHighLevel became the customer and sales layer, Jobber remained responsible for operational delivery, and Make.com became the orchestration layer connecting events between them. This allowed pipeline stages to represent real business states and allowed each state to trigger the appropriate next action without relying on manual coordination.
SYSTEM ARCHITECTURE
FROM LEAD CAPTURE TO CUSTOMER RETENTION.
Each lifecycle event triggers the appropriate synchronization, workflow or customer communication across the connected systems.
FROM LEAD CAPTURE TO CUSTOMER RETENTION.
Each lifecycle event triggers the appropriate synchronization, workflow or customer communication across the connected systems.

ENGINEERING & KEY DECISIONS
ENGINEERING & KEY DECISIONS
BUILDING THE SYSTEM MEANT SOLVING FOR RELIABILITY, NOT JUST CONNECTIVITY.
The important engineering decisions emerged from the behavior of the systems in real use. The initial Jobber integration used GraphQL and HTTP-based OAuth, but token expiration and refresh handling introduced synchronization instability, which required the integration layer to be reworked around a more reliable implementation. I also introduced duplicate checks before creating operational records, controlled quote follow-up with exit conditions, and event-based timing for appointments and completed jobs. The objective throughout was to make automation state-aware and resilient rather than simply connecting one trigger to another.
BUILDING THE SYSTEM MEANT SOLVING FOR RELIABILITY, NOT JUST CONNECTIVITY.
The important engineering decisions emerged from the behavior of the systems in real use. The initial Jobber integration used GraphQL and HTTP-based OAuth, but token expiration and refresh handling introduced synchronization instability, which required the integration layer to be reworked around a more reliable implementation. I also introduced duplicate checks before creating operational records, controlled quote follow-up with exit conditions, and event-based timing for appointments and completed jobs. The objective throughout was to make automation state-aware and resilient rather than simply connecting one trigger to another.
VALIDATION & REAL-WORLD BEHAVIOR
VALIDATION & REAL-WORLD BEHAVIOR
THE SYSTEM HAD TO SURVIVE REAL OPERATIONAL CONDITIONS.
Validation focused on whether the workflows behaved correctly across the points where sales and field operations could easily fall out of sync. I tested webhook payloads, duplicate prevention, pipeline transitions, appointment timing, quote approval states, and workflow exit conditions, then iterated on issues that appeared during implementation. Early testing exposed OAuth and synchronization instability, while reminder timing and duplicate client creation required additional controls before the workflows could reliably move customer data between GoHighLevel, Make.com, and Jobber.
THE SYSTEM HAD TO SURVIVE REAL OPERATIONAL CONDITIONS.
Validation focused on whether the workflows behaved correctly across the points where sales and field operations could easily fall out of sync. I tested webhook payloads, duplicate prevention, pipeline transitions, appointment timing, quote approval states, and workflow exit conditions, then iterated on issues that appeared during implementation. Early testing exposed OAuth and synchronization instability, while reminder timing and duplicate client creation required additional controls before the workflows could reliably move customer data between GoHighLevel, Make.com, and Jobber.
HOW THE SYSTEM WAS VALIDATED
HOW THE SYSTEM WAS VALIDATED
TEST
Webhook payloads, pipeline transitions, duplicate prevention
TRACE
Synchronization, timing, authentication failures
REFINE
Workflow logic, error handling, lifecycle controls
VERIFY
End-to-end behavior across GoHighLevel and Jobber
TEST
Webhook payloads, pipeline transitions, duplicate prevention
TRACE
Synchronization, timing, authentication failures
REFINE
Workflow logic, error handling, lifecycle controls
VERIFY
End-to-end behavior across GoHighLevel and Jobber
TEST
Webhook payloads, pipeline transitions, duplicate prevention
TRACE
Synchronization, timing, authentication failures
REFINE
Workflow logic, error handling, lifecycle controls
VERIFY
End-to-end behavior across GoHighLevel and Jobber
RESULTS & EVIDENCE
RESULTS & EVIDENCE
THE SYSTEM REPLACED MANUAL COORDINATION WITH A CONNECTED CUSTOMER LIFECYCLE.
The system reduced the delay between a new request and the first automated response from roughly 3-4 hours to approximately 5 seconds, while 412 of 412 leads in the measured cohort passed through automated lead-data processing. The documented operational impact also includes more than 60 hours of manual administrative work reclaimed per month, cancellation and no-show rates moving from above 10% to approximately 2%, approximately 2× monthly Google Review volume within 60 days, and 63 repeat bookings from a tracked cohort of approximately 500 customers. Quote approval also improved in the observed post-implementation cohort, although the longer follow-up period was still ongoing.
THE SYSTEM REPLACED MANUAL COORDINATION WITH A CONNECTED CUSTOMER LIFECYCLE.
The system reduced the delay between a new request and the first automated response from roughly 3-4 hours to approximately 5 seconds, while 412 of 412 leads in the measured cohort passed through automated lead-data processing. The documented operational impact also includes more than 60 hours of manual administrative work reclaimed per month, cancellation and no-show rates moving from above 10% to approximately 2%, approximately 2× monthly Google Review volume within 60 days, and 63 repeat bookings from a tracked cohort of approximately 500 customers. Quote approval also improved in the observed post-implementation cohort, although the longer follow-up period was still ongoing.
3 to 4h to about 5s
Response Latency
137 to 206 hrs/month
Operational Efficiency
about 58% higher
Quote Optimization
100% | 412/412
Lead Orchestration
LESSONS & LIMITATIONS
LESSONS & LIMITATIONS
THE BIGGEST LESSON WAS THAT RELIABLE AUTOMATION DEPENDS ON SYSTEM DESIGN, NOT JUST WORKFLOW LOGIC.
The project reinforced the importance of clear system ownership, stable integrations, duplicate prevention, event-driven synchronization, and controlled workflow states. It also showed why validation needs to happen against real operational behavior, especially when external APIs and business processes interact. The results combine observed cohorts with calculated outcomes, so each metric is presented according to the strength of its underlying evidence rather than treating every improvement as a controlled causal result.
LIMITATIONS
Some outcomes came from observed cohorts rather than controlled experiments, and historical baselines were not available with the same level of instrumentation across every metric.
FUTURE DIRECTION
The architecture can support deeper lifecycle automation, stronger operational monitoring, and reusable revenue operations systems for other service-based businesses
THE BIGGEST LESSON WAS THAT RELIABLE AUTOMATION DEPENDS ON SYSTEM DESIGN, NOT JUST WORKFLOW LOGIC.
The project reinforced the importance of clear system ownership, stable integrations, duplicate prevention, event-driven synchronization, and controlled workflow states. It also showed why validation needs to happen against real operational behavior, especially when external APIs and business processes interact. The results combine observed cohorts with calculated outcomes, so each metric is presented according to the strength of its underlying evidence rather than treating every improvement as a controlled causal result.
LIMITATIONS
Some outcomes came from observed cohorts rather than controlled experiments, and historical baselines were not available with the same level of instrumentation across every metric.
FUTURE DIRECTION
The architecture can support deeper lifecycle automation, stronger operational monitoring, and reusable revenue operations systems for other service-based businesses
Role
System Architecture, Automation & Integrations Engineer
Industry
Retail / Boutiques
Home Services
LOCATION
Calgary, Alberta, Canada
Stack
GoHighLevel, Make.com, Jobber
ENGINEERING FAQ
THE ENGINEERING DECISIONS BEHIND THE SYSTEM.
THE ENGINEERING DECISIONS BEHIND THE SYSTEM.
A closer look at how I handled system ownership, cross-platform synchronization, OAuth reliability, duplicate prevention, workflow failures, and lifecycle logic across GoHighLevel, Make.com, and Jobber.
A closer look at how I handled system ownership, cross-platform synchronization, OAuth reliability, duplicate prevention, workflow failures, and lifecycle logic across GoHighLevel, Make.com, and Jobber.
What happens when an integration fails?
How did you keep CRM and Jobber data consistent?
How did you prevent duplicate leads and repeated actions?
How did you handle failures without breaking the customer lifecycle?
How did you decide what should be automated?