Senior AI, CRM & Automation Architect

We are a privately held construction company seeking a senior automation architect, AI integration developer, backend engineer, or qualified small development team to build a highly systemized, client-owned automation platform connecting the software we actively use. The company name and identifying business information will be disclosed only to qualified candidates after initial discussion. We operate as one construction company under one brand, with two internal service sections: Land Clearing / Forestry, including forestry mulching, land clearing, lot clearing, brush clearing, grading, excavation, drainage, site preparation, driveway installation, access roads, culverts, trenching, demolition, hauling, material delivery, right-of-way clearing, logging cleanup, erosion-related work, stormwater-related work, and similar land-development services. Hardscape / Outdoor Living, including paver patios, retaining walls, sitting walls, walkways, steps, concrete, decks, pergolas, outdoor kitchens, fire pits, fireplaces, pool areas, pool decks, drainage improvements, landscape construction, exterior structures, and related outdoor-living projects. The goal of this project is to connect GoHighLevel, Jobber, Quo, Claude, OpenAI/GPT, n8n or similar orchestration software, Google Workspace, advertising lead sources, existing customer data, and imported CSV lists into one coordinated and highly automated business process. No website design or website development is required as part of this project. This is not a request for a basic GoHighLevel setup, a few Zapier automations, a generic CRM template, or a collection of disconnected workflows. We are looking for a properly designed system that allows information and activity to move reliably between platforms while reducing repetitive administrative work as much as reasonably possible. The finished system should allow ownership to focus primarily on growth, marketing, sales strategy, partnerships, estimating, expansion, and high-level decision-making rather than manually moving information between platforms, following up with every lead, checking every record, or managing routine communication. GoHighLevel should function primarily as the marketing automation, lead-management, email-campaign, segmentation, pipeline, reporting, and workflow platform. We are heavily focused on email campaigns and ongoing follow-up. The system should support structured campaigns for new leads, unresponsive leads, qualified leads, appointments, estimate follow-up, past customers, lost opportunities, builders, Realtors, developers, commercial prospects, referral partners, property owners, seasonal promotions, educational campaigns, project showcases, long-term nurture, customer reactivation, review requests, referral requests, and cross-selling between the two internal service sections. The email system should be organized around meaningful data such as lead source, service interest, internal service section, customer type, lifecycle stage, quote status, job status, engagement, campaign source, consent, and customer history. We do not want hundreds of random tags, duplicate automations, conflicting workflows, inconsistent naming, or unclear pipeline logic. The system must be organized in a way that can be maintained, expanded, and understood after the original developer is no longer involved. Quo should remain the primary phone and two-way SMS platform. A lead should be able to submit a form through GoHighLevel, Facebook, Instagram, Google Ads, or another approved source and receive an immediate or near-immediate SMS through Quo. The customer should then be able to reply naturally by text, and the full conversation should remain visible and manageable through Quo. The integration must prevent Quo and GoHighLevel from sending competing SMS messages to the same contact. There should be one clear source of truth for phone calls and SMS conversations. Relevant Quo activity should be reflected in GoHighLevel through fields, notes, summaries, timestamps, status updates, or another appropriate method without creating duplicate conversations or duplicate records. The system should also support missed-call workflows, call summaries, call transcripts where available, callback tasks, AI-assisted response drafting, automated follow-up, and human takeover. When a team member manually takes over a conversation, automated replies and conflicting follow-up should pause. The team member should also be able to return the conversation to automation when appropriate. Jobber should remain the operational system for qualified customers and actual projects. Jobber should continue to handle clients, contacts, properties, requests, site visits, quotes, jobs, visits, scheduling, team assignments, invoices, payments, customer history, and completed-project records. Not every raw lead should automatically become a Jobber client. The system should create or update Jobber records only when the lead reaches an approved stage, such as qualification, appointment scheduling, estimate preparation, or another clearly defined threshold. The integration should be capable of matching existing Jobber clients, creating new clients, creating or updating properties, creating requests, transferring relevant lead information, adding summaries, linking photos or documents where technically possible, and keeping selected statuses synchronized with GoHighLevel. Jobber should remain the source of truth for operational data such as quotes, jobs, visits, invoices, payments, scheduling, and completed-project history. GoHighLevel may display or reference selected Jobber information, but it should not independently overwrite Jobber-owned operational records without clearly defined rules. Claude should function as a primary reasoning, analysis, summarization, and workflow-decision layer. Claude may be used to interpret form submissions, understand customer SMS responses, summarize Quo conversations, summarize phone calls, review customer history, review Jobber history, classify service requests, identify which internal service section applies, extract project information, identify missing information, evaluate lead quality, recommend the next action, draft personalized SMS messages, draft personalized emails, create estimator summaries, create sales briefings, identify stalled leads, analyze historical records, flag weak follow-up, and generate management summaries. Claude should not have unrestricted access to every system. The finished architecture should expose controlled tools and actions such as searching a contact, reading a conversation, reviewing a Jobber client, checking a quote status, checking a job status, updating a lead classification, drafting a message, sending an approved message, creating a Jobber request, moving an opportunity stage, creating a task, pausing a workflow, or escalating a record to a human. OpenAI/GPT may be used where it is more appropriate for structured extraction, CSV analysis, data normalization, marketing content, email drafting, quality control, secondary validation, classification, or other specific tasks. We do not need Claude and GPT to perform the same job. The selected developer should recommend where each model is best suited and avoid unnecessary AI usage, unnecessary cost, and unnecessary complexity. A typical new lead workflow should function as follows: A lead submits a form from GoHighLevel, Facebook, Instagram, Google Ads, or another approved source. The contact is created or updated in GoHighLevel. The phone number and email address are normalized. The system checks for existing records and duplicates. The lead source, campaign, requested service, and internal service section are identified. Claude or GPT analyzes the submission. The lead is placed into the correct pipeline and stage. A personalized SMS is sent through Quo. A relevant email confirmation or follow-up sequence begins through GoHighLevel. If the customer responds by SMS, generic follow-up should pause. The AI should interpret the customer’s response, review available history, identify missing information, and determine the next approved action. The system should collect only the information relevant to the requested service. For Land Clearing / Forestry leads, relevant information may include property address, county, acreage, current site condition, desired result, terrain, access, utilities, wet areas, drainage, ownership status, timeline, budget indication, equipment access, photos, video, hauling requirements, material requirements, and clearing limits. For Hardscape / Outdoor Living leads, relevant information may include property address, project type, approximate dimensions, materials, existing conditions, site access, drainage concerns, timeline, budget range, design goals, photos, elevation changes, existing structures, utilities, desired features, and appointment availability. We do not want every lead to receive the same long questionnaire. The workflow should adapt based on the requested service and the customer’s prior answers. Once the lead reaches the correct qualification stage, the system should present scheduling options, notify the correct salesperson or estimator, create a useful summary, and create or update the appropriate Jobber records. After a quote is created or sent in Jobber, the correct GoHighLevel estimate follow-up should begin automatically. When the quote is approved, declined, or changed, the correct sales workflow should stop, continue, or move to another stage. When a job is created, scheduled, delayed, completed, invoiced, or paid, the appropriate customer communication, internal notification, review request, referral request, reactivation campaign, or follow-up should trigger. The system must also work with existing data, not only new leads created after launch. We currently use active platforms containing historical contacts, customers, properties, requests, quotes, jobs, conversations, invoices, payments, notes, tasks, appointments, email lists, and prior activity. The project must include a controlled historical-data process that can extract, normalize, match, classify, and activate existing records. Existing contacts across GoHighLevel, Jobber, Quo, and imported files should be matched using platform IDs, normalized phone numbers, normalized email addresses, addresses, company names, contact names, customer relationships, and manual review when certainty is low. The system should identify duplicate records, conflicting records, active opportunities, open estimates, old leads, past customers, unqualified contacts, stale records, and contacts that require manual review. Existing records should not be mass-enrolled into campaigns without classification and controlled activation. We also want the ability to import our own CSV files in the future without depending on the original developer each time. These lists may include builders, Realtors, developers, commercial contractors, property-management companies, past customers, referral partners, local businesses, property owners, vendors, or other prospects. The CSV process should allow us to upload a file, map columns, normalize names, company names, phone numbers, email addresses, and addresses, detect duplicates, match records against GoHighLevel, Jobber, and Quo, assign audience types, apply campaign and source information, identify incomplete or invalid records, determine outreach eligibility, select an approved campaign, and produce a clear import report. The system should also prevent the same list from being imported multiple times. Reliability is extremely important. The integration should not depend only on live webhooks. It should include scheduled reconciliation, duplicate-event protection, idempotency, retry handling, error notifications, failed-event logging, dead-letter handling, credential-expiration monitoring, synchronization monitoring, API rate-limit handling, data-conflict rules, manual review queues, backups, recovery procedures, and restoration documentation. The system should be able to recover from missed webhook events, duplicate events, partial failures, expired credentials, API outages, messaging failures, record mismatches, and failed AI actions. A central integration layer should coordinate the platforms. This may include n8n, custom middleware, PostgreSQL, TypeScript, Node.js, Python, REST APIs, GraphQL, OAuth, webhooks, queues, secure credential storage, audit logging, approval controls, monitoring, and a simple internal dashboard. We are open to another architecture if it provides better reliability, maintainability, ownership, portability, and long-term control. The system should maintain a cross-platform identity map so that one person or company can be connected correctly across GoHighLevel, Quo, Jobber, and the integration database. A single customer may have multiple phone numbers, email addresses, properties, requests, jobs, quotes, and opportunities. The integration must be capable of managing those relationships without creating unnecessary duplicate contacts. Each system should have a defined responsibility. GoHighLevel should generally own lead management, marketing lifecycle, opportunity stages, email campaigns, segmentation, lead source, attribution, and nurture enrollment. Quo should generally own phone calls, SMS conversations, call activity, and human phone communication. Jobber should generally own operational clients, properties, requests, quotes, jobs, visits, scheduling, invoices, payments, and project history. The integration database should generally own cross-platform IDs, sync status, workflow state, AI classifications, approval status, audit history, import history, error history, and duplicate-resolution information. Claude and GPT should provide reasoning, interpretation, summarization, classification, drafting, and decision support, but should not serve as permanent systems of record. The finished system should provide clear reporting on new leads, lead source, campaign, internal service section, qualified leads, appointments, estimates, quote approval rate, close rate, revenue by source, revenue by campaign, revenue by service section, builder campaign performance, Realtor campaign performance, email performance, SMS performance, call activity, response time, stalled opportunities, reactivation performance, workflow failures, duplicate records, AI usage, AI cost, human approvals, and records requiring review. The long-term objective is to connect marketing and outreach activity to actual Jobber revenue. All accounts, infrastructure, databases, source code, workflows, prompts, API credentials, repositories, hosting, documentation, automation files, and related intellectual property must remain client-owned. The finished system must not depend on a contractor-owned agency account, proprietary CRM, private hosting account, hidden source code, undocumented workflows, or permanent contractor access. The system should remain operational after the original contractor’s access is removed. This is intended to be a one-time custom implementation project, with the possibility of limited post-launch maintenance or future development. We are looking for someone capable of designing the system correctly, building it inside our accounts, documenting it thoroughly, testing it carefully, and handing over a reliable platform that we can continue operating and expanding.