Document Contents

---

Validation Badge Legend

Status badges appear throughout this document. Each badge identifies whether an item is confirmed, pending, or still requires action before treating as operational fact.

Confirmed   Pending Tenant Config   Tenant Validation Required   Leadership Decision Required   Legal Review Required   Reference Only / Refuted   Priority 1

Leadership Brief

Read this first. One to two pages. It answers the three questions leadership has when opening a document like this for the first time.

What Has Been Decided and Is Operational Right Now

The following are confirmed decisions in active use — not plans, not designs, not aspirational targets:

The 12-state lifecycle is the operating vocabulary. Every lead and job moves through the same 12 states from New Lead to Paid & Closed. These names are locked and in use. The sequence is not up for debate — it reflects how the business actually works.

Leap is the primary system of record. Post-contact lead records, appointment booking, job records, build-ready gate documentation, invoice amounts, payment status — all of this lives in Leap. This is a confirmed, operational decision.

GHL handles pre-contact intake. Speed-to-lead, first response, lead-source routing, and long-term nurture live in GHL. GHL does not own the job record. That boundary is set.

CompanyCam is the field evidence system. Photos are tagged to controlled taxonomies. CompanyCam is not a communication tool. Its role is limited and defined.

JobNimbus is the current estimating tool (interim). All proposals are built and delivered through JobNimbus today. When SalesPro pricing is configured and confirmed, JobNimbus is retired. The cut-over is a clean switch — no parallel running.

SalesPro is the adopted proposal tool. Leadership has confirmed this decision. The only open item is pricing configuration. Once that is complete, SalesPro becomes the live estimating system.

The team has operating instructions today. Every state block in Section 3 contains an interim manual protocol — what the team does right now, before any automation is built. Monday morning is covered.

What Is Pending and In What Priority Order

Priority 1 — Configuration (before any automation can be built): Nine validation items (VAL-01 through VAL-09) must be confirmed against live Leap, GHL, and CompanyCam tenants. These are tenant exports and configuration confirmations. Until they are received, automation workflows are based on design, not confirmed live behavior.

Priority 2 — SalesPro pricing: Load and validate all trade pricing, product options, and package structures inside SalesPro. When this is complete, the cut-over from JobNimbus happens and Section 8 is updated to reflect it as fully live.

Priority 3 — Formal leadership approvals: Two policy items (milestone language for POL-01 and payment gate posture for POL-05) still require formal leadership sign-off before they are enforced.

Everything else in this document — the lifecycle model, the state definitions, the ownership matrix, the transition rules, the CompanyCam operating model, the insurance overlay — is designed, documented, and ready to enforce.

What the Team Does Starting Monday

No configuration required. The interim manual protocols in Section 3 describe exactly what each role does at each state right now. Specifically:

• New leads route from GHL for all tracked inbound sources. SPD contacts within the current first-response SLA (2 business hours; leadership may tighten this). For SPD-created leads (referrals, door-knocks), direct Leap entry is the current operating practice — whether this exception is formally confirmed or governed is a pending leadership decision. See Section 7 and Section 12.
• Proposals are built in JobNimbus and logged in Leap after delivery.
• Contracts are signed in Leap. The job record is in Leap from signature forward.
• Build-ready gate — PM reviews the build-ready packet before any job enters the production schedule. The gate criteria are in Section 3, State 6.
• Field photos — taken and tagged in CompanyCam at defined checkpoints. Labels are in Section 9.
• Invoicing — AR Admin issues invoice in Leap. AR ladder begins at issuance.

If any role is unsure of their responsibilities, Section 5 shows ownership by state. The role-based reading guide in Section 1 shows which sections are most relevant for each role.

Where to Navigate for Specific Questions

If you want to know…	Go to
How the full lifecycle works	Section 3 (and the overview in Section 3's introduction)
Who owns each state	Section 5
What the team does right now before automation	The "Interim manual protocol" callout in each state block in Section 3
How software tools interact	Section 8
How photos and CompanyCam work	Section 9
How insurance jobs are handled	Section 10
What the KPIs are and who is accountable	Section 13
What automations are planned and their status	Section 14
How to propose a change to this framework	Section 18

---

How to Read This Framework

Start here. The order of reading is the order of understanding.

What This Document Is

This is the operating system for Locke & Ladder. It defines how every lead moves from first contact to signed contract, how every contract moves from sold work to schedulable backlog, how every job moves from scheduled to completed to invoiced to collected, and how every completed job generates the reviews, referrals, and relationships that make next year easier than this one.

It is not a software configuration guide. Software is covered in Sections 7–9, but only after the lifecycle, the ownership, and the rules have been established. The reason for this order is practical: a team that understands the lifecycle can adapt to any tool. A team that only knows the tools cannot operate when the tools change, fail, or have gaps.

Why Lifecycle Comes Before Software

The most common failure mode in CRM implementation is treating the software as the operating system. The CRM becomes the first subject of every conversation. People argue about fields and pipelines before they agree on what the states mean. Automation is built before ownership is clear. Reports are generated before the underlying definitions are stable.

The result is a system that works as configured but not as intended. Stages mean different things to different people. Automation fires on bad data. Reports produce numbers nobody trusts.

This document reverses that order. Sections 1 through 6 contain no software configuration. They establish what must be true before a single workflow is built.

Two Halves of Every State Block

Each state in Section 3 has two operational halves:

Future-state automation behavior — what the configured system does when workflows are built and confirmed live. This is the designed target.

Interim manual protocol — what the team does today, before the automation exists. This is the current operating instruction.

Both halves matter. A document that only describes the future state is a design spec. A company that only reads the future state and ignores the interim is operating on aspiration. Every state block in Section 3 tells you what the system will do and what you do now.

How to Navigate This Document

Read Sections 1 and 2 first for orientation and terminology. Section 3 is the main document — the full lifecycle from New Lead through Paid & Closed, with both future-state design and current interim protocols. Sections 4 through 6 provide the model rules governing how states, actions, gates, and transitions work. Section 6 covers forward, backward, and lateral transitions. Section 7 covers lead intake in detail. Section 8 covers the software stack. Section 9 covers CompanyCam. Section 10 covers the insurance overlay. Section 11 provides five concrete project walkthroughs — three successful journeys and two exception paths. Section 12 is the validation ledger. Sections 13 through 18 are the operational management and governance system: KPIs, automation register, management cadence, SOP vault governance, AI governance, and change control.

Role-Based Reading Guide

Not everyone needs every section. Start with Section 1 and 2, then go directly to the sections that govern your role.

If your role is…	Read these sections first	Then as needed
SPD (Senior Project Director)	1, 2, 3 (States 1–5), 7, 8	4, 6, 11
Sales Manager	1, 2, 3, 5, 6, 7, 13, 15	4, 12, 14, 18
Production Manager	1, 2, 3 (States 5–10), 5, 6, 9, 13	4, 11, 15
Production Coordinator	1, 2, 3 (States 7–9), 5, 9	6, 11
Crew Lead	1, 2, 3 (States 8–10), 9	11
AR Admin	1, 2, 3 (States 10–12), 10, 13	5, 6
Insurance Coordinator	1, 2, 10, 3 (States 1–12 overlay lane)	6, 11
Ops Systems Owner	1, 2, all sections	14, 16, 17, 18
Leadership	Leadership Brief, 1, 2, 5, 12, 13, 15	3, 8, 18

---

Terminology and Legend

A shared vocabulary prevents disagreement about meaning. These definitions are locked. If a term needs to change, that change is logged in change control and this section is updated.

Term Definitions

Lead — A person or property with potential demand for Locke & Ladder's services. A lead becomes an opportunity once qualification begins. The distinction matters for reporting and routing.

Opportunity — A lead that is actively being worked by an SPD: contact is established, the sales process has begun, and there is a real possibility of a signed contract. In Leap, an opportunity is typically represented as an active lead record under the assigned rep.

Job — A signed contract with a scope of work, a dollar value, a site, and a customer. A job exists the moment the contract is signed. Before that moment, the record is a lead or opportunity, not a job.

State — A durable condition of a lead or job that is objectively true until exit criteria are met. A state must have one accountable owner, testable entry criteria, and testable exit criteria. A state is never an action. It is never aspirational.

Action — A step performed by a person or a system inside a state or during a transition. Actions are how records move. They are not the same as states.

Task — A specific assigned unit of work within a state. A task belongs to a named person and has a due date. Tasks are inside states, not replacements for states.

Milestone — A meaningful point in the progress of a lead or job. Milestones may or may not have enforcement criteria. When they have enforcement criteria, they are gates.

Gate — A milestone with enforcement: the record cannot advance until all gate conditions are verified by the accountable owner. Gates are explicit stops, not aspirations.

Owner — The single accountable role for a given state or gate. There is always one owner. Supporting roles may assist, but the owner is accountable for the outcome and the evidence.

Automation — A system-triggered action caused by an event, condition, or state transition. Automations support humans; they do not replace human judgment at gates.

Exception — A condition where the normal path is not available or not appropriate. Every exception requires a named owner, a documented reason, and a next action. An undocumented exception is an invisible failure.

Evidence — The required fields, documents, photos, signatures, or approvals that prove a state is true or a gate is cleared. Evidence must be reviewable and attributable.

System of record — The canonical system that holds truth for a specific data object at a specific point in the lifecycle. When two systems disagree, the system of record is correct.

Overlay lane — A set of additional fields, tasks, and rules that apply to a specific job type alongside the base lifecycle. Insurance is the primary overlay lane in this company.

Backward transition — A move from a later state to an earlier state, required when conditions that made the later state true are no longer true (e.g., a scheduled job is cancelled and returns to Ready to Schedule).

Lateral hold — A condition where a record stays in its current state due to a blocker, without advancing or retreating. Holds require a named owner, documented reason, and next-action date.

Label Definitions

Role Definitions

Every named role in this document is defined here. If a role is referenced in a state block or governance section, its definition is in this list. New roles added to the framework must be defined here first.

SPD (Senior Project Director) — The field sales representative responsible for lead follow-up, appointment setting, on-site inspections, proposal delivery, contract close, and build-ready packet preparation. The SPD owns States 1 through 5 of the lifecycle and is the primary Leap user during the sales phase. "SPD" is used throughout this document to refer to any individual in this sales rep role regardless of specific title.

Sales Manager — The manager accountable for the sales team's performance, pipeline integrity, and SPD compliance with the lifecycle. The Sales Manager owns the pipeline review cadence, manages escalations from the sales phase, and approves exceptions to the standard sales path.

Production Manager (PM) — The manager accountable for the production phase of the lifecycle (States 6–10). The Production Manager owns the build-ready gate review, approves jobs entering the production schedule, and is accountable for quality review at Job Complete. The PM is the final authority on whether a job is ready to schedule and whether a completed job passes field QC.

Production Coordinator — The role responsible for scheduling confirmed jobs (States 7–8), communicating start dates to crews and customers, and tracking production throughput in the schedule. The Production Coordinator does not own the build-ready gate — that belongs to the PM — but is the first scheduler once the gate is passed.

Crew Lead — The field supervisor responsible for executing the work on site (States 8–10). The Crew Lead owns on-site safety, scope execution, CompanyCam photo compliance at defined checkpoints, and field completion sign-off. The Crew Lead reports to the Production Manager.

AR Admin (Accounts Receivable Administrator) — The role accountable for invoice issuance, payment tracking, and collections (States 11–12). The AR Admin owns the AR ladder from Final Invoice Sent through Paid & Closed. The AR Admin also owns closeout package delivery — the job is not Paid & Closed until the balance is zero AND the closeout package is delivered.

Insurance Coordinator — The role responsible for managing the insurance lifecycle overlay when a job involves a homeowner's insurance claim. The Insurance Coordinator tracks adjuster contacts, Xactimate amounts, mortgage lender holds, and supplement decisions. The Insurance Coordinator works alongside the SPD during the sales phase and the AR Admin during the financial close phase.

Ops Systems Owner — The role responsible for the configuration, governance, and maintenance of the operating systems (Leap, GHL, CompanyCam, SOP Vault). The Ops Systems Owner owns the Consolidated Automation Register, manages VAL item resolution, oversees SOP Vault governance, and is the change-control approver for framework updates. This role may be filled by an internal systems manager or an external implementation partner.

---

Master Lifecycle Overview

The full lifecycle from first lead through paid-and-closed. This is the primary operating reference. Every state block contains both the designed future-state behavior and the interim manual protocol for operating before that configuration is live.

Lifecycle Purpose

Every state in this lifecycle is a declaration of what is objectively true about a lead or job at this moment. Moving a record to the next state means the new state is now true. If it is not true, the record stays where it is and the exception surfaces.

This distinction is the most important governance rule in this document. Stage drift — when "In Production" starts meaning "we talked about it" — destroys the pipeline as an operating instrument. When the pipeline stops reflecting reality, managers manage a fiction, automation fires on garbage, and forecasting becomes guesswork.

State Summary Reference Table

Quick-lookup version. See each full state block below for complete details.

#	State	Plain-language meaning	Owner	Exit trigger
1	New Lead	Intake record exists, is owned, and is receiving a response	SPD (follow-up); Marketing/CSR (intake)	Two-way contact established
2	Appointment Set	Confirmed two-party appointment in Leap: date, time, address, owner	SPD	Inspection occurs
3	Inspection Complete	Inspection happened; outcome logged in Leap	SPD	Proposal delivered to customer
4	Proposal Delivered	Customer received the proposal — not drafted, not internal	SPD	Customer signs
5	Job Awarded	Signed contract. No other definition.	SPD (sign); Sales Mgr (handoff)	Build-ready packet complete and submitted for PM review
6	Preproduction Ready	Scope locked; handoff packet submitted; Build Ready gate (PM approval) controls release to Ready to Schedule	Production Manager	Build Ready gate passed by PM
7	Ready to Schedule	Build-ready approved; eligible for scheduling	Production Coordinator	Start date confirmed; crew committed
8	Scheduled	Confirmed start date and crew commitment exist	Production Coordinator; Crew Lead	Work begins on site
9	In Production	Crew is physically on site executing scope	Crew Lead (field); PM (oversight)	All three completion conditions true
10	Job Complete	Field done + QC done + evidence PM-reviewed. All three.	Production Manager	Invoice authorized
11	Final Invoice Sent	Invoice issued, timestamped, in customer's hands; AR ladder begins	AR Admin	Balance clears; closeout delivered
12	Paid & Closed	Zero balance in Leap AND closeout package delivered	AR Admin; Marketing/CSR	Post-close lifecycle begins

The 12 States

The 12 states are organized into three phases. Each phase has a clear commercial purpose and a clear handoff to the next.

Sales Phase (States 1–5): A lead enters the system, gets contacted and qualified, receives an inspection and a proposal, and either signs a contract or closes out as a non-win.

Production Phase (States 6–10): A signed contract passes through the build-ready gate, gets scheduled, gets built, and closes with a quality review.

Financial Close (States 11–12): The completed job converts to a paid invoice and a delivered closeout package.

SALES PHASE                         PRODUCTION PHASE                     FINANCIAL CLOSE

1. New Lead                         6. Preproduction Ready               11. Final Invoice Sent
2. Appointment Set      ──────►     7. Ready to Schedule     ──────►     12. Paid & Closed
3. Inspection Complete              8. Scheduled
4. Proposal Delivered               9. In Production
5. Job Awarded                     10. Job Complete

Each state is a fact about what is currently true — not an activity, not a goal.

---

How to read each state block

Every state block below follows the same structure. Here is what each field means:

Plain-language meaning — What is actually true about this lead or job while it sits in this state.

State owner — The one person accountable for this state. Supporting roles assist, but accountability doesn't split.

Entry criteria — What must be true before a record can be in this state.

Exit criteria — What must happen for the record to leave this state.

Required fields / evidence — What must exist in the system as proof this state is real.

Allowed and blocked actions — What is permitted and what is explicitly off-limits while in this state.

System of record — Which tool is the authoritative source for this record at this stage.

Automation summary — What the configured system does (future state). All items are marked Pending Config or Tenant Validation Required until confirmed live.

Interim manual protocol — What the team does right now, before the automation is built. This is the current operating instruction.

---

---

State 1 — New Lead

Plain-language meaning: A minimum intake record exists, is owned, and is receiving a response. For inbound leads, a linked Leap lead was created at intake.

State owner: Marketing / CSR for intake quality; assigned SPD for first response.

Entry criteria:

• Contact data sufficient to create a record
• Duplicate policy applied; record is not a known duplicate
• For inbound leads: linked Leap lead created at intake with cross-system IDs

Exit criteria:

• Two-way tracked contact established (contact-established event) → advances toward Appointment Set
• Lead qualifies for disqualification → routes to documented non-won path with owner
• Lead cannot be contacted after SLA period → routes to documented nurture or recycle path

Required fields: Contact name, address, phone, lead source (three-layer taxonomy), assigned owner, lead created timestamp, GHL contact ID, Leap linked lead ID Pending Config.

Required evidence: Source attribution recorded; assignment confirmed; SLA clock running.

Allowed actions: Speed-to-lead outreach; SLA reminder escalations; deduplication review; qualification questions during first contact.

Blocked conditions: Advancing to Appointment Set before two-way contact is established; allowing automated sequences to continue after the customer has replied to a human.

System of record: GHL for inbound leads (pre-contact phase). Leap for manual leads. For inbound leads, Leap holds the linked lead record from minute one.

Automation summary: GHL fires a speed-to-lead sequence immediately on lead creation, sends an acknowledgement, and runs SLA reminders until contact is confirmed. When the customer replies, sequences stop. Leap creates a linked lead at intake and assigns the owner. Pending Config Tenant Validation Required

CompanyCam: Not used at this state.

---

---

State 2 — Appointment Set

Plain-language meaning: A two-party appointment exists in Leap with a confirmed date, time, address, and owner. The appointment was booked after two-way SPD contact. The working system has shifted to Leap.

State owner: Assigned SPD. Sales Manager for SLA visibility and coaching.

Entry criteria:

• Two-way tracked contact confirmed between customer and assigned SPD
• Appointment created in Leap (not a verbal promise — a recorded event) with date, time, address, and owner

Exit criteria:

• Inspection occurs → advances to Inspection Complete
• Appointment no-show or cancellation → triggers recovery workflow; record may return to New Lead or advance based on outcome

Required fields: Appointment date/time, appointment address, assigned SPD, contact-established timestamp, appointment-confirmed status.

Required evidence: Contact-established event logged; appointment record in Leap.

Allowed actions: Appointment confirmation and reminder communications; preparation tasks (pre-inspection research, material lookups); customer-facing pre-appointment communication.

Blocked conditions: Booking the appointment without prior two-way contact; creating the appointment in any system other than Leap after contact is established; GHL running customer-facing sequences after contact-established event.

System of record: Leap. The contact-established event shifts authority from GHL to Leap.

Automation summary: Leap sends appointment confirmation reminders and a day-before reminder. If the appointment passes without an inspection logged, a no-show recovery task fires. GHL receives the narrow writeback (contact-established status, appointment status) and stops all customer-facing sequences. Pending Config Tenant Validation Required

CompanyCam: Not used at this state.

---

---

State 3 — Inspection Complete

Plain-language meaning: The inspection happened and the outcome is logged in Leap. The SPD has evaluated the property and recorded what they found.

State owner: Assigned SPD.

Entry criteria:

• Appointment occurred (inspector was on site or virtual evaluation was completed)
• Inspection outcome logged in Leap (scope noted, customer conversation recorded, next step clear)

Exit criteria:

• Proposal drafted and delivered to customer → advances to Proposal Delivered
• Job determined to be non-viable or customer uninterested → documents outcome and routes to non-won path

Required fields: Inspection date, inspection outcome (scope notes), next action.

Required evidence: Outcome logged in Leap with at least a scope summary and a clear next action.

Allowed actions: Scope assessment; measurement; damage documentation; product recommendation; initial proposal preparation; customer education during or after inspection.

Blocked conditions: Marking Proposal Delivered without first marking Inspection Complete; treating a phone-only conversation as an inspection unless the SOP specifically allows it for that job type.

System of record: Leap.

Automation summary: Leap creates a post-inspection follow-up task and alerts the Sales Manager if no outcome is logged within the defined window. GHL remains suppressed. Pending Config

CompanyCam: Pre-job assessment photos may be taken here, especially for insurance jobs or complex scope. Not required at this state but recommended.

---

---

State 4 — Proposal Delivered

Plain-language meaning: A proposal was delivered to the customer — not drafted, not emailed internally, not "almost ready." Delivered means the customer has received and reviewed it.

State owner: Assigned SPD.

Entry criteria:

• Proposal is complete and final (scope locked, pricing confirmed)
• Proposal delivered to the customer via Leap SalesPro presentation, email, Leap portal, or in-person; currently via JobNimbus until SalesPro pricing is configured

Exit criteria:

• Customer signs → advances to Job Awarded
• Customer declines → routes to documented lost path with reason logged
• No response after follow-up sequence → routes to documented stale path with owner

Required fields: Proposal-delivered timestamp, proposal amount, follow-up schedule, proposal status.

Required evidence: Delivery event recorded (SalesPro proposal sent or opened, email confirmation, or in-person delivery noted).

Allowed actions: Follow-up communications; objection handling; proposal revision if scope changes (resets delivery timestamp if re-delivered); manager coaching on stalled proposals.

Blocked conditions: Marking a proposal "delivered" when it has only been prepared; treating a verbal quote as a delivered proposal unless the SOP specifically allows it.

System of record: Leap.

Automation summary: Leap creates a follow-up task sequence for the SPD and alerts the Sales Manager when a proposal has been stale beyond the defined threshold. GHL is not used at this state. Pending Config

CompanyCam: Not used at this state.

---

---

State 5 — Job Awarded

Plain-language meaning: The customer signed the contract. Not a verbal agreement. Not a handshake. Not a deposit alone. A signed contract. This is the definition, and it is the only definition.

State owner: Assigned SPD for signing; Sales Manager for handoff quality.

Entry criteria:

• Signed contract exists in Leap
• Contract amount is recorded
• Job type (retail or insurance) is confirmed

Exit criteria:

• Build-ready packet complete and submitted for PM review → advances to Preproduction Ready [NOTE: Preproduction Ready is the scope-lock and handoff-complete condition; it is not the same as Build Ready gate approval. The PM-owned Build Ready gate controls release from Preproduction Ready to Ready to Schedule.]

Required fields: Signed contract (document attached), contract amount, job type, deposit status, insurance overlay activation (if applicable).

Required evidence: Signed contract document.

Allowed actions: Build-ready packet preparation; production handoff initiation; deposit collection; insurance overlay activation if insurance job; sales-to-production handoff notification.

Blocked conditions: Advancing to Preproduction Ready without PM approval; scheduling any work before build-ready gate is passed; treating verbal agreement or deposit receipt alone as Job Awarded.

System of record: Leap.

Automation summary: Leap creates a build-ready review task and assigns it to the PM, sends the sales-to-production handoff notification, and initiates a deposit request if not already paid. GHL writeback continues for the four tracked fields; no new customer-facing sequences at this state. Pending Config

CompanyCam: Pre-job photo checklist should be completed now or at latest before Preproduction Ready. A linked CompanyCam project must exist. Pending Config Tenant Validation Required

---

---

State 6 — Preproduction Ready

Plain-language meaning: Scope is locked and the build-ready handoff packet is complete and submitted. The SPD's job is done; the record now sits with the Production Manager for the Build Ready gate review. Preproduction Ready and Build Ready are not the same thing. Preproduction Ready is the scope-lock and handoff-complete condition. Build Ready is the PM-owned gate review that controls release to Ready to Schedule. A job is in Preproduction Ready from the moment the SPD submits the completed packet until the moment the PM either passes or fails the Build Ready gate.

State owner: Production Manager (Build Ready gate approval authority).

Entry criteria (all must be true before entering Preproduction Ready):

• Signed contract and locked scope in Leap
• Confirmed selections and materials in Leap structured fields
• Site constraints and access notes in CompanyCam plus special instructions
• Permit or approval status documented in Leap field
• Deposit received and confirmed in Leap
• Pre-job photo pack in CompanyCam Pending Config Tenant Validation Required
• Insurance release blocker is Clear (if insurance job) Pending Config
• SPD has submitted explicit notification to PM that the build-ready packet is complete and ready for review

Exit criteria:

• PM passes Build Ready gate (all conditions confirmed, no open defects) → advances to Ready to Schedule
• PM finds defects during Build Ready gate review → explicit defect list issued, each defect named with an owner and a deadline; job returns to Job Awarded; re-enters Preproduction Ready only when all defects are resolved and SPD resubmits

Required fields: PM approval timestamp, all build-ready checklist fields complete, insurance blocker status (for insurance jobs).

Required evidence: Pre-job CompanyCam photo pack; completed build-ready checklist (all required items confirmed); PM approval event.

Allowed actions: Gate review by PM; defect identification and assignment; trade-specific artifact verification; insurance addenda review for insurance jobs.

Blocked conditions: Scheduling any work before PM approval; treating "mostly ready" as a passed gate; PM approving readiness for a job they have not actually reviewed.

System of record: Leap + CompanyCam.

Automation summary: Leap notifies the Production Coordinator when the PM approves the gate, sends a defect task to sales for each identified defect, and creates a re-review task when defects are resolved. GHL is not used at this state. Pending Config

CompanyCam: Pre-job checklist must be complete. Job Start checklist section completed with required photos tagged PH-Start and the appropriate trade tag. Project linked to Leap job. Pending Config Tenant Validation Required

---

---

State 7 — Ready to Schedule

Plain-language meaning: Build-ready is approved. The job is eligible to be placed on the production schedule. No work has been committed to a specific date yet.

State owner: Production Coordinator / Scheduler.

Entry criteria:

• Preproduction Ready gate passed and recorded

Exit criteria:

• Start date confirmed and crew committed → advances to Scheduled

Required fields: Build-ready approval date; scheduling queue position.

Required evidence: PM approval on record.

Allowed actions: Capacity planning; crew assignment; materials ordering; scheduling conversation with customer.

Blocked conditions: Starting any field work before advancing to Scheduled.

System of record: Leap.

Automation summary: Leap places the job in the scheduling queue view and notifies the Production Coordinator. GHL is not used at this state. Pending Config

CompanyCam: Not used at this state.

---

---

State 8 — Scheduled

Plain-language meaning: A confirmed start date exists with a committed crew. The customer has been notified. The job is on the calendar as a real commitment, not a placeholder.

State owner: Production Coordinator / Scheduler for maintenance; Crew Lead for execution readiness.

Entry criteria:

• Start date confirmed with customer
• Crew committed and available
• Materials available or confirmed for delivery before start

Exit criteria:

• Work begins on site → advances to In Production

Required fields: Confirmed start date, crew assignment, materials confirmation.

Required evidence: Customer-confirmed appointment; crew assignment logged.

Allowed actions: Pre-start crew preparation; materials staging; customer pre-start communication; weather or logistics rescheduling with customer notification.

Blocked conditions: Allowing a job to remain in Scheduled for more than a defined period without progressing; permitting field work to begin without logging the transition to In Production.

System of record: Leap.

Automation summary: Leap sends start-date reminders to the crew and customer, creates a materials-arrival confirmation task, and can trigger weather-window alerts if configured. GHL may handle pre-start customer communication if that routing decision is confirmed. Pending Config Tenant Validation Required

CompanyCam: Not used actively at this state. Crew Lead should review the pre-job photo pack before start.

---

---

State 9 — In Production

Plain-language meaning: Work is actively underway on site. A crew is physically executing the contracted scope. This state is not "we are thinking about starting" or "materials have been ordered." It means a crew is on the property doing work.

State owner: Crew Lead for field execution; Production Manager for oversight and issue escalation.

Entry criteria:

• Crew is on site and work has begun
• Transition logged in Leap (not left in Scheduled)

Exit criteria:

• All field work done, QC complete, and final evidence package PM-reviewed → advances to Job Complete

Required fields: Start date (actual), crew lead assigned, daily progress log.

Required evidence: Daily CompanyCam progress photos; phase-by-phase checklist sections completed; hidden condition documentation if any abnormal condition discovered; change-order documentation in Leap if scope changes.

Allowed actions: Daily field work execution; CompanyCam documentation by phase; exception escalation by crew lead; PM site visits for QC; change-order identification and documentation.

Blocked conditions: Marking Job Complete before QC is done and evidence is PM-reviewed; hiding change conditions in text messages; treating verbal scope changes as binding without written documentation.

System of record: Leap for job status; CompanyCam for field evidence.

Automation summary: Leap surfaces daily progress visibility, alerts on documentation gaps, and sends a PM review reminder if no progress update is logged for a defined period. GHL is not used during production. Pending Config

CompanyCam: Phase checklists are active throughout this state. Required photo tags: phase tag (PH-Demo, PH-Substrate, PH-DryIn, PH-Install, PH-Detail), trade tag (TR-Roof, TR-Siding, TR-Windows, TR-Gutters), and issue tags (ISS-HiddenDamage, ISS-ChangeOrder) when applicable. PM reviews checklist completion before advancing.

---

---

State 10 — Job Complete

Plain-language meaning: Three conditions are all true: (1) field work is done, (2) QC review is done, (3) final evidence package is complete and PM-reviewed. All three. Not two.

State owner: Production Manager. No one else may advance a job to Job Complete.

Entry criteria (all three must be confirmed by PM):

• Field work is physically complete per contracted scope
• QC review is done and any punch-list items are resolved
• Final evidence package in CompanyCam is complete and PM-reviewed

Exit criteria:

• PM authorizes invoice release → advances to Final Invoice Sent

Required fields: PM completion sign-off timestamp; QC sign-off; evidence-package review date.

Required evidence: Final QC checklist complete in CompanyCam with required photos tagged PH-FinalQC and EV-Completion; PM review logged; any change-order documentation finalized.

Allowed actions: PM evidence review; punch-list follow-up; invoice release authorization; customer closeout package preparation.

Blocked conditions: Issuing a final invoice before PM reviews and approves the evidence package; allowing AR to release invoices without this review completed.

System of record: Leap + CompanyCam.

Automation summary: Leap creates an invoice release task to AR when the PM signs off, and surfaces an incomplete-evidence task to the PM if the job is marked complete with an unfinished checklist. When Job Complete is confirmed and payment clears, a trigger sends the post-close signal to GHL, which routes review request and closeout communications. Pending Config Tenant Validation Required

CompanyCam: Final QC checklist section completed. Closeout Page generated and exported to PDF; checklist PDF exported and stored in project files. Photo gallery or Page available for the customer closeout package.

---

---

State 11 — Final Invoice Sent

Plain-language meaning: The final invoice is issued, timestamped, and in the customer's hands. The AR ladder begins from this moment.

State owner: AR Admin.

Entry criteria:

• PM has authorized invoice release (signed off on final evidence package)
• Invoice created in Leap with correct amount, due date, and payment options

Exit criteria:

• Balance cleared in Leap and closeout package delivered → advances to Paid & Closed

Required fields: Invoice issue date, invoice amount, due date, payment method options, invoice status.

Required evidence: Invoice delivery confirmation (email sent, portal notification, SMS sent).

Allowed actions: AR dunning ladder execution (reminders at defined intervals); dispute classification and routing; payment plan approval process if applicable; stop-work consideration if payment milestone missed during ongoing work; escalation per AR ladder.

Blocked conditions: Issuing an invoice before PM authorization; running AR in any system other than Leap; creating parallel invoices or parallel balances in GHL that conflict with Leap's financial truth.

System of record: Leap. Leap is the single source of financial truth. Invoice amount, balance due, payment status, and due date all live in Leap.

Automation summary: Leap runs the AR reminder sequence at defined intervals (7 days late, 14 days late, 30+ days late) and creates escalation tasks to the Sales Manager and Leadership at defined thresholds. GHL may send invoice delivery messages if that routing decision is confirmed — but GHL must never become a parallel invoice ledger. Leap is the only financial source of truth. Pending Config Tenant Validation Required

CompanyCam: Not used at this state. Evidence is already captured and reviewed.

---

---

State 12 — Paid & Closed

Plain-language meaning: Two conditions are both true: (1) balance is zero in Leap, (2) closeout package has been delivered to the customer. Not one condition. Both.

State owner: AR Admin confirms zero balance; Marketing / CSR confirms closeout package delivery.

Entry criteria:

• Balance confirmed at zero in Leap
• Closeout package delivered: final photos from CompanyCam, scope summary, warranty summary, product care guidance, service contact path

Exit criteria:

• Record enters post-close lifecycle: review request, referral path, long-term nurture — all managed in GHL

Required fields: Payment-cleared timestamp, closeout package delivery confirmation, post-close enrollment flag.

Required evidence: Zero balance in Leap; delivery confirmation for closeout package.

Allowed actions: Review request (via GHL — one system, one ask, no duplicates); referral path initiation; long-term nurture enrollment; service opportunity tracking.

Blocked conditions: Marking Paid & Closed when balance is not zero in Leap; sending review requests before closeout package is delivered; sending review requests from any system other than GHL's designated review engine.

System of record: Leap for financial closeout; GHL for post-close relationship.

Automation summary: When payment clears in Leap, a post-close trigger fires to GHL, which launches the review request workflow, referral path enrollment, and long-term nurture sequence based on job type and installed scope. Leap also creates a closeout package delivery task to the designated owner. Pending Config Tenant Validation Required

CompanyCam: Customer-facing gallery link or Page available for the closeout package. Project archived after closeout.

---

State vs Action vs Task vs Gate

Four concepts that are commonly confused. Conflating them destroys the pipeline as a management instrument.

The Core Distinction

A state is what is true. An action is what is being done. A task is a specific assigned unit of work. A gate is an enforced milestone that cannot be passed without meeting defined conditions.

The confusion happens when states are named as if they are actions. When a stage is called "Sending Proposal" instead of "Proposal Delivered," it is an action label, not a state. Nobody knows when it ends. The pipeline becomes a list of activities rather than a map of current reality.

Definitions with Examples from This Business

State examples:

• New Lead = it is currently true that this contact is an uncontacted lead. It remains true until two-way contact is established.
• Job Awarded = it is currently true that this customer signed a contract. It remains true until the build-ready gate is passed.
• In Production = it is currently true that a crew is actively working this job on site. Not "a crew is planning to start." On site, working.

Action examples:

• Making a call to establish contact (action inside New Lead)
• Delivering a proposal to a customer (action that creates the transition from Inspection Complete to Proposal Delivered)
• Taking pre-job photos in CompanyCam (action inside Job Awarded or Preproduction Ready prep)

Task examples:

• "Send deposit request by tomorrow" — a task assigned to the AR Admin, due date set, inside the Job Awarded state
• "Complete build-ready checklist for the Johnson job" — a task assigned to the Production Coordinator, due inside Job Awarded
• "Call stalled proposal — last contact was 7 days ago" — a task assigned to the SPD, inside Proposal Delivered

Gate examples:

• Build-ready gate at Preproduction Ready: the PM must confirm all six conditions before the job advances. The record cannot skip this gate. If any condition is missing, the job does not advance.
• Evidence gate at Job Complete: the PM must review and approve the final evidence package. Invoice release is blocked until this approval exists.

Why This Matters for Managers

When states are named as actions, managers cannot see what is true. They see activity. They can count "calls made" but cannot answer "how many leads are genuinely uncontacted?" They can see "proposals in flight" but cannot answer "which proposals have actually been delivered?"

When states represent facts, every report answers a real question. Every record without a next action is visible. Every gate failure is an exception, not a surprise.

Why This Matters for Automation

Automation fires on state changes and field values. If the state means "we are doing something" rather than "this is true," automation fires on ambiguous data. A reminder that fires because a record has been in "In Production" for 30 days is useful only if "In Production" reliably means "the crew is currently on site." If it sometimes means "we talked about scheduling," the reminder fires on garbage.

---

Ownership by State

One accountable owner per state. Supporting roles assist but do not share accountability. When accountability is shared, it is owned by no one.

Ownership Map

State	Accountable owner	Supporting roles	Owner's accountability
New Lead	Assigned SPD (follow-up); Marketing/CSR (intake quality)	Sales Manager (SLA enforcement)	First response within SLA; contact-established event logged
Appointment Set	Assigned SPD	Sales Manager (visibility)	Appointment exists in Leap; inspection happens
Inspection Complete	Assigned SPD	Sales Manager (coaching)	Outcome logged in Leap; next action clear
Proposal Delivered	Assigned SPD	Sales Manager (follow-up coaching)	Proposal in customer's hands; follow-up schedule active
Job Awarded	Assigned SPD (signing); Sales Manager (handoff quality)	Production Coordinator (build-ready packet support)	Signed contract in Leap; build-ready packet initiated
Preproduction Ready	Production Manager	Production Coordinator, Sales Rep (defect resolution)	Gate reviewed; every condition verified; defects assigned
Ready to Schedule	Production Coordinator / Scheduler	Production Manager	Job in scheduling queue; no unbounded wait
Scheduled	Production Coordinator / Scheduler; Crew Lead (readiness)	Production Manager	Start date confirmed; crew committed; customer notified
In Production	Crew Lead (field); Production Manager (oversight)	Sales Manager (scope change authorization)	Work executing; evidence captured; issues escalated
Job Complete	Production Manager	Crew Lead (evidence), AR Admin (invoice readiness)	All three completion conditions verified; invoice authorized
Final Invoice Sent	AR Admin	Sales Manager, Leadership (escalation)	AR ladder running; every open invoice has a next action
Paid & Closed	AR Admin (financial close); Marketing/CSR (closeout delivery)	Leadership (exceptions)	Zero balance in Leap; closeout package delivered

Rules for This Table

One owner means one owner. When two names appear in the accountable owner column separated by a semicolon, the first name is accountable for the state and the second is accountable for a specific gate condition within the state. They are not equally accountable for the state.

Supporting roles are not fallback owners. A supporting role assists. The accountable owner is accountable even when support fails.

If a state has no owner, it has no accountability. Review the table periodically. If a role listed here is vacant or doesn't exist yet, leadership must designate an interim owner. An ownerless state is an operational hole.

Insurance overlay jobs have additional ownership. See Section 10.

---

State Transition Rules

What must be true for a record to move between states — including forward, backward, and lateral transitions.

Forward Transition Matrix

From state	To state	Triggering event	Conditions that must be met	Automations (Leap)	Automations (GHL)	Required evidence	Exception approver
New Lead	Appointment Set	Two-way contact established; appointment created in Leap	Contact-established event logged; appointment has date, time, address, owner	Appointment confirmation; SLA clock stops; narrow writeback fires	Sequences suppressed; contact-established status received	Contact record; linked Leap lead	Sales Manager
Appointment Set	Inspection Complete	Inspection occurs and outcome logged	Inspection outcome in Leap; next action set	Post-inspection follow-up task	None	Appointment record	Sales Manager
Inspection Complete	Proposal Delivered	Proposal delivered to customer	Proposal finalized; delivery event in Leap	Follow-up task sequence; stale-proposal alert	None	Inspection outcome on record	Sales Manager
Proposal Delivered	Job Awarded	Customer signs contract	Signed contract in Leap; contract amount recorded; job type confirmed	Build-ready initiation task to PM; deposit request	None	Signed contract document	Sales Manager
Job Awarded	Preproduction Ready	SPD completes build-ready packet and submits for PM review	All required handoff items complete; SPD notifies PM in writing that packet is ready	Build-ready review task assigned to PM	None	Pre-job photo pack; build-ready packet submitted	Production Manager (no exception for production scheduling before Build Ready gate is passed)
Preproduction Ready	Ready to Schedule	PM passes Build Ready gate (completes gate review and approves)	All six build-ready conditions confirmed by PM; no open defects	Ready-to-schedule notification; scheduling queue entry	None	PM approval; completed build-ready checklist	Production Manager
Ready to Schedule	Scheduled	Start date confirmed with customer and crew committed	Customer notification sent; crew assignment logged; materials confirmed	Start-date reminder sequence; crew prep notification	Pre-start customer message (if configured)	Build-ready approval on record	Production Manager
Scheduled	In Production	Crew arrives on site and work begins	Start logged in Leap; crew lead on site	Daily progress visibility activated	None	Confirmed start date	Production Manager
In Production	Job Complete	PM reviews all three completion conditions	Field work done; QC done; final evidence package PM-reviewed	Invoice release task to AR; closeout package task	Post-complete trigger if Paid & Closed event fires	Final QC checklist in CompanyCam; PM sign-off	Production Manager (no exception for invoice release without review)
Job Complete	Final Invoice Sent	PM authorizes invoice release	PM sign-off exists; invoice created in Leap with correct amount and due date	AR ladder begins; Day 7/14/30 reminder tasks	Invoice delivery message (if GHL used for comms)	PM completion sign-off; final evidence package	Production Manager
Final Invoice Sent	Paid & Closed	Balance clears to zero in Leap; closeout package delivered	Zero balance in Leap confirmed; closeout package delivery confirmed	Paid & Closed event; post-close trigger to GHL	Review request workflow; nurture enrollment	Payment record; closeout delivery confirmation	AR Admin; Leadership for payment plan exceptions

Backward and Lateral Transition Rules

Real operations are not always linear. Jobs are cancelled, put on hold, returned for rework, or suspended. Every non-forward transition requires a named owner, a documented reason in Leap, and a next action with a due date.

Cancellation from Scheduled → Ready to Schedule

Triggering event: Job in Scheduled state is cancelled by customer or by Locke & Ladder before work begins.

Conditions for the backward transition:

• Cancellation reason documented in Leap
• Customer notified in writing
• Crew and materials orders cancelled or redirected
• Recovery path documented (reschedule attempt or lost path with reason)

Owner: Production Coordinator initiates; Sales Manager approves if customer-originated; Leadership approves if contract terms affect the cancellation.

Backward path options:

• Customer requests reschedule: record returns to Ready to Schedule; original PM approval remains valid unless scope changed; new start date required before advancing to Scheduled
• Customer cancels entirely: record routes to non-won path with reason; contract status updated in Leap

Evidence required: Written cancellation documentation in Leap; customer notification on record.

---

Suspension from In Production → Scheduled (or Ready to Schedule)

Triggering event: Active production job must be suspended mid-execution (weather event requiring multi-day delay, materials unavailability, safety concern, customer-requested stop, or scope dispute requiring resolution before continuation).

Conditions for the backward transition:

• Suspension reason documented in Leap by Production Manager
• Site security and weather protection measures documented in CompanyCam (if applicable)
• Crew notified; crew removed from site
• If scope dispute: dispute owner named and resolution timeline set

Owner: Production Manager for weather and logistics; Leadership sign-off for scope disputes or contract-related holds.

Backward path options:

• Short suspension (materials delay, weather): record returns to Scheduled with new start date; crew held for this job
• Extended suspension (dispute, customer hold): record may return to Ready to Schedule; PM must re-confirm build-ready conditions before advancing to Scheduled again if significant time has elapsed

Evidence required: Suspension reason and action in Leap; site-protection photos in CompanyCam if weather or safety involved.

---

Build-Ready Defect Return from Preproduction Ready → Job Awarded

Triggering event: PM identifies defects during build-ready gate review.

Conditions:

• Explicit defect list in Leap — each defect named with an owner and a deadline
• Job stays in Job Awarded; does not advance until every defect is resolved
• PM schedules re-review after defects are marked resolved by their owners

Owner: Production Manager for re-approval; Sales Rep or Production Coordinator for defect resolution (per defect owner assignment).

Evidence required: Defect list in Leap with timestamps; resolution confirmation for each defect; PM re-approval event.

---

Contract Void from Job Awarded → non-won path

Triggering event: Signed contract is voided after signing but before production begins (customer exercises cancellation right, mutual agreement, unresolvable dispute, or failed contingency on insurance job).

Conditions:

• Contract void documented in Leap with reason
• Deposit disposition documented (refunded, retained, or disputed — per the financial policy)
• Leadership sign-off required if deposit is retained
• Insurance overlay deactivated if applicable

Owner: Sales Manager for standard voids; Leadership for contested voids.

Evidence required: Void documentation in Leap; customer notification on record; deposit disposition recorded.

---

Lateral Hold — Any State

Triggering event: A blocker condition prevents the record from advancing without the record needing to move backward. The record stays in its current state.

Conditions for a valid hold:

• Blocker type documented in Leap
• Named blocker owner responsible for resolution
• Next-action date set; hold reviewed at least weekly
• No record may remain on hold beyond 14 calendar days without a leadership-reviewed exception

Examples:

• Insurance release blocker: insurance_release_blocker_status = Blocked — record stays in current lifecycle state; insurance fields track the specific blocker reason
• Materials delay after build-ready approval: record stays in Ready to Schedule with a hold note; coordinator tracks expected materials arrival
• Customer-requested timing hold in Scheduled: record stays in Scheduled; new start date set when customer clears hold

Evidence required: Hold reason and next-action date documented in Leap; weekly exception review by the state owner.

Exception Handling Rules

Every exception from the normal transition path requires three things: a named owner, a documented reason visible in Leap, and a next action with a due date. An exception without documentation is a decision someone made that no one can audit.

The Production Manager may not approve exceptions at the gates they own — specifically, the Preproduction Ready gate and the Job Complete evidence gate — by simply bypassing the gate requirements. If the PM wants to override a gate, the override is documented as an exception with leadership sign-off.

---

Lead Intake Architecture

Every lead that enters the system must be owned, clean, and receiving a response within minutes. This section defines how — including what to do today for channels whose transport paths are not yet confirmed.

The Two Entry Paths

Inbound leads arrive through any tracked intake channel — web forms, third-party platforms, paid advertising, or referral platforms. They enter GHL. At intake, a linked Leap lead is created. Both systems hold the record from minute one.

SPD-created leads — referrals, self-generated conversations, door-knocks — are currently created directly in Leap by the assigned SPD. Whether this is a confirmed, governed exception to the GHL-first intake path or an unconfirmed operating practice is a pending leadership decision. Until leadership formally confirms this exception and defines how it is governed (source attribution, deduplication, GHL record creation or not), treat SPD-created lead entry as current practice but not as proven, formally adopted intake architecture. Leadership Decision Required

Required Intake Fields (All Leads)

Field	Required	Why
Contact name	Yes	Identity
Property address	Yes	Serviceability and routing
Primary phone	Yes	Contactability
Lead source — tier 1 (attribution source)	Yes	Platform or channel that generated the lead
Lead source — tier 2 (business source)	Yes	Marketing category (paid, organic, referral, door-knock)
Lead source — tier 3 (campaign detail)	When available	Specific ad, campaign, or referral relationship
Lead created timestamp	Yes	SLA measurement start
Assigned owner or queue	Yes	Accountability from minute one
GHL contact ID	Yes (inbound)	Cross-system linkage
Leap linked lead ID	Yes (inbound)	Cross-system linkage Pending Config Tenant Validation Required
Job type (retail / insurance)	On confirmation	Activates the correct operating lane

Speed-to-Lead Standard

The current standard is a first human attempt within 2 business hours of lead creation for inbound leads during business hours. After hours, the SLA clock restarts at the beginning of the next business day, but automated acknowledgement must fire immediately.

Deduplication Rules

No lead is auto-merged without a human confirmation. Auto-merge errors corrupt attribution and follow-up history in ways that are difficult to unwind. Deduplication requires a human review queue where suspected duplicates are confirmed by a designated owner before merge. The merge cannot happen silently.

Source Normalization Rules

Lead source must use the three-layer taxonomy (attribution source, business source, campaign detail). Free-text source notes are not source attribution — they are noise. Every inbound channel must have a defined, consistent source label before going live.

Lead Channel Inventory

Channel	Transport path to GHL	Status	Interim manual protocol if transport not confirmed
Company website contact form	GHL native form or web form embed with GHL API connection	Tenant Validation Required	CSR checks email inbox or form notification daily; manually creates GHL contact and Leap lead with source attribution
Company website estimate request form	Same as above	Tenant Validation Required	Same as above
Facebook Lead Ads	GHL has a Facebook Lead Ads integration; native connector	Tenant Validation Required	Leads delivered by email notification; CSR manually enters into GHL and Leap within SLA window
Google Local Services Ads	GHL has LSA integration; must be confirmed in tenant	Tenant Validation Required	LSA leads delivered to LSA dashboard; CSR enters into GHL and Leap daily; source tagged as Google LSA
Roofing Calculator / Instant Roofer	Native transport path to GHL is not confirmed. These platforms have their own lead delivery mechanisms (email, webhook, CRM integrations) that vary by account setup and tier.	Validate-External — Do not assume this creates a GHL record automatically	Leads arrive by email to a designated inbox; CSR enters into GHL and Leap within 30 minutes of receipt; source attribution preserved from the platform's notification email; this process continues until transport path is confirmed live
HomeBuddy	Native transport path to GHL is not confirmed. HomeBuddy has partner program agreements and delivery mechanisms that require configuration.	Validate-External — Do not assume this creates a GHL record automatically	Same as Roofing Calculator — designated inbox, manual entry, source preserved
Google Business Profile (organic calls/messages)	Call tracking through GHL phone number if GHL number is published; organic form submissions if GHL form is embedded	Tenant Validation Required	Calls answered by CSR or voicemails transcribed; CSR creates GHL contact and Leap lead; source = Google Organic
Yelp, Angi, HomeAdvisor	Lead delivery mechanisms vary by platform and account tier; not confirmed as native GHL integrations	Validate-External — Verify per platform	Each platform sends lead notifications to a designated email; CSR enters into GHL and Leap same day; source attribution preserved per platform
Referrals (SPD-sourced)	SPD creates lead directly in Leap at time of referral conversation	Leadership Decision Required — Direct-to-Leap entry for SPD-created leads is current operating practice; whether this exception is formally confirmed, how it is governed, and whether a GHL record should also be created are unresolved. See Section 12.	SPD creates Leap lead same day with source attribution; Sales Manager confirms no GHL record conflict exists
Door-knocks (SPD-sourced)	SPD creates lead directly in Leap same day	Leadership Decision Required — same as referrals above	SPD creates Leap lead same day with source attribution; Sales Manager confirms no GHL record conflict exists

Owner at Intake

Inbound leads that arrive in GHL are assigned based on the current routing hierarchy: relationship context first (existing active customers, then existing completed customers), then referral/partner source, then insurance/storm-fit classification, then geography and workload balancing. Geography-first is not the current intended routing order. The actual live routing rules in GHL must be exported and confirmed — the hierarchy above reflects current design intent in the compiled operating system, not confirmed live automation. Tenant Validation Required The assigned SPD is accountable from assignment. Marketing / CSR is accountable for intake data quality. Sales Manager is accountable for SLA enforcement.

SPD-created leads (referrals, door-knocks) are currently created and owned by the creating SPD from minute one. Whether this exception path is formally confirmed and how it is governed remains a pending leadership decision. Leadership Decision Required

What Lives Where at Intake

Data object	GHL	Leap
Inbound lead record	Primary intake record	Linked lead created at intake
Contact information	Yes	Yes (linked)
Source attribution	Yes (authoritative)	Yes (mirrored)
Speed-to-lead sequences	Yes (GHL runs these)	No
Owner assignment	Yes (GHL assigns)	Yes (Leap mirrors assignment)
Post-contact rep workspace	No (sequences stop)	Yes (Leap takes over)
Appointment booking	No (after contact)	Yes
Financial data	No	Yes (authoritative)

---

Software Stack

Five tools. Each has a specific role. Each has boundaries. Misuse of any one creates operating failure.

Why System Boundaries Matter

When two systems both claim to own the same data, the result is always the same: duplicate truth, invisible exceptions, and accountability fog. Boundary discipline is not a software preference. It is the only way to keep the pipeline readable and the data trustworthy.

---

Leap CRM

The role it plays: The primary operational system of record from the moment two-way contact is established through the final collection event. Leap owns the rep workspace, qualification, appointment booking, job record, production status, invoicing, AR, and financial truth.

What it is the system of record for: Post-contact lead and opportunity record; all appointment booking after contact-established event; job record from signed contract through payment; production stage and status; invoice amount, balance due, payment status, due date; build-ready gate documentation; stage progression and stage gating.

What it is explicitly not the system of record for: Pre-contact speed-to-lead and first response (GHL owns this); field photo evidence (CompanyCam owns this); post-close review requests and long-term nurture (GHL owns this); marketing attribution (GHL owns this); estimates and proposals before SalesPro is live (currently JobNimbus handles this as an interim tool).

Key validated behaviors: Delivers invoices by email, text, and homeowner portal; accepts debit, credit, and ACH. Supports stage progression automation and stage locking concepts. Tenant Validation Required Supports creating material and work orders from proposals. Provides production planning with crew-facing job information. Supports Leap Pay for payment processing. Tenant Validation Required CompanyCam integration allows linking a Leap job to a CompanyCam project and viewing/saving CompanyCam photos within the Leap job record.

Current validation gaps: Stage lock enforcement behavior in the live tenant is not confirmed. Tenant Validation Required AR dunning ladder capability — configurable reminder timing and automatic escalation tasks — is not confirmed in this tenant. Tenant Validation Required Leap-GHL integration mechanism is not confirmed. Tenant Validation Required QuickBooks Online integration specifics must be confirmed.

Major misuse risks: Using Leap as a photo system. Building stage progression without first defining stage-lock behavior. Allowing any other system to hold parallel financial records.

---

Leap SalesPro

The role it plays: The adopted digital proposal and estimating tool for SPDs. SalesPro is the designed future-state system for building and delivering all customer-facing proposals. It is not yet live — the current blocker is pricing configuration.

What it does: SalesPro is a mobile-first field presentation and proposal tool that runs inside the Leap ecosystem. Key capabilities include:

• Price book and estimating: Proposals are built from a configured price book containing trade pricing, product catalog, and package structures. SPDs select products, quantities, and packages to build a proposal — no manual pricing calculation.
• Interactive customer presentation: Proposals are presented directly to the customer from an iPad or mobile device, with product options, visualizations, and pricing visible in real time.
• Electronic signature: SecureSign captures the customer's signature on the proposal electronically, in the field. A signed SalesPro proposal creates or updates the corresponding Leap job record automatically.
• Aerial measurement integration: SalesPro connects to EagleView and GAF QuickMeasure for aerial measurement data that populates material quantities directly into the proposal, reducing manual measurement entry.
• Multi-trade proposals: A single SalesPro proposal can cover multiple trades (e.g., roof + gutters + siding). Scope and pricing are itemized per trade within one customer-facing document.
• Change orders: Scope changes during production can be documented and priced as formal change orders in SalesPro, maintaining a clean financial record in Leap.

What it is the system of record for: All final proposals and signed contracts, once SalesPro is live. Signed proposals flow into Leap job records.

Current status — adopted, pending pricing configuration: SalesPro is the confirmed proposal tool for Locke & Ladder. It is not yet live. The current blocker is that all trade pricing, product options, and package structures must be validated and loaded into SalesPro before it can be used for live proposals. Until pricing is confirmed and loaded, all estimates and proposals run through JobNimbus (see below). Do not treat SalesPro as live. Do not run parallel proposals in both SalesPro and JobNimbus.

When the transition happens: When the pricing configuration is confirmed complete and tested, all proposal and estimating activity moves to SalesPro. JobNimbus is retired at that point. There is no partial-adoption period — the cut-over is a clean switch.

Major misuse risks: Building proposals in SalesPro before pricing is fully configured and validated — bad pricing loaded early produces customer-facing errors. Running SalesPro and JobNimbus in parallel after the cut-over, which creates duplicate proposal records and financial confusion.

---

JobNimbus (Interim Estimating Tool)

The role it plays: Current interim tool for estimates and proposals. JobNimbus is in use for all estimates while SalesPro pricing is being configured. It is a temporary production tool, not a permanent system of record.

What it handles right now: SPDs build and deliver all estimates and proposals through JobNimbus. Proposals are emailed or shared from JobNimbus, and delivery is logged manually in Leap. Once a customer signs, the job record lives in Leap — JobNimbus is not the source of truth for signed contracts or job records.

What it is explicitly not: Not integrated into the lifecycle architecture. Not the permanent proposal system. Not a system of record for any financial data that matters beyond the estimate itself. JobNimbus records do not need to be migrated into SalesPro — the cut-over is forward-looking.

When it goes away: When SalesPro pricing is confirmed complete and tested, JobNimbus use stops. No estimates or proposals should be created in JobNimbus after that point.

Major misuse risks: Treating JobNimbus as a permanent tool and building workflows around it. Allowing JobNimbus to accumulate financial data that creates confusion when the cut-over to SalesPro happens.

---

GoHighLevel (GHL)

The role it plays: Inbound lead intake orchestration, speed-to-lead execution, first response automation, linked-lead creation trigger, post-close communications, review request engine, and long-term customer nurture.

What it is the system of record for: Inbound lead intake and source attribution (pre-contact phase); speed-to-lead sequences and first response; post-close review requests and nurture sequences; marketing attribution data.

What it is explicitly not the system of record for: Post-contact rep workspace (Leap owns this); appointment booking after contact-established event (Leap owns this); job record, production status, or financial data (Leap owns this); AR ledger — GHL must not become a parallel invoice system.

Key validated behaviors: Supports creating and sending invoices via email/text and tracking invoice status. Supports workflow triggers based on invoice status changes. Invoice reminder behavior has known constraints: reminders configured after a reminder period starts do not apply retroactively to already-overdue invoices. Supports contact-tag-based workflow triggers. Review request automation is available as a native workflow action. Campaigns and Triggers are deprecated; Workflows are the correct automation layer. Supports Facebook Lead Ads integration (must be confirmed in this tenant).

Current validation gaps: GHL-to-Leap linked-lead creation mechanism is not confirmed. Tenant Validation Required Narrow writeback from Leap to GHL (four fields only) — mechanism not confirmed. Tenant Validation Required Contact-established detection is not confirmed. Tenant Validation Required Facebook Lead Ads integration active status in this GHL tenant is not confirmed. Tenant Validation Required

Major misuse risks: Running AR inside GHL in parallel with Leap, creating two competing financial truths. Allowing GHL sequences to continue after two-way contact is established. Using GHL as the post-contact appointment or job management system.

---

CompanyCam

The role it plays: Field evidence capture, proof-of-work documentation, phase-based QC, and customer-facing closeout package support.

What it is the system of record for: Field photos organized by phase and trade; phase-based checklists and checklist completion; QC sign-off evidence; closeout photo deliverable to customer.

What it is explicitly not the system of record for: Lifecycle stage or job status (Leap owns this); invoice data or financial information (Leap owns this); scheduling (Leap owns this).

Key validated behaviors: Supports project templates including checklist templates, report templates, and pages templates. Supports checklist fields configured as required-photo fields. Supports project labels (project-level) and photo/video tags (photo-level) as distinct organizational tools. Supports exporting checklists to PDF and storing the exported file as a project document. Supports Pages for structured narrative deliverables exportable to PDF. Supports sharing via gallery links and project timeline links with access controls. Supports date/time and GPS coordinate stamps on photos. Supports integration with Leap: auto-creates a CompanyCam project when a Leap job is created (if the CompanyCam option is checked); syncs after job creation; photos viewable in Leap job record; "Save In Job" step required before photos are usable in Leap estimating or invoicing. Project Groups (for grouping multiple projects) are an Elite-tier feature only; not available on Basic, Pro, or Premium. Gallery links cannot be deactivated by users; deactivation requires contacting CompanyCam support.

Current validation gaps: CompanyCam plan tier must be confirmed. Tenant Validation Required Whether CompanyCam project templates are automatically applied when projects are created via the Leap integration must be confirmed. Tenant Validation Required Checklist completion rate tracking and export capability must be confirmed against the actual plan. Tenant Validation Required

Major misuse risks: Taking photos without required tags, making them unsearchable and unusable for QC review, dispute defense, or customer packages. Treating "photos are in CompanyCam" as equivalent to "evidence is organized and reviewed." Skipping the "Save In Job" step in Leap. Using CompanyCam as a scheduling or lifecycle management tool.

---

---

Operating Maps and Control Tables

The maps and tables below turn framework rules into auditable operating controls. Each map has one job: make a specific type of ambiguity harder to maintain. Where a map marks a behavior as unconfirmed, that behavior is not operational — regardless of how clean the diagram looks.

Standalone map files live in maps/. This section embeds the current versions for in-document reference.

---

8A.1 Lifecycle State Map

Shows the 12-state forward path, approved backward transitions, and the lateral hold concept. Use to confirm whether a record is genuinely in its claimed state — not just visually placed there.

_See Section 3 (state definitions) and Section 6 (forward, backward, and lateral transition rules)._

---

8A.2 System Boundary Map

Shows system-of-record zones and authorized data flows. Leap is the sole financial SOT. No system may hold parallel invoice, balance, or payment data.

_See Section 8 (software stack) and Section 7 (lead intake architecture)._

---

8A.3 Integration Event Map

Shows the 5 integration events connecting GHL, Leap, CompanyCam, and SalesPro, with validation status per event. Events marked Tenant Validation Required are design intent — not confirmed live behavior.

_See Section 12.4 (P1 validation items) and Section 14 (consolidated automation register)._

---

8A.4 Ownership Map

Resolves "who owns this state right now" without reading the full state blocks. One accountable owner per state. Supporting roles assist — they do not share accountability.

State	State Owner	Supporting	Gate Approver	Exception Approver
1 New Lead	SPD (follow-up); Marketing/CSR (intake quality)	Sales Manager (SLA)	No gate	Sales Manager
2 Appointment Set	Assigned SPD	Sales Manager	No gate	Sales Manager
3 Inspection Complete	Assigned SPD	Sales Manager	No gate	Sales Manager
4 Proposal Delivered	Assigned SPD	Sales Manager	No gate	Sales Manager
5 Job Awarded	Assigned SPD (signing); Sales Manager (handoff quality)	Production Coordinator	No gate	Sales Manager
6 Preproduction Ready	Production Manager	Production Coordinator; SPD (defect resolution)	Production Manager (Build Ready gate)	Leadership — PM may not self-override
7 Ready to Schedule	Production Coordinator	Production Manager	No gate	Production Manager
8 Scheduled	Production Coordinator (scheduling); Crew Lead (execution readiness)	Production Manager	No gate	Production Manager
9 In Production	Crew Lead (field); Production Manager (oversight)	Sales Manager (scope change)	PM approves exit via Evidence gate	Leadership
10 Job Complete	Production Manager — sole authority	Crew Lead (evidence); AR Admin (invoice readiness)	Production Manager (Evidence gate — all 3 conditions)	Leadership
11 Final Invoice Sent	AR Admin	Sales Manager (Day 14); Leadership (Day 30)	No gate	AR Admin (standard); Leadership (payment plans)
12 Paid & Closed	AR Admin (zero balance); Marketing/CSR (closeout delivery)	Leadership	No gate	Leadership

Split-ownership notes: State 1 — intake quality (Marketing/CSR) and first response (SPD) are different jobs. State 12 — both conditions required simultaneously; AR Admin confirms zero balance → notifies Marketing/CSR → CSR delivers closeout and logs in Leap.

_See Section 5 (base ownership table) and all state blocks in Section 3._

---

8A.5 Gate Enforcement Map

Two named gates control lifecycle movement. Neither is confirmed enforced in the live tenant. Manual fallbacks are mandatory until tenant validation is complete.

Gate	Controls	Required conditions	Evidence	Approver	Live enforcement
Build Ready gate	Preproduction Ready → Ready to Schedule	6 universal: scope locked; materials confirmed; site constraints noted; permit status documented; deposit received; pre-job CC photo pack complete. Plus insurance addenda if applicable: claim decision received; supplement resolved; deductible confirmed; payor type confirmed; insurance_release_blocker_status = Clear (or Monitor with PM + Leadership sign-off); insurance doc pack complete.	Completed build-ready checklist; pre-job CC photo pack with PH-Start tag; PM approval timestamp in Leap; insurance fields if applicable	Production Manager	Tenant validation required [P1-D, P1-E]. Manual fallback: PM written approval to Production Coordinator is the gate until system enforcement is confirmed.
Evidence gate	In Production → Job Complete AND Job Complete → Final Invoice Sent	All 3: (1) field work physically complete, (2) QC done and punch-list resolved, (3) final evidence package in CompanyCam complete and PM-reviewed. All change-orders finalized in Leap.	Final QC checklist complete in CC with PH-FinalQC + EV-Completion tags; PM sign-off logged in Leap; change-orders finalized	Production Manager — sole authority	Tenant validation required [P1-F]. Manual fallback: PM explicit written authorization to AR Admin before any invoice issues.

Insurance release blocker (insurance jobs only): insurance_release_blocker_status = Clear / Monitor / Blocked. Blocked prevents build-ready approval and scheduling. Valid blocker reasons: Claim Decision Pending · Scope Mismatch · Supplement Pending · Lender Path Unknown · Deductible Not Collected · Documentation Missing · Carrier Correspondence Unresolved · Manager Exception. Live enforcement: Tenant validation required.

Exception rule: All gate exceptions require a named owner, documented reason in Leap, and a next action with a due date. PM may not self-override any gate they own. Leadership sign-off required for any exception.

_See Section 3 (States 6 and 10), Section 6 (gate transition rules), Section 10 (insurance overlay), and Section 12.4 (P1-D, P1-E, P1-F)._

---

8A.6 Validation Status Map

Compressed view of what is confirmed, what is design intent, and what still requires proof. Does not replace Section 12.

Status key: Confirmed = safe to operate from. Partially confirmed = directional but not proven in live tenant. Tenant validation required = not operational until tested. Leadership decision required = software cannot resolve. Legal review required = cannot deploy without counsel. Refuted = do not use.

Confirmed

Item	Operational meaning
12-state lifecycle names and definitions	Safe to use as operating vocabulary. Verify Leap stage names match exactly.
Preproduction Ready ≠ Build Ready gate	Do not advance to Ready to Schedule without PM gate approval.
Paid & Closed = zero Leap balance AND closeout delivered (both)	Neither condition alone closes the record.
System boundary: GHL pre-contact; Leap post-contact + financial SOT; CompanyCam field evidence	Safe to enforce as boundary rule.
Leap is sole financial SOT	No other system may hold a parallel invoice ledger.

Partially confirmed

Item	Confidence	Note
Job Complete = field done + QC done + evidence PM-reviewed (all 3)	High	Verify stage movement and QC trigger in live Leap.
Narrow writeback — 4-field contract (Leap → GHL)	Medium	Design intent; do not assert as proven until middleware export confirms.
SalesPro adopted; pricing config is current blocker; JobNimbus is interim	Medium	No parallel proposals. Clean cut-over when pricing ready.

Tenant validation required — P1 (blocks system build)

ID	Item	What breaks if missing	Owner
P1-A	GHL-to-Leap linked-lead creation	Intake spine breaks; duplicate Leap entries; broken cross-system IDs	Systems Owner
P1-B	Leap-to-GHL narrow writeback (4 fields only)	GHL continues pre-contact automation after human relationship exists	Systems Owner
P1-C	Contact-established event recording and suppression	Bot harassment after human contact; false contact-rate reporting	Sales Manager + GHL Admin
P1-D	Leap stage-lock enforcement in live tenant	Gates become advisory; dashboards unreliable	Systems Owner + PM
P1-E	Build Ready gate enforcement in live Leap	Sold jobs hit scheduling before ready	PM + Systems Owner
P1-F	Evidence gate enforcement — invoice held without PM sign-off	Invoices go out before proof exists; disputes harder to defend	AR Admin + PM

Tenant validation required — P2

Item	Owner
Insurance overlay fields deployed in live Leap tenant	Systems Owner + PM
CompanyCam plan tier	CompanyCam Admin
CompanyCam project auto-create via Leap	CompanyCam Admin + Systems Owner
Post-close trigger reliability (Paid & Closed → GHL)	GHL Admin + AR Admin
GHL routing rules live configuration	Sales Manager + GHL Admin
GHL Facebook Lead Ads integration status	GHL Admin
Website form-to-GHL transport	GHL Admin + Web Admin
HomeBuddy transport path to GHL	Marketing Ops + Systems Owner
Instant Roofer / Roofing Calculator transport path to GHL	Marketing Ops + Systems Owner

Leadership decision required

Item	Priority
Payment term specificity (deposit %, stop-work, late fees)	P1
AI consent mechanism for customer-facing AI	P1
Invoice delivery channel: GHL vs Leap	P1
SPD-created lead entry path (referrals, door-knocks)	P2
SOP vault platform selection	P2

Legal review required

Item	Priority
Review policy compliance (gating, incentives, sentiment filtering)	P1
Payment-term enforcement language (late fees, interest, lien notices)	P1
AI-assisted call recording consent, disclosure, and retention	P1

Refuted

Prior claim	Correct status
Manual / SPD-created leads bypass GHL	Refuted — leadership decision required
Speed-to-lead SLA = 5-minute standard	Refuted — current SLA is 2 business hours

_See Section 12 (full validation ledger with evidence summaries, P1 remediation protocols, and validation procedure appendix)._

---

8A.7 Configuration Proof Map

For each unconfirmed item, defines the exact proof artifact and test procedure needed. "We think the workflow is live" is not proof.

P1 items — must confirm before system build

ID	Item	Proof required	System to inspect	Owner
P1-A	GHL-to-Leap lead creation	Submit test lead from each source. Confirm single Leap record created; GHL contact ID written to Leap; Leap ID written to GHL. Capture time-to-create and error logs.	GHL Workflows; middleware; Leap contact record	Systems Owner
P1-B	Leap-to-GHL narrow writeback	Export Leap webhook and GHL inbound workflows. Run stage-change tests; confirm exactly 4 fields updated in GHL. Test idempotency.	Leap webhook/API; middleware; GHL contact record	Systems Owner
P1-C	Contact-established event	Define authoritative field name. Test qualifying events (answered call, two-way SMS/email). Test non-qualifying (voicemail only). Confirm sequences suppressed on qualifying event.	GHL contact record; GHL workflow suppression settings; Leap contact record	Sales Manager + GHL Admin
P1-D	Leap stage-lock enforcement	Create test record with missing required tasks; attempt to advance. Document blocking behavior. Repeat by user role.	Leap stage config; workflow settings; permissions by role	Systems Owner + PM
P1-E	Build Ready gate enforcement	Test PM-only approval stage for Preproduction Ready → Ready to Schedule. Confirm defect task fires to SPD when PM returns a job.	Leap Preproduction Ready stage settings; approval-stage config; defect task automation	PM + Systems Owner
P1-F	Evidence gate enforcement	Test 1: attempt Job Complete without CC QC checklist complete. Test 2: attempt invoice issue without PM sign-off. Document actual blocking behavior.	Leap job record → invoice creation; CC checklist completion; PM sign-off event	AR Admin + PM

P2 items — confirm before dependent configuration

Item	Proof required	System to inspect	Owner
CompanyCam project auto-create via Leap	Create test job with CC checkbox. Confirm CC project created; linked to Leap job; template applied.	Leap job creation; CC project list; CC admin template settings	CompanyCam Admin + Systems Owner
Post-close trigger path to GHL	Advance test job to Paid & Closed. Confirm GHL receives trigger; review request launches; nurture enrollment fires.	Leap Paid & Closed event; middleware; GHL workflow trigger	GHL Admin + AR Admin
Insurance overlay fields in live Leap	Export custom fields, job types, and insurance stages from Leap admin. Confirm each required field exists.	Leap → Settings → Custom Fields; Job Types	Systems Owner + PM
CompanyCam plan tier	Check Billing → Pricing Plans. Confirm plan tier and checklist template capability.	CompanyCam admin: Billing → Pricing Plans	CompanyCam Admin
GHL routing rules	Export GHL Workflows → assignment actions. Compare to intended routing hierarchy (relationship first).	GHL Workflows → assignment actions	Sales Manager + GHL Admin

Manual fallbacks — if P1 items cannot be confirmed before operations

P1 item	Manual fallback
P1-A (lead creation)	Marketing/CSR creates Leap lead manually same business day; enters GHL contact ID; logs exception
P1-B (narrow writeback)	Daily manual writeback queue; GHL workflows key only off manually confirmed fields
P1-C (contact-established)	Human owner sets boolean only on confirmed qualifying events; Sales Manager reviews daily exceptions
P1-D (stage lock)	PM-owned approval-only stage advancement; daily exception queue for bypass attempts
P1-E (Build Ready gate)	Scheduling board restricted to PM-approved jobs; PM written approval required regardless of system lock
P1-F (Evidence gate)	Invoice-send rights restricted to AR Admin; PM written QC release required before sending; audit weekly

_See Section 12.4 (P1 remediation protocols) and Section 12.5 (validation procedure appendix)._

---

8A.8 Field Governance Map

Source, SOT, sync direction, and validation status for every field driving automation, gate enforcement, or KPI reporting. If a field is not defined and owned, it should not trigger anything.

Sync direction: → = one-way write. ↔ = bidirectional mirror. No sync = field stays in its SOT only.

Cross-system identity

Field	SOT	Allowed sync	Required for	Status
GHL contact ID	GHL	GHL → Leap at intake	All integration events; deduplication	Tenant validation required [P1-A]
Leap linked lead ID	Leap	Leap → GHL at intake	Suppression; writeback; integrity	Tenant validation required [P1-A]

Lead intake and attribution

Field	SOT	Allowed sync	Required for	Status
Lead source — tier 1 (attribution source)	GHL (inbound); Leap (manual)	GHL → Leap. Leap → GHL not permitted.	Lead volume by source KPI; routing	Partially confirmed Tenant Validation Required
Lead source — tier 2 (business source)	GHL	GHL → Leap	Channel-specific sequences	Partially confirmed Tenant Validation Required
Lead source — tier 3 (campaign detail)	GHL	GHL → Leap	Campaign reporting	Partially confirmed Tenant Validation Required

Contact and qualification

Field	SOT	Allowed sync	Required for	Status
Contact-established status + timestamp	GHL (boolean); Leap (event log)	GHL ↔ Leap via writeback [P1-C]	Lead contact rate KPI; suppression; rep workspace shift	Tenant validation required [P1-C]
Appointment status	Leap	Leap → GHL (narrow writeback, 1 of 4) [P1-B]	Appointment set rate KPI; reminder trigger	Tenant validation required [P1-B]
Qualification result	Leap	Leap → GHL (narrow writeback, 1 of 4) [P1-B]	Routing; GHL nurture	Tenant validation required [P1-B]
Recycle / disqualify outcome	Leap	Leap → GHL (narrow writeback, 1 of 4) [P1-B]	GHL recycle and suppression	Tenant validation required [P1-B]

Job and production

Field	SOT	Allowed sync	Required for	Status
Job type (retail / insurance / service / warranty)	Leap	No sync to GHL	Insurance overlay activation; CC template; AR path	Partially confirmed Tenant Validation Required
PM approval timestamp (Build Ready gate)	Leap	No sync	Build-ready pass rate KPI; gate signal to Coordinator	Tenant validation required [P1-E]
QC completion signal (Job Complete)	Leap (PM event); CompanyCam (checklist)	CC status visible in Leap via integration Tenant Validation Required	Documentation KPI; invoice release gate	Tenant validation required [P1-F]

Financial and close — Leap is sole SOT for all financial fields

Field	SOT	Allowed sync	Required for	Status
Invoice amount / balance / due date / payment status	Leap	No competing system	DSO; AR aging; payment tracking	Confirmed
Zero-balance signal	Leap	No sync for signal; Paid & Closed event fires to GHL [E-04]	Paid & Closed gate; post-close trigger	Confirmed (Leap-side); trigger path tenant validation required
Closeout package delivery confirmation	Leap	No sync	Paid & Closed gate condition	Partially confirmed — field must exist in Leap Pending Config
Post-close enrollment trigger	GHL	Triggered by Leap [E-04]	Review capture rate; referral lead rate KPIs	Tenant validation required [E-04]

Insurance overlay

Field	SOT	Allowed sync	Required for	Status
insurance_overlay_active	Leap	No sync	Insurance pipeline reporting; overlay logic	Tenant validation required — overlay fields not confirmed deployed
insurance_release_blocker_status	Leap	No sync	Weekly exception review; Build Ready gate enforcement	Tenant validation required

Fields with open definitions (from conflicts register)

Field	Issue	Action required
first_human_attempt (speed-to-lead KPI)	Not named or defined anywhere in the framework. KPI formula depends on it.	Define: name it, assign to GHL, define qualifying events. See RA-01.
SPD submission event (build-ready pass rate denominator)	SPD submission is a notification, not a tracked system event. Denominator is undefined.	Define "submitted" as a Leap stage or task event. See RA-02.

_See Section 7 (intake fields), Section 10 (insurance overlay field table), Section 13 (KPI table), and Section 14 (automation register)._

---

8A.9 Conflicts and Open Questions

Active contradictions and unresolved items requiring cleanup before the framework is treated as frozen canon. Existence in this register does not invalidate the framework — it prevents the company from pretending the conflict does not exist.

Register file: maps/conflicts-and-open-questions.md

Summary of open categories:

Category	Count	Priority
Canonical contradictions (C-)	2	P1–P2
Automation ambiguities (A-)	3	P2
Ownership ambiguities (OA-)	2	P2
Gate ambiguities (GA-)	2	P1
Reporting ambiguities (RA-)	2	P2
Leadership decisions required (LD-)	6	P1–P2
Legal review required (LR-)	3	P1

_See Section 12 (validation ledger) and Section 18 (change control)._

---

CompanyCam Operating Model

Proof of work. Not a photo pile. Every photo has a purpose, a phase, and a path to review.

The Problem CompanyCam Solves (and Does Not Solve)

CompanyCam solves the evidence capture and retrieval problem: the ability to prove what happened, when it happened, who did it, and what condition the site was in at each phase. It does not solve the quality problem, the ownership problem, or the governance problem. Those require human decisions about standards, assignments, and enforcement.

CompanyCam provides the mechanisms. The SOP provides the rules. Management provides the enforcement.

Project Structure

One CompanyCam project per Leap job. The project is linked to the Leap job at creation (via the integration). If the integration does not create the link automatically, the Production Coordinator must create the link manually before the job advances to Scheduled. An unlinked project is an orphaned evidence file.

Project Groups are an Elite-tier feature. If the current plan is below Elite, project grouping is not available. Tenant Validation Required

Label and Tag Architecture

CompanyCam uses two distinct organizational mechanisms:

Project labels apply to the project (the job). They categorize the project in the project feed. They are for filtering and reporting across jobs.

Photo tags apply to individual photos and videos within a project. They are for filtering and retrieving specific photos within a job.

These are different tools with different purposes. Do not use project labels to tag photos and do not use photo tags to categorize jobs.

Controlled Project Label Taxonomy

Label	When applied	Purpose
JOB-Roof	At project creation	Trade filter for reporting
JOB-Siding	At project creation	Trade filter for reporting
JOB-Windows	At project creation	Trade filter for reporting
JOB-Gutters	At project creation	Trade filter for reporting
JOB-MultiTrade	When two or more trades	Multi-trade scope flag
JOB-Insurance	When job type = Insurance	Activates insurance documentation awareness
DOC-WIP	Project active, documentation in progress	Work-in-progress marker
DOC-ReadyForQC	Crew lead marks phase documentation complete	Triggers PM review queue
DOC-QCApproved	PM approves documentation	Evidence gate cleared

Do not invent labels outside this taxonomy. Label sprawl makes the project feed unsearchable. If a new label is needed, it must be approved by the Ops Systems Owner and added to the canonical list.

Controlled Photo Tag Taxonomy

Phase tags (one per photo, required):

Tag	Phase
PH-Start	Pre-job site conditions, access, existing damage
PH-Demo	Demolition or tear-off
PH-Substrate	Deck, sheathing, or rough opening condition
PH-DryIn	Underlayment, water management, flashing
PH-Install	Primary installation in progress
PH-Detail	Critical details, penetrations, trim
PH-Cleanup	Site protection, cleanup, property restored
PH-FinalQC	Final quality review condition

Trade tags (one per photo, required):

Tag	Trade
TR-Roof	Roofing scope
TR-Siding	Siding scope
TR-Windows	Windows and doors scope
TR-Gutters	Gutters and drainage scope

Issue tags (conditional — add when applicable):

Tag	When to apply
ISS-HiddenDamage	Concealed condition discovered during demolition or substrate work
ISS-PreExisting	Pre-existing damage documented before work begins
ISS-ChangeOrder	Photo documents scope change requiring a written change order
ISS-CallbackRisk	Condition that may generate a callback if not addressed
ISS-Safety	Safety hazard on site

Evidence tags (add when applicable):

Tag	Purpose
EV-Wide	Context shot showing the full area
EV-Detail	Close-up of a critical detail or connection
EV-ConcealedWork	Photo of work that will be covered and cannot be re-photographed
EV-Completion	Final condition at closeout

Each photo should carry one phase tag and one trade tag as a minimum. Issue tags and evidence tags are added as needed.

Checklist Template Architecture

Four checklist templates standardize the documentation obligation by phase:

Template	When used	Responsible party
Checklist 1 — Job Start and Site Protection	Before work begins	Crew Lead
Checklist 2 — Trade Execution	During installation	Crew Lead
Checklist 3 — Final QC and Closeout	After all work is complete	Production Manager
Checklist 4 — Exception Documentation	When a hidden-damage, change-order, safety issue, or customer-complaint condition exists	Crew Lead (initial); PM (review)

All checklist fields should default to "photos required." Reference images showing "what good looks like" should be included in the template where practical. Pending Config

Accountability by Role

Crew Lead:

• Completes Checklists 1 and 2 during the job.
• Tags every photo with phase and trade tags at minimum.
• Tags issue photos immediately when a hidden condition is found. Does not wait until end of day.
• Changes project label to DOC-ReadyForQC when phase documentation is complete and ready for PM review.
• Confirms to the Production Manager (via Leap message or phone) when DOC-ReadyForQC is set, so the PM knows to begin the review.

Production Manager:

• Reviews checklist completion and photo evidence at defined milestones: pre-job approval, mid-job spot check, and final QC before invoice release.
• Specifically opens the CompanyCam project and reviews each checklist section — not just the photo count, but whether the required photo types are present and correctly tagged.
• Completes Checklist 3. Does not delegate the final QC sign-off.
• Changes project label to DOC-QCApproved when documentation meets standard.
• Does not authorize invoice release until DOC-QCApproved is set and the evidence gate is cleared.
• Defines "pass" as: all required checklist items complete, required phase and trade tags present on photos, no open issues unresolved, and no punch-list items outstanding.

Production Leadership (Ops Systems Owner):

• Owns template library. All new or revised templates require Ops Systems Owner approval before publishing.
• Runs weekly documentation compliance review: pulls the CompanyCam project list for the week, reviews checklist completion rate, photo count by phase, and QC approval rate by crew and job type. This is a named view in CompanyCam, reviewed every Monday. Results are logged. Crews or job types below threshold are escalated to the Production Manager before the next crew meeting.
• Identifies and escalates documentation failures before they become disputes.

Admin / Ops Systems Owner:

• Controls labels, tags, permission settings, and template governance.
• Labels and tag taxonomy changes require Ops Systems Owner approval.
• Gallery link governance: govern which links are created and shared. Deactivating a gallery link requires contacting CompanyCam support.

Deliverable Types

Deliverable	When created	Purpose
Phase checklist PDF	After each major phase	PM review artifact; stored in project files
Final QC checklist PDF	At Job Complete	Evidence gate artifact; stored in project files and available for Leap
Page — "Job Start Conditions"	Pre-job, generated from PH-Start photos	Customer communication and pre-existing condition defense
Page — "Final QC Packet"	At Job Complete	Customer closeout package; internal QC record
Page — "Change Order Evidence"	When ISS-ChangeOrder exists	Change-order documentation support
Gallery or Page PDF	At Paid & Closed	Customer-facing closeout packet delivery

---

Insurance Lifecycle Overlay

Insurance jobs use the same 12-state lifecycle. The overlay adds visibility and control for claim-specific actions, blockers, and payment paths — without creating hidden parallel stages.

Core Governing Rules

Insurance does not create a second lifecycle or a second pipeline board. Every insurance job follows the 12-state lifecycle. The overlay adds fields, tasks, and blocker logic that run alongside the core states.

GoHighLevel is not the insurance project board. After two-way SPD contact, active insurance work stays in Leap.

No automation may advance a core lifecycle state based on carrier notes, email content, or informal claim updates. Stage advancement requires the same gate conditions as retail jobs — plus insurance-specific blockers where applicable.

No one may hide supplement, lender, or deductible problems in freeform notes when they affect scheduling, invoice release, or cash timing.

Overlay Activation and Exit

Moment	Rule
Overlay activation	Set job_type = Insurance and insurance_overlay_active = Yes as soon as insurance involvement is confirmed
Activation timing	At intake if known; at inspection at the latest
Overlay persistence	Runs alongside the core lifecycle until all insurance obligations are resolved
Overlay exit	Insurance obligations cleared; or leadership approves documented retail conversion (claim denied or abandoned)
Never do this	Do not create separate lifecycle stages named Supplement Pending, Lender Delay, or similar. These are overlay field values, not stages.

Insurance-Specific Waiting States vs Active States

Insurance jobs have moments where work cannot proceed while waiting for an external party (carrier decision, supplement approval, lender release). These are not new lifecycle stages. They are blocker conditions tracked in the insurance_release_blocker_status field.

Waiting state (blocked): insurance_release_blocker_status = Blocked. The job sits in its current lifecycle stage. The blocker has a named reason, a named owner, and a next-action date. The production schedule or AR ladder does not proceed against a blocked job without a documented leadership exception.

Active state (clear or monitoring): insurance_release_blocker_status = Clear or Monitor. Work proceeds on the normal lifecycle timeline. Monitor means the blocker risk exists but is not currently stopping movement.

Required Insurance Overlay Fields in Leap

These fields must be configured in Leap before insurance work is considered operationally controlled. Pending Config Tenant Validation Required

Field	Values	Required by	Owner
job_type	Retail, Insurance, Service, Warranty	Lead or job creation	SPD / Admin
insurance_overlay_active	Yes, No	Confirmation of insurance involvement	SPD / Insurance Coordinator
claim_number	Free text	Inspection or first claim contact	SPD / Insurance Coordinator
carrier_name	Canonical dropdown	Inspection complete	Insurance Coordinator
insurance_claim_status	Status taxonomy (see below)	Each claim event	Insurance Coordinator
adjuster_appointment_at	Date/time	When set	Insurance Coordinator
claim_decision_type	Unknown, ACV, RCV, Denied	On carrier decision	Insurance Coordinator
acv_amount	Currency	On ACV decision	Insurance Coordinator / AR
deductible_amount	Currency	On decision or contract	Insurance Coordinator / AR
supplement_status	Status taxonomy (see below)	When supplement relevant	Supplement Owner
supplement_amount_requested	Currency	On submission	Supplement Owner
supplement_amount_approved	Currency	On approval	Supplement Owner / AR
payor_type	Insurance Direct, Lender Loss Draft, Homeowner Reimbursement, Mixed/Other	By Job Awarded	Insurance Coordinator / AR
lender_name	Free text	When payor_type = Lender Loss Draft	Insurance Coordinator
deductible_collected_status	Not Collected, Partially Collected, Collected, Manager Exception	By Job Awarded	AR / Insurance Coordinator
insurance_release_blocker_status	Clear, Monitor, Blocked	Before build-ready and at each blocker change	Insurance Coordinator / PM / AR
insurance_release_blocker_reason	Reason taxonomy (see below)	When not Clear	Insurance Coordinator / PM / AR
insurance_document_pack_status	Not Started, In Progress, Ready for Review, Complete, Rejected	Build-ready prep onward	PM / Insurance Coordinator
insurance_owner	Named user	Overlay activation	Leadership-assigned
supplement_owner	Named user	When supplement risk appears	Leadership-assigned

Insurance Claim Status Taxonomy

Status value	Meaning
Not Confirmed	Insurance involvement suspected but not confirmed
Filed	Claim filed and active
Adjuster Scheduled	Adjuster appointment set
Adjuster Visited	Adjuster visit completed; decision pending
Scope Received	Carrier scope or claim package received for review
ACV Approved	Claim approved on ACV path
RCV Approved	Claim approved on RCV path without unresolved supplement issue
Supplement Pending	Supplement submitted; awaiting decision
Supplement Approved	Carrier approved supplement
Supplement Denied	Carrier denied supplement; leadership decision required
Claim Denied / Retail Decision Needed	Insurance path failed; leadership or SPD decides whether to proceed as retail
Carrier Paid / Overlay Complete	Insurance-specific payment path complete

Release Blocker Reason Taxonomy

Reason	Impact
Claim Decision Pending	Blocks scope lock or sale progression
Scope Mismatch	Blocks build-ready
Supplement Pending Material	Blocks build-ready or scheduling
Lender Path Unknown	Blocks schedule commitment or AR forecast confidence
Lender Packet Missing	Blocks payment-release path
Deductible Not Collected	Blocks build-ready or invoice release per policy
Documentation Missing	Blocks supplement or final packet release
Carrier Correspondence Unresolved	Blocks payment-release path
Manager Exception	Leadership override with documented risk acceptance

Build-Ready Gate for Insurance Jobs

Insurance jobs must pass the universal build-ready gate (all six conditions in Section 3, State 6) plus the following insurance addenda:

• Claim decision received and scope confirmed (or proceed-at-risk decision made with leadership documentation)
• Supplement path resolved or explicitly deferred with documentation
• Deductible collection plan confirmed
• Payor type confirmed with payment-path notes
• insurance_release_blocker_status = Clear (or Monitor with PM and leadership sign-off)
• Insurance document pack status = Ready for Review or Complete

AR Implications for Insurance Jobs

Insurance jobs may have multiple payment events (ACV check, supplement approval, depreciation release, lender loss-draft release). Each event is a separate AR action. Leap tracks each component of the payment path. GHL does not.

The lender loss-draft path is the highest AR risk. When a lender is co-insured on the property, the insurance check requires lender endorsement before the contractor can cash it. This process can take weeks and is invisible unless the payor_type = Lender Loss Draft flag is set and the lender_packet_status field is actively maintained.

Paid & Closed for an insurance job requires zero balance in Leap across all payment components — not just the first ACV check.

Weekly Insurance Exception Review

One weekly insurance exception review is the minimum governance cadence. The review is anchored on a Leap view filtered to insurance jobs with insurance_release_blocker_status = Blocked or Monitor. Each job is reviewed: blocker owner confirmed, next action confirmed, escalation triggered if stalled. This is a named review meeting with a designated facilitator. It does not happen informally.

---

Example Project Journeys

Five complete walkthroughs. The first three show the lifecycle working cleanly. The last two show exception paths — because things going wrong is most of the job, and the system must be understood in both modes.

---

Example 1 — Retail Roofing Project (Standard Path)

Lead source: Company website contact form (inbound, GHL)

Job: Asphalt shingle full roof replacement, standard scope, retail customer, no insurance involvement.

Stage 1: New Lead

The homeowner completes the website contact form. A GHL contact record is created immediately. The integration fires and creates a linked Leap lead with cross-system IDs written to both records. Tenant Validation Required GHL assigns the lead to an SPD based on the current routing hierarchy (relationship context first, then referral/partner source, then insurance/storm fit, then geography/capacity). The acknowledgement message fires immediately. The SLA clock starts.

Owner: Marketing / CSR (intake quality); assigned SPD (first response).

Stage 2: Appointment Set

The SPD calls the homeowner within the current 2-business-hour SLA window. Two-way contact established. Contact-established event logged in Leap. GHL receives the narrow writeback and stops all outbound sequences. SPD books the appointment in Leap with date, time, and address.

Owner: Assigned SPD.

Stage 3: Inspection Complete

SPD on site. Takes pre-inspection photos tagged PH-Start, TR-Roof, EV-Wide. Completes inspection. Logs outcome in Leap with scope summary, square footage, selected product line, risk areas, and next action.

Owner: Assigned SPD.

Stage 4: Proposal Delivered

Proposal prepared and sent through JobNimbus (current interim path — SalesPro becomes the delivery tool once pricing is configured). Delivery logged in Leap. SPD follows up the next morning. Homeowner approves on day two.

Owner: Assigned SPD.

Stage 5: Job Awarded

Homeowner signs contract in Leap. Contract amount recorded. Job type = Retail confirmed. Deposit request sent. Build-ready review task created for PM. SPD begins build-ready packet.

Owner: Assigned SPD (build-ready packet); Production Manager (gate review).

Stage 6: Preproduction Ready

SPD submits the completed build-ready packet and notifies the PM. Job enters Preproduction Ready (scope-lock complete; packet submitted). PM reviews the build-ready packet (Build Ready gate). All conditions confirmed — scope, selections, site constraints (steep pitch, pool protection), no permit required, deposit received, pre-job photo pack complete. PM passes Build Ready gate with written approval. Job moves to Ready to Schedule.

Owner: Production Manager.

Stage 7–8: Ready to Schedule and Scheduled

Coordinator enters scheduling queue. Materials ordered. Start date confirmed with customer. Crew committed. Customer notified.

Stage 9: In Production

Crew on site Monday. Checklist 1 completed. Photos tagged PH-Start, TR-Roof. During tear-off, 4 sheets of rotten decking found — photos taken immediately, tagged ISS-HiddenDamage, PH-Substrate. PM notified. Change order initiated in Leap. Customer approves. Replacement decking photographed tagged EV-ConcealedWork. Full install proceeds with all phases documented. Cleanup complete. Project label = DOC-ReadyForQC.

Stage 10: Job Complete

PM reviews final evidence package. Checklist 3 complete. All required photos confirmed. No punch-list items. PM changes label to DOC-QCApproved. Invoice authorized.

Stage 11: Final Invoice Sent

AR Admin issues invoice in Leap. Invoice includes original scope plus change-order decking repair. Due date 14 days out. AR ladder begins.

Stage 12: Paid & Closed

Customer pays ACH on day 9. Zero balance confirmed. Closeout package assembled and delivered. Review request fires from GHL. Customer enrolled in long-term nurture.

---

Example 2 — Insurance Roofing Project with Lender (Standard Insurance Path)

Lead source: Facebook Lead Ad (inbound, GHL) Tenant Validation Required

Job: Insurance claim for hail damage, full roof replacement, lender co-insurance.

Stage 1–2: Lead enters GHL, linked Leap lead created. SPD makes first call within the current 2-business-hour SLA window. Two-way contact confirmed. SPD asks about insurance at first call — homeowner confirms hail damage, hasn't filed yet. Contact-established event logged. Appointment booked in Leap.

Stage 3–4: SPD on site. Full pre-inspection photos tagged PH-Start, TR-Roof, ISS-PreExisting for all hail damage. Contingency proposal delivered through Leap portal — scope pending carrier approval, customer's cost limited to deductible. Customer approves.

Stage 5: Job Awarded — Insurance Overlay Activated

Customer signs contingency contract. job_type = Insurance. insurance_overlay_active = Yes. Insurance owner assigned. Claim filed. claim_number logged. insurance_claim_status = Filed. insurance_release_blocker_status = Blocked. insurance_release_blocker_reason = Claim Decision Pending. Build-ready packet preparation deferred until scope confirmed.

Adjuster and Supplement Phase (inside Job Awarded)

Adjuster visits site. insurance_claim_status = Scope Received. PM reviews carrier scope — scope mismatch identified (two valleys and skylight flashing missing). Supplement assembled and submitted. supplement_status = Submitted. insurance_claim_status = Supplement Pending.

Weekly insurance exception review: supplement reviewed each week. Carrier approves supplement on week 3. supplement_amount_approved recorded. supplement_status = Approved. Additionally: lender discovered on property. payor_type = Lender Loss Draft. lender_name recorded. Lender packet assembled and submitted. insurance_release_blocker_status = Monitor with PM and leadership sign-off.

Stage 6: Preproduction Ready

Scope confirmed. Deductible collected. Blocker = Monitor with documentation. PM reviews all universal conditions plus insurance addenda. All confirmed. PM approves.

Stages 7–10: Same pattern as retail example. At Job Complete, insurance document pack also confirmed complete.

Stage 11–12: Invoice issued covering full scope including supplement. Lender endorses check. Homeowner pays deductible. Zero balance confirmed across all payment components. Closeout package delivered with carrier claim closeout paperwork.

---

Example 3 — Siding and Windows Project (Multi-Trade Retail)

Lead source: SPD self-generated door-knock

Job: Full siding replacement and three window replacements, retail customer.

Stage 1: SPD knocks during neighborhood canvass. Homeowner shows interest. SPD creates lead directly in Leap. Two-way contact from this moment. No GHL path.

Stage 2: Appointment booked on the doorstep — Saturday inspection.

Stage 3: Multi-trade inspection. Siding all elevations photographed. Three windows measured. Existing rot at two window corners noted and documented.

Stage 5: Contract signed. JOB-MultiTrade label applied in CompanyCam. Separate checklist sections for siding and windows.

Stage 6: Multi-trade build-ready review: siding product/color/trim confirmed; rot contingency documented; windows manufacturer/series/sizes confirmed; staging and neighbor fence constraint noted; egress check documented. PM approves both trades.

Stage 9 — Production (sequenced: windows first, then siding):

Window Day 1–2: Pre-existing conditions documented. At Window 2, rot found at rough opening beyond inspection scope. Photos taken immediately: tagged ISS-HiddenDamage, PH-Substrate. PM notified. Change order issued and approved before framing repairs proceed. Windows installed and photographed with appropriate tags.

Siding Day 3–5: Soft sheathing section found — within contingency scope, PM approves proceeding. WRB and integration detail photographed before siding starts: tagged PH-DryIn, EV-ConcealedWork. Full siding install documented. Cleanup complete. DOC-ReadyForQC set.

Stages 10–12: PM reviews evidence for both trades. Both confirmed. Invoice authorized. Closeout package includes trade-specific warranty documentation. Review request fires from GHL.

---

Example 4 — Build-Ready Gate Failure and Recovery

This example shows what happens when a job fails the build-ready gate — the defect loop in action.

Setup: A roofing job has been won. Contract signed. SPD completes the build-ready packet and submits it to the PM. The record advances to Preproduction Ready (scope-lock complete; packet submitted; awaiting Build Ready gate review).

Build Ready gate review — PM finds defects:

PM opens the build-ready packet during the Build Ready gate review and finds three defects:

1. Selections are incomplete — shingle color is noted but ridge cap color is not confirmed.
2. Deposit is recorded as "pending" — not confirmed as received.
3. No pre-job photo pack exists in CompanyCam.

PM does not pass the Build Ready gate. PM creates three defect tasks in Leap:

• Defect 1: "Confirm ridge cap color — owner: SPD, due: 2 business days"
• Defect 2: "Confirm deposit received — owner: AR Admin, due: 1 business day"
• Defect 3: "Upload pre-job photo pack to CompanyCam — owner: SPD, due: 2 business days"

PM notifies the SPD and Coordinator in writing: the Build Ready gate has not been passed; this job is not approved for scheduling. No scheduling conversation with the customer occurs.

Job returns to Job Awarded. The Build Ready gate failure returns the record from Preproduction Ready back to Job Awarded. The record does not advance to Ready to Schedule.

Defect resolution:

Defect 2 is resolved in one day — AR Admin confirms deposit received and updates the Leap field. Defect 1 and 3 are resolved by day two — SPD calls the customer to confirm the ridge cap color selection, updates Leap, and visits the site to take pre-job photos which are uploaded and tagged.

Re-review:

PM receives resolution notifications. SPD resubmits the corrected packet; record re-enters Preproduction Ready. PM re-opens the build-ready packet during a fresh Build Ready gate review. All three conditions are now confirmed. PM passes the Build Ready gate with written approval. PM notifies the Production Coordinator in writing.

Record advances to Ready to Schedule.

What this shows: Preproduction Ready is the submitted-and-under-review condition. The Build Ready gate is the PM's approval action. When the gate fails, the job goes back to Job Awarded — it is not "in Preproduction Ready on hold." The defect loop is explicit, named, and owned. The Coordinator does not schedule anything until PM's Build Ready gate approval exists in writing. The customer waits — correctly — because the alternative is a crew arriving at a job that wasn't ready.

---

Example 5 — Scheduled Job Cancelled and Returned to Ready to Schedule

This example shows a backward transition and what must happen at each step.

Setup: A siding job is in Scheduled state. Start date is confirmed for Monday. On Thursday, the homeowner calls and says they need to delay — they have a family event the following week and want to push the job two weeks.

Coordinator response:

The Production Coordinator accepts the call and tells the homeowner they will check availability and call back within the hour. Coordinator does not verbally commit to a new date.

Coordinator checks crew availability for the requested window. The crew is already committed to another job in that window. No immediate reschedule is available.

Record moves backward — Scheduled → Ready to Schedule:

Coordinator documents in Leap:

• Reason: Customer-requested timing delay
• Customer notification: received and confirmed
• Crew status: released from this job for the original date; redirected to next available job
• Materials status: materials order placed — coordinator checks with supplier on cancellation or hold
• Recovery path: reschedule attempt; customer aware of 2-3 week lead time for next available slot

Job returns to Ready to Schedule in Leap. PM is notified.

What happens next:

Coordinator calls the homeowner back and explains available windows. Customer selects a new start date 3 weeks out. Coordinator confirms crew availability and re-commits. Record advances to Scheduled with the new date. Customer notification sent. Materials re-confirmed.

What this shows: Backward transitions are explicit, documented, and owned. The crew is not left hanging. The materials situation is handled immediately. The customer is contacted promptly and professionally. The record tells the truth about what is happening — it is genuinely "not yet scheduled," not "scheduled but on hold."

---

Validation Ledger

The audit and validation baseline for every substantive claim in this document. Do not treat any item marked Tenant Validation Required, [Tenant validation still required], Leadership Decision Required, or Legal Review Required as operational fact. Items marked Confirmed are safe to operate from. Items marked Partially confirmed are safe to use as current design baseline only — live-tenant proof is still required before treating them as enforced reality.

---

12.1 Auditability Note

This validation pass compiled findings from the accumulated operating-system materials visible in this project, official vendor documentation for GoHighLevel, Leap, and CompanyCam, and publicly available information about lead-source integrations (HomeBuddy, Instant Roofer).

The following primary source artifacts were not separately retrieved in this validation pass and therefore some claims that cite them as authority are only indirectly supported by the compiled operating-system materials rather than directly traceable to the original named files:

• Decision Register adopted 2026-03-23 — Some "Decision Register entry" claims in earlier versions of this document are supported by the compiled operating system but have not been individually traced to a line in the original file in this pass.
• Audited v1.1 Bible — Referenced as source authority; not separately pulled for direct citation.
• Insurance Overlay Design Packet dated 2026-03-23 — The insurance operating model is strongly consistent with the compiled materials, but the original packet was not independently retrieved.

This does not erase the substance those documents carry. It does mean that when leadership refers to a "Decision Register entry," the company should be able to pull that file immediately. Until those artifacts are reattached as primary citations, some Confirmed items are Confirmed by compiled canon, not by direct primary-source trace.

---

12.2 Status and Confidence Taxonomy

Status labels used in this ledger:

• Confirmed — Safe to operate from as current fact. Traceable to compiled company canon, official vendor documentation, or both.
• Partially confirmed — Substance is directionally correct per available materials, but either the exact primary artifact was not retrieved, or the platform capability is confirmed while live-tenant configuration is not.
• Refuted — The claim in a prior version of this document is not supported by the accessible current canon; the document has been corrected.
• Tenant validation still required — The platform can do this in principle; whether this tenant is configured to do it is not proven.
• Leadership decision required — Software research cannot resolve this. A policy choice by leadership is required before any system is built around it.
• Legal review required — Counsel review is required before this item can be operationalized.

Confidence labels:

• High — Multiple sources corroborate; no meaningful counterevidence in accessible canon.
• Medium — Directionally supported; primary source not independently retrieved or partial corroboration only.
• Low — Minimal support; should be treated as a working assumption only.

Required interpretation standard — maintain for every item:

• (A) Can the platform do this in principle? — Confirmed by vendor documentation.
• (B) Is there evidence this tenant is configured to do this right now? — Separate from A; requires live-tenant export or test.
• (C) If not yet proven, what exact steps are required to confirm it? — See Section 12.5 Validation Procedure Appendix.

Do not confuse A with B. A platform capability is not a tenant configuration.

---

12.3 Validation Ledger Table

Validation Item	Category	Status	Confidence	Evidence Summary	Operational Implication	What Still Must Be Checked in Live Tenant	Owner	Priority
12-state lifecycle names and locked definitions	Lifecycle definition	Confirmed	High	Accessible operating-system document uses the 12-state model end to end.	Safe to use as current document canon.	Verify Leap workflow stage names and order exactly match.	Systems Owner	P2
Job Awarded definition: signed contract required; verbal or deposit alone do not qualify	Lifecycle definition	Partially Confirmed	High	Current canon requires signatures, locked value, payment path; verbal wins explicitly rejected. Deposit-alone wording not separately surfaced as a standalone primary artifact.	Safe to treat signed contract as required.	Verify Leap stage entry criteria and current rep behavior.	Sales Manager	P2
Preproduction Ready = scope-lock and handoff-complete condition; Build Ready gate = PM approval that releases to Ready to Schedule	Lifecycle definition	Confirmed	High	Current compiled canon separates Preproduction Ready (scope-lock complete) from the Build Ready gate (PM approval). Prior document versions conflated these; V8 corrects the distinction throughout.	Preproduction Ready is NOT the same as Build Ready gate passed. Do not advance a job to Ready to Schedule without PM Build Ready gate approval.	Verify tenant stages preserve this separation. Confirm PM-approval signal in Leap.	Systems Owner	P1
Job Complete definition: field work done + QC done + PM-reviewed evidence. All three.	Lifecycle definition	Partially Confirmed	High	Field completion and evidence readiness confirmed at Job Complete; QC pass is the exit gate before Final Invoice Sent.	Do not collapse Job Complete and QC pass into one state.	Verify stage movement and QC trigger logic in Leap.	Production PM	P2
Paid & Closed = zero Leap balance plus closeout package delivery	Lifecycle definition	Confirmed	High	Current canon requires all payments posted/applied, closeout complete, and handoff to lifecycle.	Safe as current close definition.	Verify zero-balance detection and required closeout fields.	AR Admin	P2
Contact-established definition: answered outbound, returned inbound, two-way SMS, two-way email qualify; voicemail-only and bot-only do not	Policy definition	Partially Confirmed	Medium	Definition may be internally adopted; separate primary-artifact wording was not independently retrieved; live implementation is not proven.	Treat as policy intent, not yet audit-traceable implementation.	Define exact source field, timestamp, qualifying events, and suppression behavior in GHL/Leap.	Sales Manager + Systems Owner	P1
System boundary map: GHL pre-contact intake; Leap post-contact workspace and financial truth; CompanyCam field evidence	System boundary	Confirmed	High	Current canon explicitly assigns these responsibilities throughout.	Safe to operate from this boundary.	Verify integrations do not create competing ownership.	Systems Owner	P1
Narrow writeback design intent: only four fields back to GHL (contact-established, qualification result, appointment status, recycle/disqualify)	Integration contract	Partially Confirmed	Medium	Internal canon supports narrow event syncing and cross-system IDs; exact four-field list is directionally supported but was not directly traced to the original Decision Register artifact in this pass.	Do not assert the exact four-field contract as proven until the original Decision Register artifact is attached or middleware export confirms it. Treat as current design intent.	Inspect middleware/webhooks/field list; confirm only intended fields update in live integration.	Systems Owner	P1
Financial truth anchor: Leap owns invoice amount, balance due, payment status, due date	Financial control	Confirmed	High	Internal canon repeatedly anchors AR truth and close logic in Leap.	Safe to enforce as source-of-truth rule. No other system may hold a parallel invoice ledger.	Verify no parallel GHL-ledger behavior exists.	AR Admin + Systems Owner	P1
Evidence gate: PM reviews final evidence package before invoice release; no exceptions without leadership sign-off	Financial / QC gate	Confirmed	High	Internal canon: no final invoice before QC release; AR does not release without production QC signal.	Safe as rule. Unsafe to assume tenant enforcement without testing.	Test whether invoice can be sent without QC pass in live tenant.	Production PM + AR Admin	P1
Manual / SPD-created leads bypass GHL and are created directly in Leap	Intake architecture	Refuted / Leadership Decision Required	Medium	Accessible current canon treats GHL as the primary intake origin for controlled inbound sources. The claim that manual leads "bypass GHL" as a confirmed, governed Decision Register entry is not separately supported in the retrieved materials. SPD-created lead entry is current practice, not proven canon.	Do not treat this as a confirmed operating rule. If leadership wants a formal direct-to-Leap exception path for SPD-created leads, that decision must be made explicitly and governance must be defined.	Confirm leadership decision on whether this exception is formally adopted and how it is governed.	Sales Manager + Leadership	P2
Leap SalesPro adopted; not yet live; pricing config is current blocker; JobNimbus is interim until cutover	Sales platform decision	Partially Confirmed	Medium	Internal canon positions SalesPro as target architecture and JobNimbus as interim context; live rollout state not independently exported.	Treat as leadership road map, not completed implementation. Do not run SalesPro and JobNimbus in parallel.	Verify SalesPro pricing library, product catalog, package setup, and remaining JobNimbus dependencies.	Leadership + Systems Owner	P2
Insurance overlay design: overlay fields, status taxonomy, blocker taxonomy, build-ready addenda	Insurance model	Partially Confirmed	Medium	Current compiled canon has insurance fields, statuses, gates, supplement workflow, and payer buckets. The original Insurance Overlay Design Packet (2026-03-23) was not separately retrieved in this pass.	Safe to use as current design baseline. Audit trail to original packet is incomplete in this pass until artifact is reattached.	Confirm exact field names and workflow deployment in live Leap tenant.	Production PM + Systems Owner	P2
CompanyCam labels vs photo tags are distinct mechanisms	CompanyCam capability	Confirmed	High	Official help center clearly separates Project Labels (project-level) and photo Tags (photo-level).	Safe to treat as platform fact. Apply controlled taxonomies per Section 9.	Verify internal taxonomy deployment and staff usage.	CompanyCam Admin	P2
CompanyCam required-photo checklist fields; checklist PDF export; page-to-PDF export	CompanyCam capability	Confirmed	High	Official help docs confirm all three.	Safe to treat as platform fact.	Verify account tier and staff usage/training.	CompanyCam Admin	P2
Save In Job required before CompanyCam photos are usable in Leap estimates or invoices	CompanyCam + Leap integration	Confirmed	High	Official integration doc explicitly requires Save In Job before using photos folder in estimates/invoices.	Safe to treat as platform fact.	Verify staff follow the save step consistently.	CompanyCam Admin + Sales Manager	P2
GHL invoice creation, invoice status tracking, workflow trigger on invoice status change	GHL capability	Confirmed	High	Official docs confirm invoice creation and invoice workflow trigger for sent/paid/overdue.	Safe to treat as platform capability.	Verify whether GHL is used operationally or only as comm layer in this tenant.	Systems Owner	P2
GHL Campaigns/Triggers deprecated; Workflows are correct automation layer	GHL capability	Confirmed	High	Official docs explicitly state Campaigns and Triggers are deprecated and sunsetting.	Safe to treat as platform fact. Do not build new automations using deprecated Campaigns or Triggers.	Verify no active legacy Campaigns remain in tenant.	GHL Admin	P2
GHL invoice reminder retroactivity limitation: reminders do not apply to invoices already overdue before enablement	GHL capability	Confirmed	High	Official invoice-reminder doc confirms this behavior.	Important for AR migration and cutover planning.	Verify reminder settings enablement date and backlog cleanup plan.	AR Admin + GHL Admin	P2
AR dunning ladder Day 0 / 7 / 14 / 30+ cadence	AR policy	Confirmed	High	Internal AR docs and compiled canon define this cadence.	Safe as operating ladder draft. Legal terms (late fees, interest, stop-work rights, lien notices) are separated and require legal review.	Confirm actual automation/manual ownership by bucket.	AR Admin	P2
Five-minute speed-to-lead window as current company policy	Sales SLA policy	Refuted	High	Current compiled operating system uses first human attempt within 2 business hours. A 5-minute standard has not been formally adopted as Locke & Ladder policy.	Do not present 5 minutes as current company rule. Current SLA standard is 2 business hours. Leadership may choose to tighten this.	Leadership must decide if SLA is tightened. Then configure GHL enforcement.	Sales Manager + Leadership	P2
Build-ready gate artifact list (universal checklist plus trade addenda)	Build-ready definition	Partially Confirmed	High	Current canon has a universal checklist and trade addenda. Prior "mere inference" language has been removed.	Safe to use as current baseline. Trade-specific refinement may still evolve.	Production should validate final artifact list by trade.	Production PM	P2
Pool-based routing: geography first, then trade or lead class, then insurance vs retail	Routing logic	Refuted	High	Current canon does not support geography-first routing. Current hierarchy prioritizes existing customers and relationship context before geography/capacity. Document corrected in Section 7.	Geography-first routing description was incorrect. Use the corrected routing hierarchy in Section 7.	Export live GHL routing rules and compare to intended hierarchy.	Sales Manager + GHL Admin	P2
CompanyCam project templates may auto-apply when Leap creates projects	CompanyCam tenant behavior	Tenant Validation Required	Medium	Platform prerequisites confirmed; actual auto-template behavior is not proven for this tenant.	Do not assume template auto-application in production.	Create test Leap job with CompanyCam option checked; inspect resulting project.	CompanyCam Admin	P2
GHL-to-Leap integration mechanism	Tenant integration	Tenant Validation Required	High	GHL supports outbound webhooks; Leap/SalesPro supports webhooks; internal canon assumes middleware-first webhook-driven architecture; live mechanism is unproven.	Priority 1. This is the intake spine. If broken, all downstream automation is suspect. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	Systems Owner	P1
Leap-to-GHL narrow writeback	Tenant integration	Tenant Validation Required	High	Same integration primitives exist; no live proof of the four-field contract was surfaced.	Priority 1. If absent, suppression, post-close, and customer messaging drift. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	Systems Owner	P1
Contact-established event recording	Tenant automation / KPI	Tenant Validation Required	High	No retrieved source proved exact event model or suppression logic in live tenant.	Priority 1. If weak, AI/bot follow-up continues after human contact; contact-rate KPI is dirty. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	Sales Manager + GHL Admin	P1
Leap stage-lock enforcement	Tenant enforcement	Tenant Validation Required	High	Official docs confirm stage locking exists in principle; live config is unproven.	Priority 1. If not real, gates become advisory and KPIs become fiction. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	Systems Owner + Production PM	P1
Build Ready gate enforcement in Leap	Tenant enforcement	Tenant Validation Required	High	Process rule is clear; native block/approval behavior in this tenant is unproven.	Priority 1. If missing, sold-not-ready jobs hit scheduling. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	Production PM + Systems Owner	P1
Evidence gate enforcement before invoice release	Tenant enforcement	Tenant Validation Required	High	Rule is confirmed; live technical enforcement is unproven.	Priority 1. If weak, AR and dispute defense are exposed. See Section 12.4.	See Priority 1 validation procedure below and Section 12.5.	AR Admin + Production PM	P1
Leap AR dunning capability (configurable reminder timing and escalation tasks)	Tenant capability	Tenant Validation Required	Medium	Leap invoicing and payment capture confirmed; native dunning ladder capability not documented in publicly available sources.	Do not assume Leap can replace GHL/manual dunning without testing.	Inspect reminder settings, overdue automation, tasks, and escalation behavior in tenant.	AR Admin	P2
CompanyCam plan tier	Tenant plan/tier	Tenant Validation Required	High	Many needed template features are unavailable on Basic/Pro. Tier is unconfirmed.	Tier determines whether template-driven standardization is actually possible.	Check Billing > Pricing Plans in CompanyCam admin.	CompanyCam Admin	P2
CompanyCam auto-project creation via Leap integration	Tenant integration	Tenant Validation Required	High	Official integration doc says checking CompanyCam on job creation creates a project; live behavior unproven.	Safe as capability; not as live fact.	Run a test job create in Leap with checkbox enabled.	CompanyCam Admin + Systems Owner	P2
Insurance overlay fields deployed in live Leap tenant	Tenant configuration	Tenant Validation Required	Medium	Internal canon defines the data model; live deployment not proven.	Do not assume reporting or automation works until fields exist.	Export custom fields, job types, insurance stages, payer buckets from Leap admin.	Systems Owner + Production PM	P2
Post-close trigger reliability (Paid & Closed → GHL post-close sequence)	Tenant integration	Tenant Validation Required	Medium	GHL can react to invoice/status events; internal canon assumes lifecycle handoff; live Leap→GHL signal path unproven.	If weak, review/referral/lifecycle nurture start unreliably.	Test Paid-and-Closed path end to end; confirm tag/segment/workflow entry in GHL.	GHL Admin + AR Admin	P2
GHL Facebook Lead Ads integration live in this tenant	Lead-source integration	Tenant Validation Required	High	Official GHL docs confirm direct FB Lead Ads integration capability; live activation unproven.	Do not assume ads are feeding the CRM.	Check Subaccount Settings > Integrations / Ad Manager; submit test lead.	GHL Admin	P2
Instant Roofer / Roofing Calculator transport path to GHL	Lead-source integration	Tenant Validation Required	Medium	Instant Roofer publicly documents CRM integration via Zapier and an API; direct GHL path not proven.	Do not assume automatic GHL transport.	Inspect Zapier/Make/webhook setup; submit live test lead/report.	Marketing Ops + Systems Owner	P2
HomeBuddy transport path to GHL	Lead-source integration	Tenant Validation Required	Medium	HomeBuddy public integrations page lists GHL and Leap; live path unproven.	Do not assume transport is active or mapped correctly.	Verify HomeBuddy account, integration mapping, test lead and appointment sync.	Marketing Ops + Systems Owner	P2
Website form-to-GHL transport	Lead-source integration	Tenant Validation Required	Medium	No live website config was retrieved.	Cannot trust source attribution or SLA without proving the path.	Inspect form endpoints, hidden fields; submit test entries; verify GHL field mapping.	GHL Admin + Web Admin	P2
GHL routing rules live configuration	Tenant routing	Tenant Validation Required	High	Current intended hierarchy exists on paper; live automation unproven.	Routing cannot be trusted until exported and tested.	Export workflows/assignment logic, round robin, queue ownership, and if/else branches.	Sales Manager + GHL Admin	P2
Payment term specificity: deposit %, stop-work timelines, late fees	Financial policy	Leadership Decision Required	High	Internal canon sets structure but not exact numbers/thresholds.	No system should be built around unstated policy. Stop-work, late-fee, and deposit-% configurations require a policy memo before system build.	N/A software-only. Choose policy; send to counsel for review.	Leadership	P1
AI consent mechanism for customer-facing AI	AI / compliance policy	Leadership Decision Required	High	Internal canon requires disclosure/consent; exact mechanism not decided.	Customer-facing AI should not launch until policy exists.	N/A software-only. Define disclosure/consent standard; hand to counsel.	Leadership	P1
GHL as invoice delivery channel vs Leap	System ownership decision	Leadership Decision Required	High	Both platforms can invoice; one customer-facing owner must be chosen.	Without one owner, AR truth and customer experience drift.	N/A software-only. Choose channel; disable competing path.	Leadership + AR Admin	P1
SOP vault platform	Governance decision	Leadership Decision Required	High	Governance model is clearer than platform choice; final platform not selected.	Do not confuse governance completeness with platform decision completeness.	N/A software-only. Choose platform and permission model.	Leadership + Systems Owner	P2
Review policy compliance (gating, incentives, sentiment filtering)	Legal / compliance	Legal Review Required	High	Google prohibits incentivized/filtered/fake review practices; FTC guidance makes deceptive review practices legally risky.	Do not launch review gating or incentives without counsel sign-off.	N/A tenant-only. Legal review of scripts, asks, suppression, and incentives.	Leadership + Counsel	P1
Payment-term enforcement language (late fees, interest, stop-work rights, lien notices, collections)	Legal / compliance	Legal Review Required	High	Internal canon sets AR ladder structure; legal enforceability of specific terms requires counsel.	No late-fee or lien-notice language should appear in customer-facing communications without counsel review.	N/A tenant-only. Counsel review of AR enforcement language.	Leadership + Counsel	P1
AI-assisted call recording and customer-facing AI communication consent/disclosure/retention	Legal / compliance	Legal Review Required	High	Call recording consent and AI disclosure obligations vary by jurisdiction.	Phase-one AI use requires confirmed consent mechanism before any recorded call analysis begins.	N/A tenant-only. Counsel review of call recording disclosure, AI communication consent, and retention policy.	Leadership + Counsel	P1

---

12.4 Priority 1 Items — Tenant Validation Required Before Treating as Operational

The following six items are the highest-risk unresolved items in the live stack. Until each is tested end-to-end in the live tenant, it must be treated as design intent, not operating fact. Each item includes why it matters, what breaks if it is missing, exact validation steps, and a fallback operating protocol.

---

P1-A: GHL-to-Leap Integration Mechanism

Why it matters: This is the intake spine. If the handoff is brittle, downstream promises about source attribution, lead ownership, suppression, appointment truth, and cross-system reporting become suspect.

What breaks if it is missing:

• Duplicate Leap entry
• Unreliable cross-system IDs
• Broken suppression logic
• Lifecycle backbone becomes non-credible

Exact validation steps:

1. Export all GHL workflows that trigger on Contact Created, Form Submitted, Appointment Booked, and any outbound webhook or custom webhook action.
2. Inspect middleware accounts (Zapier, Make, Pabbly, or custom services).
3. Inspect Leap/SalesPro webhook or API endpoints receiving data.
4. Submit one live test lead from each source: website, Facebook Lead Ad, manual GHL form, inbound call, and any external aggregator.
5. Confirm the Leap record is created once, carries expected source fields, and stores the correct GHL contact ID.
6. Capture error logs and time-to-create.

Fallback operating protocol if native enforcement does not exist: Queue owner manually creates the Leap record the same business day, enters the GHL contact ID into a required field, and logs the exception in a visible integration-failure queue. No automation depending on post-contact truth should be trusted until the linkage is proven.

---

P1-B: Leap-to-GHL Narrow Writeback

Why it matters: This prevents GHL from continuing pre-contact automations after operational truth has already changed in Leap.

What breaks if it is missing:

• Customers receive bot texts and sequences after real human engagement exists
• Scheduled/active/closed jobs remain in pre-contact logic
• Post-close workflows trigger unreliably

Exact validation steps:

1. Export Leap/SalesPro outbound webhook settings and any middleware scenarios.
2. Export GHL workflows using Inbound Webhook triggers and any update-contact/update-opportunity actions.
3. Verify exact target fields: contact-established, qualification result, appointment status, recycle/disqualify.
4. Run stage-change tests in Leap and confirm only intended fields update in GHL.
5. Repeat each event twice to test idempotency and duplicate protection.

Fallback operating protocol if native enforcement does not exist: Create a daily manual writeback queue owned by ops/admin. GHL customer-facing workflows should key only off manually confirmed fields until automated writeback is proven.

---

P1-C: Contact-Established Event Recording

Why it matters: This is the suppression boundary between "keep chasing" and "a human relationship now exists."

What breaks if it is missing:

• False contact-rate reporting
• Bot harassment after human contact has been established
• Confused rep ownership

Exact validation steps:

1. Define the authoritative field name and timestamp field in GHL and/or Leap.
2. Test qualifying events: answered outbound call; returned inbound call; two-way SMS; two-way email.
3. Test non-qualifying events: voicemail only; bot reply only; outbound attempt without reply.
4. Confirm suppression shuts off the correct nurture and AI sequences after a qualifying event.
5. Confirm the event mirrors correctly to the other system.

Fallback operating protocol if native enforcement does not exist: Use one authoritative boolean plus timestamp in GHL, set only by a qualifying-event workflow or a human owner. Sales Manager reviews daily exceptions until automation is stable.

---

P1-D: Leap Stage-Lock Enforcement

Why it matters: Without real stage locking, gates are theater. Every stage on the dashboard becomes aspirational rather than factual.

What breaks if it is missing:

• Dirty dashboards with false progression
• Jobs marked ready that are not ready
• Management drift attributed to software, caused by unchecked human workarounds

Exact validation steps:

1. Inspect Leap workflow settings, production automations, permissions, and tasks tied to gated stages.
2. Create a test record with missing required tasks and attempt to move it forward.
3. Document whether Leap blocks the move, allows it, or requires an approval-stage workaround.
4. Repeat with different user roles.

Fallback operating protocol if native enforcement does not exist: Use approval-only stages that only the approving role can move, plus a daily exception queue of records that attempted to bypass the gate.

---

P1-E: Build Ready Gate Enforcement in Leap

Why it matters: This is the most important sales-to-production control. Preproduction Ready is the scope-lock condition; the Build Ready gate is what releases the job to Ready to Schedule. If this gate has no native enforcement, sold jobs hit scheduling without being ready.

What breaks if it is missing:

• Sold jobs hit the production schedule before permits, materials, access constraints, funding readiness, or pre-job evidence are confirmed
• PM approval becomes advisory
• Scheduling conflicts and customer experience failures follow

Exact validation steps:

1. Create a test job in Preproduction Ready.
2. Leave one critical item blank each run: permit status; material ETA; pre-job photos; funding note; customer constraints.
3. Attempt the move to Ready to Schedule.
4. Record whether the move is blocked by task lock, stage lock, field requirement, approval stage, or nothing.

Fallback operating protocol if native enforcement does not exist: Insert a dedicated PM-owned Build Ready Review approval stage and restrict scheduling-board visibility to jobs that have passed it. PM written approval is required before any job moves to Ready to Schedule regardless of system lock status.

---

P1-F: Evidence Gate Enforcement Before Invoice Release

Why it matters: This is the cash-protection and dispute-defense gate. Invoices issued before proof exists are invoices that cannot be defended.

What breaks if it is missing:

• Invoices go out before proof exists
• Customer disputes become harder to defend
• QC becomes performative

Exact validation steps:

1. Create a test job at Job Complete with missing final photos or incomplete QC checklist items.
2. Attempt to generate and send a final invoice.
3. Verify whether AR permissions, QC signal fields, tasks, or workflow logic actually block release.
4. Confirm whether a manual override leaves an exception trail.

Fallback operating protocol if native enforcement does not exist: Restrict invoice-send rights to AR Admin only. Require documented PM QC release evidence before sending. Audit all invoice sends weekly against QC completion dates.

---

12.5 Leadership Decisions — Flagged Separately

These items cannot be resolved by software research, vendor documentation, or tenant configuration. They require explicit policy decisions from leadership before any dependent system is built or enforced.

LDEC-01 — Payment term specificity (deposit %, stop-work timelines, late fees): Internal canon sets the payment framework structure without specifying exact numbers. No system should be built around unstated policy. Requires a policy memo sent to counsel before AR configuration. Owner: Leadership. Priority: P1.

LDEC-02 — AI consent mechanism: The specific consent mechanism for AI-assisted customer communications has not been decided. No customer-facing AI communication may launch until this mechanism is defined and reviewed. Owner: Leadership. Priority: P1.

LDEC-03 — GHL as invoice delivery channel vs Leap: Both platforms can create and send invoices. One customer-facing owner must be named and the other disabled for invoice delivery. Without this choice, AR truth and customer experience drift. Owner: Leadership + AR Admin. Priority: P1.

LDEC-04 — SPD-created lead exception path (manual leads): Whether SPD-created leads (referrals, door-knocks) formally bypass GHL intake, whether GHL records should be created in parallel, and how this exception is governed (source attribution, deduplication) has not been confirmed as a formally adopted Decision Register entry in the accessible materials. Owner: Sales Manager + Leadership. Priority: P2.

LDEC-05 — SOP vault platform: The platform on which the canonical SOP vault lives has not been confirmed. Governance model is designed; platform selection is not. Owner: Leadership + Systems Owner. Priority: P2.

---

12.6 Legal and Compliance Items — Flagged Separately

These items require counsel review before any live launch of the dependent feature. Do not operationalize any of the following without legal sign-off.

LEGAL-01 — Review policy compliance: Google explicitly prohibits incentivized reviews, selective positive-only solicitation, and review-removal offers. FTC guidance and the 2024 Consumer Reviews and Testimonials Rule make sentiment-conditioned incentives legally risky. No review gating, sentiment filtering, incentive, or review-removal offer may be used without counsel sign-off. Owner: Leadership + Counsel. Priority: P1.

LEGAL-02 — Payment-term enforcement language: Late fees, interest charges, stop-work rights, lien notice language, and collections escalation language must be reviewed by counsel before appearing in customer-facing communications or contracts. Owner: Leadership + Counsel. Priority: P1.

LEGAL-03 — AI-assisted call recording, customer-facing AI, and disclosure/consent: Call recording consent standards vary by jurisdiction. AI communication disclosure requirements are evolving. Retention policies create liability exposure if not established. No phase-one AI use with recorded calls may begin until consent mechanism, disclosure standards, and retention policy are confirmed with counsel. Owner: Leadership + Counsel. Priority: P1.

---

12.7 Validation Procedure Appendix

For every tenant-specific item that remains unconfirmed, the following provides the authoritative system, exact field or trigger to inspect, where to inspect it, how to test it, what screenshot or export counts as proof, owner, and review cadence.

---

VAP-01 — GHL-to-Leap integration mechanism

• Authoritative system: GHL (workflow trigger); middleware (if applicable); Leap (receiving endpoint)
• Field/trigger: Outbound webhook action on Contact Created; Leap lead ID written to GHL custom field; GHL contact ID written to Leap lead field
• Where to inspect: GHL → Workflows → filter by trigger type (Contact Created, Form Submitted); Zapier/Make/Pabbly account if middleware is used; Leap → Settings → Webhooks/Integrations
• How to test: Submit a test lead from each source; trace it from GHL contact record through to Leap lead record; confirm both cross-system IDs are present in both records
• Proof: Screenshot of GHL contact showing Leap lead ID; screenshot of Leap lead showing GHL contact ID; middleware execution log with timestamp; no duplicate Leap record created
• Owner: Systems Owner
• Review cadence: Weekly for first 30 days post-activation; monthly thereafter

---

VAP-02 — Leap-to-GHL narrow writeback

• Authoritative system: Leap (event source); middleware or direct webhook; GHL (receiving fields)
• Field/trigger: Four approved writeback fields only: contact-established status, qualification result, appointment status, recycle/disqualify outcome
• Where to inspect: Leap → Settings → Webhooks (outbound); GHL → Workflows → Inbound Webhook triggers; middleware account
• How to test: Change each of the four approved fields in a test Leap record; confirm GHL contact updates only those four fields; confirm no other GHL fields change; run each test twice to confirm idempotency
• Proof: GHL contact before/after screenshot for each test event; middleware execution log; confirmation that unapproved fields did not update
• Owner: Systems Owner
• Review cadence: Weekly for first 30 days; monthly thereafter

---

VAP-03 — Contact-established event recording

• Authoritative system: GHL (primary contact field); mirrored to Leap
• Field/trigger: contact_established_status boolean + contact_established_at timestamp; qualifying events: answered outbound call, returned inbound call, two-way SMS, two-way email
• Where to inspect: GHL → Contact record → Custom fields; GHL → Workflows → trigger conditions for contact-established event
• How to test: Simulate each qualifying event type (answered call, inbound reply, two-way SMS, two-way email) in a test record; confirm field flips to true and timestamp is set; simulate non-qualifying events (voicemail, bot reply, outbound attempt without reply) and confirm field does not flip; confirm appropriate sequences stop after field flip
• Proof: Contact record screenshots before/after each test event; sequence activity log showing suppression; timeline showing no customer-facing messages after contact-established = true
• Owner: Sales Manager + GHL Admin
• Review cadence: Weekly for first 30 days; monthly thereafter

---

VAP-04 — Leap stage-lock enforcement

• Authoritative system: Leap (stage configuration)
• Field/trigger: Stage-lock settings per workflow stage; required tasks; role-based stage movement permissions
• Where to inspect: Leap → Settings → Workflows → individual stage settings; task templates on gated transitions; role/permission settings
• How to test: Create a test record; attempt to move it to a gated stage with required tasks incomplete; document result (blocked, allowed, or approval-stage workaround required); repeat with different user roles
• Proof: Screen recording or screenshots of each attempted gate bypass; role-specific test results; Leap admin settings screenshot showing lock configuration
• Owner: Systems Owner + Production PM
• Review cadence: Once at activation; then quarterly or after any stage configuration change

---

VAP-05 — Build Ready gate enforcement in Leap

• Authoritative system: Leap (stage-lock or approval stage between Preproduction Ready and Ready to Schedule)
• Field/trigger: PM approval field or approval-stage transition; task requirements for each Build Ready checklist item
• Where to inspect: Leap → Preproduction Ready stage settings; task template for Build Ready review; PM role permissions for stage advancement
• How to test: Create test job in Preproduction Ready; leave one required item blank (permit, material ETA, pre-job photos, funding note, site constraints) per test run; attempt move to Ready to Schedule; document whether move is blocked by task lock, field requirement, approval stage, or nothing
• Proof: Screenshots of each test attempt; documentation of which controls (if any) block the move; Leap admin screenshots of stage configuration
• Owner: Production PM + Systems Owner
• Review cadence: Once at activation; quarterly thereafter

---

VAP-06 — Evidence gate enforcement before invoice release

• Authoritative system: Leap (invoice permissions + QC signal field or task)
• Field/trigger: QC-complete signal field or task; AR Admin invoice-send permissions restricted pending PM signal
• Where to inspect: Leap → Invoice settings → permissions for who can send; Leap → Job Complete stage settings; QC checklist completion field or task
• How to test: Create a test job at Job Complete with missing final photos or incomplete QC checklist items; attempt to generate and send a final invoice; verify whether the system blocks release or allows it; confirm whether manual override leaves an exception trail
• Proof: Screenshots of test attempt; documentation of block or allow result; AR Admin permission settings screenshot; exception log if override attempted
• Owner: AR Admin + Production PM
• Review cadence: Once at activation; weekly exception audit of invoice sends vs QC completion dates thereafter

---

VAP-07 — CompanyCam plan tier

• Authoritative system: CompanyCam admin (billing)
• Field/trigger: Current subscription plan name
• Where to inspect: CompanyCam → Billing > Pricing Plans
• How to test: Navigate to billing; identify plan name; cross-reference against CompanyCam feature matrix for template availability, checklist features, and project groups
• Proof: Screenshot of billing page showing plan name and active features
• Owner: CompanyCam Admin
• Review cadence: At initial validation; again at any renewal date

---

VAP-08 — CompanyCam auto-project creation via Leap integration

• Authoritative system: CompanyCam (project creation); Leap (integration trigger)
• Field/trigger: CompanyCam checkbox on Leap job creation; resulting CompanyCam project with expected template elements
• Where to inspect: Leap → Create Job → CompanyCam option; resulting CompanyCam project in CompanyCam dashboard
• How to test: Create a test job in Leap with the CompanyCam checkbox enabled; inspect whether a CompanyCam project appears; inspect whether default template elements (checklists, labels) are present in the created project
• Proof: Screenshot of Leap job creation with checkbox; screenshot of resulting CompanyCam project with template elements (or their absence)
• Owner: CompanyCam Admin + Systems Owner
• Review cadence: Once at activation; test again after any template configuration change

---

VAP-09 — GHL routing rules live configuration

• Authoritative system: GHL (workflow assignment logic)
• Field/trigger: Assignment rules, round-robin settings, queue ownership, if/else branch conditions for routing
• Where to inspect: GHL → Workflows → all workflows with assignment actions; GHL → Settings → Round Robin / Assignment; Conversations → team queue settings
• How to test: Submit test leads from each source; trace assignment to correct SPD; test edge cases (after hours, new vs returning customer, insurance vs retail flag); confirm hierarchy matches intended design (relationship context first, then referral/partner, then insurance fit, then geography/capacity)
• Proof: Exported workflow screenshots showing assignment logic; test lead assignment log; comparison document showing intended vs actual routing
• Owner: Sales Manager + GHL Admin
• Review cadence: Once at initial validation; monthly during first quarter; quarterly thereafter

---

VAP-10 — Insurance overlay fields in Leap

• Authoritative system: Leap (custom fields, job types, workflow variants)
• Field/trigger: All 18+ insurance overlay custom fields (see Section 10); insurance job type; supplement status workflow; payer bucket fields
• Where to inspect: Leap → Settings → Custom Fields; Leap → Settings → Job Types / Workflow Variants; Leap → Settings → Stages for insurance-specific stages
• How to test: Export full custom field list; cross-reference against Section 10 required field table; identify any fields not present; create a test insurance job and confirm all required fields are available and behave correctly
• Proof: Exported custom field list from Leap admin; field-by-field comparison against Section 10 table; test insurance job screenshots
• Owner: Systems Owner + Production PM
• Review cadence: Once at activation; quarterly thereafter

---

VAP-11 — Post-close trigger reliability

• Authoritative system: Leap (Paid & Closed event); GHL (receiving workflow)
• Field/trigger: Leap invoice zero-balance or Paid & Closed stage event → GHL workflow trigger → review request + nurture enrollment
• Where to inspect: Leap → stage/automation settings for Paid & Closed event; GHL → Workflows → trigger for Leap event (inbound webhook or direct integration)
• How to test: Complete a test job through full cycle; confirm zero balance; confirm GHL receives the trigger; confirm review request workflow fires; confirm nurture enrollment occurs; confirm no duplicate triggers
• Proof: Leap Paid & Closed event log; GHL workflow execution log; screenshot of test contact showing review request sent and nurture enrollment
• Owner: GHL Admin + AR Admin
• Review cadence: Once at activation; monthly for first quarter; quarterly thereafter

---

VAP-12 — GHL Facebook Lead Ads integration

• Authoritative system: GHL (Subaccount Integrations)
• Field/trigger: Facebook Ad account connection; Lead Ad form mapping; workflow trigger on lead arrival
• Where to inspect: GHL → Settings → Integrations → Facebook / Ad Manager; GHL → Subaccount → Integrations
• How to test: Verify active Facebook connection; run a live test lead from the Facebook Lead Ad form; confirm receipt in GHL with correct field mapping; confirm source attribution; confirm routing and speed-to-lead sequence fires
• Proof: Screenshot of active Facebook integration in GHL settings; test lead receipt with correct source tag; workflow execution log
• Owner: GHL Admin
• Review cadence: At activation; monthly during first quarter

---

VAP-13 — Website form-to-GHL transport

• Authoritative system: GHL (form endpoint or webhook)
• Field/trigger: Form submission event → GHL contact creation → correct source attribution → linked Leap lead
• Where to inspect: Website admin → form settings → submission endpoint; GHL → Forms or → Workflows → Form Submitted trigger; GHL → Contacts → test submission
• How to test: Submit test form entry from website; confirm GHL contact created with correct source attribution; confirm routing fires; confirm Leap lead created (once VAP-01 is confirmed)
• Proof: Screenshot of test form submission in GHL contacts; source attribution correct; workflow execution log
• Owner: GHL Admin + Web Admin
• Review cadence: At activation; after any website platform update

---

VAP-14 — HomeBuddy transport path to GHL

• Authoritative system: HomeBuddy account (integration settings); GHL (receiving workflow)
• Field/trigger: HomeBuddy lead event → GHL contact creation → correct source attribution
• Where to inspect: HomeBuddy account → Integrations → GoHighLevel; GHL → Workflows → inbound webhook or form trigger for HomeBuddy
• How to test: Verify HomeBuddy integration is configured and active; submit a test lead from HomeBuddy; confirm receipt in GHL; confirm correct source attribution and routing
• Proof: Screenshot of active HomeBuddy integration settings; test lead receipt in GHL with correct source tag; workflow execution log
• Owner: Marketing Ops + Systems Owner
• Review cadence: At activation; monthly for first quarter

---

VAP-15 — Instant Roofer / Roofing Calculator transport path to GHL

• Authoritative system: Instant Roofer account (API or Zapier settings); GHL (receiving webhook or Zap)
• Field/trigger: Instant Roofer lead/report event → Zapier or API → GHL contact creation → correct source attribution
• Where to inspect: Instant Roofer account → Integrations → CRM or Zapier; Zapier account → Zaps involving Instant Roofer and GHL; GHL → Workflows → Inbound Webhook
• How to test: Submit a test lead or report request from Instant Roofer; trace it through Zapier or API to GHL; confirm receipt with correct source attribution and routing
• Proof: Screenshot of active Zapier/API integration; test lead receipt in GHL with correct source tag; execution log
• Owner: Marketing Ops + Systems Owner
• Review cadence: At activation; monthly for first quarter

---

KPI Accountability

What the company measures, who owns it, and what the numbers mean.

Purpose

This company does not guess at its performance. It measures things that matter — leading indicators that tell the team where problems are forming before they become crises. A speed-to-lead number that drops tells the Sales Manager something needs to change before deals are lost. A build-ready pass rate that falls tells the Production Manager that sales handoffs are degrading. A DSO number that rises tells leadership that the AR ladder is not working.

Governance Rules

KPI Table

Metric	Formula	System	Owner	Starting Threshold
Lead volume by source	Unique leads / period by business source	GHL	Marketing / CSR	Set after source taxonomy confirmed
Speed-to-lead	first_human_attempt − lead_created; % within SLA	GHL	Sales Manager	Current SLA = 2 business hours; Green ≥ 85% within SLA; Yellow 70–84%; Red < 70%. Threshold recalibrates if leadership adopts a tighter SLA. Leadership Decision Required
Lead contact rate	contacted leads / total leads	GHL	Sales Manager	Green ≥ 90%; Yellow 75–89%; Red < 75%
Appointment set rate	appointments set / contacted leads	GHL	Sales Manager	Green ≥ 60%; Yellow 45–59%; Red < 45%
Appointment held rate	appointments held / scheduled	Leap	Sales Manager	Set after 60 days
Close rate	signed contracts / proposals delivered	Leap	Sales Manager	Green ≥ 35%; Yellow 25–34%; Red < 25%
Pipeline coverage	open pipeline / monthly revenue target	Leap	Sales Manager	Green ≥ 3×; Yellow 2–2.9×; Red < 2×
Build-ready pass rate	approved jobs / submitted jobs	Leap + gate log	Production Manager	Green ≥ 90%; Yellow 80–89%; Red < 80%
Production cycle time	job_complete − scheduled_start (days)	Leap	Production Manager	Green ≤ 14 days; Yellow 15–21; Red > 21
Documentation completion	evidence-complete jobs / active jobs	CompanyCam + PM review	Production Manager	Green ≥ 95%; Yellow 85–94%; Red < 85%
Invoice lag	invoice_issued − job_complete (days)	Leap	AR Admin	Green ≤ 2 days; Yellow 3–5; Red > 5
DSO	AR balance / (period revenue / 30)	Leap	AR Admin	Green ≤ 30; Yellow 31–45; Red > 45
Dunning compliance	on-time dunning actions / total due	Leap + collections log	AR Admin	Green ≥ 95%; Yellow 85–94%; Red < 85%
Dispute rate	disputed invoices / total invoices	Leap	AR Admin	Green ≤ 3%; Yellow 4–6%; Red > 6%
Review capture rate	posted reviews / eligible completed jobs	GHL	Marketing / CSR	Set after review engine confirmed
Referral lead rate	referral leads / total leads	GHL	Marketing / CSR	Set after 60 days

How KPIs Are Used

KPIs are management instruments, not scorecards. A red number is a flag that something needs investigation and a response — not a punishment. The Sales Manager's job is to look at speed-to-lead numbers weekly and ask: what happened, why, and what changes?

Every KPI in this table has one owner. That owner reviews the metric weekly, identifies the cause of any threshold breach, and either takes corrective action or escalates. A KPI that has been red for two consecutive weeks without a documented root cause and a corrective action is a management failure, not a performance failure.

---

Consolidated Automation Register

Every automation in the system, in one reference. Use this section to build and validate workflows. Use the fallback protocols to operate before each automation is live.

Purpose

Every automation in this system does one of three things: eliminates manual work that creates errors under volume, surfaces exceptions before they become problems, or moves information to the right system at the right moment. Automation does not replace human judgment — it gives humans better information to judge with.

An automation that fires on ambiguous stage meaning, missing preconditions, or incorrect data does more damage than no automation at all.

Automation Pattern

flowchart TD
  T["Trigger event"] --> C["Preconditions checked"]
  C -->|All pass| A["Action executes"]
  C -->|Any fail| E["Exception created"]
  A --> O["Output written to system of record"]
  E --> F["Fallback owner assigned and notified"]

Every automation follows this pattern. No automation runs without a precondition check. Every failure creates a visible exception with a named owner.

Automation Entries

Any change to an entry requires a change-control record (Section 18). Entries marked Pending Config require live-system setup before they can be considered operational. Entries marked Tenant Validation Required require live-tenant confirmation.

---

A-01 — New Inbound Lead Created

System: GHL → Leap | Owner: Marketing / CSR

Trigger	New lead created from tracked intake path
Preconditions	Contact data present; duplicate policy applied; GHL-Leap linked-lead contract configured
Action	Create GHL contact; assign owner; send acknowledgement; create first-response next action; initiate linked Leap lead with cross-system IDs
Output	GHL record + linked Leap lead; SLA clock running; acknowledgement sent
Failure mode	Duplicate lead; Leap lead not created; cross-system IDs missing
Fallback	Marketing / CSR manually creates Leap lead and writes GHL contact ID to both records. Daily exception audit: any inbound lead created in GHL with no linked Leap lead ID is treated as a manual entry error and corrected same day.
Status	Pending Config Tenant Validation Required — mechanism for linked-lead creation and ID writing must be confirmed in live tenant

---

A-02 — Lead Untouched Beyond SLA

System: GHL | Owner: Sales Manager

Trigger	Active inbound lead; no qualifying human attempt logged; no suppression condition active
Preconditions	SLA window defined; lead not already assigned to active contact attempt
Action	Fire task reminder; create manager escalation
Output	SLA breach visible; reassignment need surfaced
Failure mode	False positive (rep worked lead outside system); SLA window not set
Fallback	Sales Manager reviews the GHL contact feed each morning for leads created in the prior 24 hours with no logged outreach attempt. Breached leads are reassigned before noon same day.

---

A-03 — Customer Replies on Tracked Channel

System: GHL | Owner: Sales Rep

Trigger	Lead enrolled in follow-up; reply received through supported channel
Preconditions	Reply channel is supported by suppression logic
Action	Stop all automated sequences; create high-priority respond-now task
Output	Human takes over; no further automated messaging
Failure mode	Reply through unsupported channel not detected; sequences continue
Fallback	Manual stop rule: Sales Manager reviews active GHL sequences daily and manually suppresses any sequence where a customer reply is visible in the conversation thread but sequences haven't stopped.
Status	Pending Config — reply suppression coverage must be tested across all active channels

---

A-04 — Appointment No-Show or Cancellation

System: GHL | Owner: Sales Rep / Sales Manager

Trigger	Scheduled appointment time passes; outcome not logged, or outcome is no-show / cancellation
Preconditions	Appointment record exists; outcome field monitored
Action	Create reschedule / follow-up task; move record to recovery sequence
Output	No-show lead stays visible; recovery path triggered
Failure mode	Outcome never logged; record goes dark; wrong status mapping
Fallback	Sales Manager reviews all Appointment Set records each morning for appointments whose scheduled date has passed with no inspection-complete event logged. Each record is addressed in the same business day.

---

A-05 — Contact-Established Event (Inbound Lead)

System: GHL + Leap | Owner: Ops Systems Owner

Trigger	Two-way tracked SPD contact confirmed for inbound lead
Preconditions	Inbound lead has linked Leap record with cross-system IDs; qualifying contact logged
Action	Stop GHL customer-facing messaging; mirror contact-established status to GHL; shift working system to Leap
Output	Leap is primary rep workspace; GHL sequences stopped; status mirrored
Failure mode	Contact event not detected; GHL continues messaging; two systems messaging same customer simultaneously
Fallback	SPD logs contact-established status in Leap and manually notifies Sales Manager to suppress the GHL sequence. Sales Manager suppresses manually and logs the suppression. Exception queue: any active GHL sequence for a contact whose Leap record shows contact-established is a live error requiring same-day resolution.
Status	Pending Config Tenant Validation Required — depends on linked-lead integration method being confirmed and tested

---

A-06 — Narrow Leap-to-GHL Writeback

System: Leap → GHL | Owner: Ops Systems Owner

Trigger	One of the four approved writeback events: qualification result, appointment status, contact-established status, or recycle / disqualify outcome
Preconditions	Event is within the four-field writeback contract; cross-system IDs exist in both records
Action	Mirror only the four approved fields into the GHL record
Output	GHL record updated for suppression, reporting, and hygiene
Failure mode	Writeback outside approved field map; sync drift; GHL receives data it should not
Fallback	Manual handoff checklist: SPD provides Sales Manager with a status update on each inbound lead at contact-established and at appointment-confirmed. Sales Manager manually updates the GHL record for suppression purposes until the writeback is live.
Status	Pending Config Tenant Validation Required — integration mechanism (native, webhook, or middleware) must be specified

---

A-07 — Job Submitted for Build-Ready Review

System: Leap + CompanyCam | Owner: Production Manager

Trigger	SPD submits completed build-ready packet; record enters Preproduction Ready
Preconditions	Required fields, selections, site constraints, and handoff packet complete enough to review; SPD has notified PM in writing
Action	PM runs Build Ready gate review; creates missing-item defect tasks or approves; on approval, record advances to Ready to Schedule
Output	Build Ready gate passed (job in Ready to Schedule), or explicit defect list with owners and deadlines (job returns to Job Awarded)
Failure mode	Stage gating cannot block progression; required artifacts in scattered notes; Preproduction Ready and Build Ready gate conflated
Fallback	PM reviews Preproduction Ready queue every Monday morning. SPD sends explicit notification to PM when packet is complete. PM issues defect list via Leap task if gate fails; job returns to Job Awarded. Coordinator does not schedule without written PM Build Ready gate approval. See State 6 interim manual protocol.
Status	Pending Config Tenant Validation Required — Leap stage-lock behavior and the artifact checklist must be confirmed

---

A-08 — CompanyCam Evidence Phase Completed

System: CompanyCam | Owner: Crew Lead / Production Manager

Trigger	Required photo or checklist pack is complete for pre-job, install, or QC phase
Preconditions	Correct linked project exists; photos captured and tagged; PM review path defined
Action	Surface evidence set for PM review; save required assets into Leap job
Output	Evidence pack supports QC, closeout, and dispute defense
Failure mode	Photos captured but not tagged; not saved into job; project not linked
Fallback	Crew Lead changes project label to DOC-ReadyForQC and sends Leap message to PM. PM checks CompanyCam review queue daily. Weekly documentation compliance review by Ops Systems Owner surfaces any jobs with incomplete or unreviewed evidence.
Status	Pending Config Tenant Validation Required — CompanyCam plan tier, checklist templates, and Save In Job behavior must be confirmed

---

A-09 — Job Complete / Evidence Gate Cleared

System: Leap | Owner: AR Admin

Trigger	Job Complete confirmed with PM sign-off on final evidence
Preconditions	Completion confirmed; final evidence package PM-reviewed; invoice truth in Leap
Action	Issue invoice; set AR follow-up tasks; timestamp invoice event
Output	Job enters AR ladder with clean starting point
Failure mode	Job marked complete without evidence review; invoice released before PM sign-off
Fallback	PM sends written authorization to AR Admin via Leap message or email before any invoice is issued. AR Admin does not invoice without this written authorization on record. Daily completed-not-invoiced exception list reviewed by AR Admin and Sales Manager.

---

A-10 — Invoice Crosses Aging Threshold

System: Leap + communication layer | Owner: AR Admin

Trigger	Invoice age exceeds day 7, 14, or 30 threshold
Preconditions	Invoice exists; due date and balance accurate in Leap; dispute status known
Action	Send reminders; create follow-up tasks; escalate by tier
Output	Collections activity timed, visible, and owned
Failure mode	Wrong due date; disputed invoice treated as normal overdue; conflicting balances
Fallback	AR Admin reviews the Leap Final Invoice Sent queue every Monday morning. Day 7 and Day 14 reminders sent manually via Leap communication tools. Day 14 escalation list emailed to Sales Manager. Day 30+ aging report provided to Leadership manually.

---

A-11 — Job Reaches Post-Close Review-Request Point

System: GHL | Owner: Marketing / CSR

Trigger	Job reaches Paid & Closed and closeout package confirmed delivered
Preconditions	GHL is single review engine; customer communication policy defined
Action	Send review request; optionally enroll in post-close nurture
Output	Customer enters review or referral lifecycle
Failure mode	Duplicate asks from multiple systems; request before closeout delivered
Fallback	AR Admin notifies Marketing / CSR when zero balance is confirmed. Marketing / CSR manually sends review request through GHL within 24 hours of closeout package delivery. One ask. One system. Logged in Leap as delivered.
Status	Pending Config — exact trigger and nurture enrollment logic must be set up

---

A-12 — Long-Term Nurture and Service-Lane Enrollment

System: GHL | Owner: Marketing / CSR

Trigger	Paid & Closed customer reaches nurture or service-reminder enrollment point
Preconditions	Consent and segmentation fields exist; service-lane ownership defined
Action	Enroll customer in nurture, service reminder, referral, or reactivation sequence
Output	Post-close lifecycle becomes systematic; service requests enter Leap service workflow
Failure mode	Bad segmentation; over-messaging; service-lane ownership confusion
Fallback	Marketing / CSR manually tags completed customers in GHL with installed scope for future nurture targeting. Service requests received by phone or email are manually entered into the Leap service workflow by the CSR.
Status	Pending Config — service-lane routing, segmentation rules, and nurture sequences must be built

---

A-13 — AI Call Review (Phase One)

System: AI + call platform + CRM | Owner: Sales Manager

Trigger	Inbound lead call completed on a supported recorded channel
Preconditions	Call on recorded channel; consent confirmed; reviewer capacity confirmed
Action	Generate draft summary or coaching notes for human review
Output	Faster review cycle with human-approved output
Failure mode	AI summary incorrect; no one reviews output; consent not confirmed
Fallback	Human call notes only, entered by SPD in Leap immediately after call. Sales Manager reviews call recordings manually for coaching purposes until AI review is operational. No AI-generated content enters the CRM without human review and approval.
Status	Pending Config Tenant Validation Required — call topology, consent mechanism, review queue, and retention must all be confirmed before this automation is operational

---

Management Cadence

How the company converts lifecycle data into daily, weekly, and monthly action.

Purpose

A dashboard nobody acts on is not management — it is decoration. The purpose of every review meeting, every exception queue, and every escalation rule in this section is to create visible, owned, timely action. Locke & Ladder manages by exception: the manager's job is to see the things that require intervention and intervene. This section defines what those things are, who sees them, what actually happens in each review, and what the outputs are.

Review Cadence

Cadence	What gets reviewed	Required attendees	Required output
Daily	Exceptions only: untouched leads, stalled records, missing evidence, aging invoices	Department managers (by function, not in a single meeting)	Named exception assigned to an owner before end of business day
Weekly	Scorecard: pipeline health, KPI status, execution velocity, AR standing	Functional leads + all managers	Written summary of threshold breaches and corrective actions; escalations noted
Monthly	Trends: threshold calibration, policy gaps, process improvement opportunities	Leadership	Decision log for any threshold adjustments or policy updates

Daily Review — By Function

Sales Manager (morning, under 15 minutes): Opens the GHL contact feed and Leap lead view. Checks for inbound leads created in the prior 24 hours with no logged outreach attempt. Any breach is reassigned before noon. Checks for active Appointment Set records whose scheduled date has passed with no inspection logged. Each is addressed same day. Checks for any GHL sequences active for contacts whose Leap record shows contact-established. Each is suppressed and logged as an exception.

Production Manager (morning, under 15 minutes): Opens CompanyCam and checks for any jobs labeled DOC-ReadyForQC that have been waiting for PM review for more than one business day. Begins review for any confirmed. Opens Leap and checks for any jobs in Scheduled with a start date today or tomorrow that haven't logged an In Production transition — confirms with Coordinator that crew is on site or confirms the delay.

AR Admin (morning, under 10 minutes): Opens the Final Invoice Sent queue in Leap. Any invoice that crossed a dunning threshold overnight (Day 7, 14, or 30) receives the appropriate contact or escalation action before noon.

Weekly Review — Pipeline and Scorecard

Who runs it: Sales Manager facilitates. Production Manager and AR Admin attend. Leadership attends monthly version.

When: Monday or Tuesday, same time each week, no longer than 45 minutes.

What is reviewed:

Sales pipeline: all open records by lifecycle state. Every record in Proposal Delivered with no follow-up in 7+ days is flagged. Every record in Appointment Set with no inspection logged 5+ days after appointment is flagged. Every record in Inspection Complete with no proposal activity in 3+ days is flagged.

Production queue: all records from Job Awarded through Job Complete. Any job that has been in Job Awarded for more than 10 business days without a PM approval decision is flagged. Any job in Ready to Schedule for more than 5 business days is flagged. Any job in In Production with no progress update in 2 business days is flagged.

AR status: all open invoices by age. Any invoice at Day 14 or beyond is reviewed individually — current contact status, next action, and escalation path.

KPI scorecard: the four primary metrics for the week (speed-to-lead %, close rate, build-ready pass rate, DSO). Threshold breaches are noted. Root cause discussion for any metric that was red for the second consecutive week.

Required output: Written exception list from the meeting (Leap task or shared doc) naming each flagged record, its current status, the assigned owner, and the next action with a due date. Meeting notes are shared with attendees within 24 hours.

Monthly Review — Trends and Calibration

Who runs it: Leadership.

When: First week of each month.

What is reviewed:

KPI trend lines for the prior month. Any metric that has been yellow or red for 3+ consecutive weeks is reviewed for root cause — is the threshold wrong, is the process failing, or is the data unreliable? Decision made: adjust threshold, correct process, or improve data quality.

Validation ledger status: any Tenant Validation Required item that was expected to be resolved in the prior month is reviewed. If still unresolved, a new deadline is set and an owner is confirmed.

Change control log: any changes made in the prior month are reviewed to confirm they were properly logged and that the document reflects current operating truth.

Owner Map

Role	What they own
Owner / Operator	Policy decisions, final exceptions, enforcement culture
Sales Manager	Speed-to-lead, pipeline discipline, rep coaching, contact-established enforcement
SPD / Sales Rep	Lead contact, qualification, inspection, proposal, close
Production Manager	Build-ready approval, scheduling, execution quality, QC sign-off, invoice authorization
Production Coordinator	Pre-production documentation, ordering, permit tracking, scheduling queue
AR Admin	Invoice timing, dunning ladder, payment tracking, aging escalation
Marketing / CSR	Intake quality, attribution accuracy, review operations, nurture hygiene
Ops Systems Owner	System boundary governance, vault publish authority, automation integrity

Exception Rules

Every exception below surfaces automatically (or is identified in daily review) and requires a response before it ages another day.

Exception	Primary owner	Escalation trigger	Escalation path
Uncontacted inbound lead beyond SLA	Sales Manager	SLA breach	Daily sales review; manager reassignment
Active record with no next action	Record owner's manager	Same business day	Exception queue + manager coaching
GHL sequences running after SPD contact	Ops Systems Owner	Contact-established event not mirrored	Manual stop; exception queue until automation confirmed
Build-ready defect not resolved	Production Manager	Missing artifact or unresolved field	Build-ready review loop before scheduling proceeds
Completed job not invoiced	AR Admin	Daily check	AR review + manager escalation
Aging invoice past threshold	AR Admin	Timed AR ladder	Escalation per defined ladder
Evidence incomplete at invoice gate	Production Manager	PM review detects gap	Corrective task; recurring review until resolved
AI summary error found in review	Sales Manager	Human review detects mismatch	Do not write to CRM until corrected
Backward transition (scheduled job cancelled)	Production Coordinator	Cancellation received	Document in Leap; notify PM; resolve materials same day
Job on lateral hold beyond 14 days without leadership exception	State owner's manager	Calendar trigger	Leadership review within 24 hours

---

SOP Vault Governance

Where the company's operational truth is kept, governed, and accessible.

Purpose

Every company that grows past a small team faces the same problem: knowledge about how to do things right starts living in people's heads. When those people are available, things run well. When they are not, things break in ways that are hard to diagnose because nobody wrote anything down. The SOP Vault is the answer to that problem. It is where operational truth is published, versioned, and owned.

Four-Layer Model

Layer	What lives here	Change cadence	Who can modify
Canonical Truth	Approved SOPs, the master framework, the lifecycle dictionary, approved templates	Change control required; leadership sign-off	Ops Systems Owner (with approval authority)
Drafts	Work in progress; not operating truth	Frequent; no restrictions	Any team member, designated by domain owner
Reference	Industry guidance, product specs, background research	As needed	Ops Systems Owner or domain owner
Archive	Retired canon	Read-only; historical reference	No modifications; access controls enforced

How to Add a New SOP

1. The domain owner or a designated author drafts the SOP in the Drafts layer using the canonical SOP template.
2. The domain owner reviews the draft for completeness against the canonical document standard.
3. The domain owner submits the draft to the Ops Systems Owner with a written request for promotion to Canon.
4. The Ops Systems Owner reviews: does the SOP conform to the metadata standard? Does it cover all required sections? Does it conflict with existing Canon?
5. If Canon-ready: Ops Systems Owner promotes to Canonical Truth with metadata completed, version number assigned, and status = canon.
6. If not ready: Ops Systems Owner returns to the author with specific required changes.
7. When promoted to Canon, the Ops Systems Owner notifies affected team members.

Approval authority for Canon promotion: Ops Systems Owner for operational SOPs. Leadership sign-off required for SOPs that define lifecycle states, system boundaries, KPI formulas, or policy.

How to Retire an SOP

1. The domain owner identifies that an SOP is no longer current (superseded by a new SOP, policy change, or system change).
2. Domain owner requests retirement from the Ops Systems Owner in writing.
3. Ops Systems Owner confirms that no active workflows, automations, or references depend on the retiring document.
4. Ops Systems Owner changes status to deprecated and moves the document to Archive.
5. A brief retirement note is added to the document explaining what superseded it and when.
6. Any Canon documents that reference the retired SOP are updated.

No document is deleted from Archive. Historical Canon is preserved for reference, dispute defense, and audit trail.

Canonical Document Standard

Every document in the Canonical Truth layer must carry this metadata. Documents without it are not canon.

Metadata field	Requirement
title	Plain-language name of the process or policy
owner_role	The role accountable for the content (role, not person)
status	draft, under-review, canon, or deprecated
last_reviewed	YYYY-MM-DD — required for canon
next_review	YYYY-MM-DD — required for canon
systems_used	Every tool touched by this SOP
linked_framework_sections	Framework sections this SOP supports
source_basis	Internal evidence or policy decision ID

Every canonical SOP must contain these body sections, in order:

Section	Contents
Purpose	Why this SOP exists and what failure it prevents
Trigger	What event starts the process
Entry Criteria	What must already be true before work begins
Steps	Ordered actions for the executor
Owner	The role accountable for correct completion
Tools	Systems, templates, or forms required
Expected Output	What must exist at the end
QA Check	What must be reviewed before the SOP is considered done
Failure Modes	Common ways this process breaks and how to detect them
Source Basis	Internal evidence or policy decision backing this SOP

SOP Vault Domain Map

Domain	Domain owner	Primary Canon documents
Lead intake and qualification	Sales Manager / Ops Systems Owner	Intake checklist SOP, deduplication protocol, source tagging guide
Sales process	Sales Manager	Contact-established procedure, proposal delivery standard, close protocol
Build-ready and handoff	Production Manager	Build-ready checklist by trade, handoff packet standard
Field execution	Production Manager	Phase evidence requirements, change-order documentation protocol
AR and collections	AR Admin	Invoice release procedure, AR dunning ladder, dispute classification
Post-close	Marketing / CSR	Closeout package assembly, review request protocol
CompanyCam	Ops Systems Owner	Tag taxonomy guide, checklist template library
Insurance	Insurance Coordinator	Insurance overlay activation, supplement submission protocol
AI use	Sales Manager	Phase-one scope, consent deployment, review queue procedure

---

AI Governance

Draft support and canon retrieval under human governance.

Purpose

AI can make this team meaningfully faster — at reviewing calls, at documenting interactions, at retrieving company knowledge. Used with governance, it is a competitive advantage. Used carelessly — without review, without consent, without boundaries — it creates problems that are hard to detect until damage is done. This section defines the operational scope, the rules, and the non-negotiables.

Phase-One Scope

Phase one covers inbound lead calls only. Before phase one can be considered operational, five preconditions must all be confirmed:

1. Consent is deployed on every recorded channel.
2. A human review queue exists with a named owner who reviews every AI output before it enters the CRM.
3. Retention and access controls are documented.
4. The call topology is mapped — which channels are recorded, by whom, with what system.
5. The consent mechanism is tested and confirmed — not assumed.

Allowed Uses

Use	Governing rule
Draft summaries from reviewed calls	Human review required before any output enters the CRM. The reviewer is the named queue owner. No AI summary is treated as accurate until the reviewer confirms it.
Coaching support from call analysis	Sales Manager confirms the coaching point before acting on it. AI coaching suggestions are inputs, not conclusions.
SOP vault retrieval	Canon-only. AI explicitly acknowledges uncertainty when the canon does not answer the question. AI does not retrieve from Drafts or Archive.
Draft message assistance	Human owns the final send decision — always. No AI message goes to a customer without a human having reviewed and approved the specific message.

Disallowed Uses

Use	Why
Autonomous customer-facing AI execution	Risk without proven evidence quality and lifecycle governance
AI as final truth for customer commitments	Transcripts and summaries are fallible; humans are accountable
Retrieval from Drafts or Archive	Blends obsolete or unapproved material into current truth
Expanding scope before phase one is proven	Review capacity and consent deployment must be established first
AI populating lifecycle stages or field values without human review	Stage truth must come from a human judgment about what is actually true

Error Protocol

When an AI summary error is found during human review:

1. Do not write the incorrect output to the CRM.
2. The reviewer corrects the output and enters the corrected version.
3. The error is reported to the Sales Manager with a description of what was wrong.
4. Sales Manager determines whether the error type is a pattern or a one-off. Patterns trigger a review of the prompt or configuration.
5. The error is not suppressed or hidden. Transparent error tracking is the mechanism by which the AI use evolves from phase one to phase two.

Consent Requirement

Customer-facing AI communications — any message drafted with AI assistance and sent to a customer — must disclose AI involvement where required by law and consistent with the consent posture established by leadership. The specific consent mechanism (passive notification, active checkbox, or other) is an unresolved conflict requiring a leadership decision before any AI-assisted customer-facing communication goes live. See Section 12, Unresolved Conflicts.

---

Change Control

How canonical truth changes — and how changes are tracked.

Purpose

A process that works today but cannot be updated officially is a process that will silently drift. Stage definitions get interpreted loosely. Automation runs on rules that no longer match the business. KPI formulas diverge from the fields that actually exist. Change control is how the company keeps its operating system trustworthy over time.

What Requires Change Control

Any change to the following requires a change-log entry before it is reflected in the canonical Markdown and a republished DOCX before it is distributed:

• Lifecycle state definitions
• System boundary rules
• Automation triggers or logic
• KPI formulas or definitions
• Policy decisions
• Insurance overlay architecture
• SOP vault governance rules
• Backward or lateral transition rules

Change Process

1. The proposer (any team member) identifies a needed change and describes it in writing: what is changing, why, and what the proposed new language or rule is.
2. The domain owner for that section reviews the proposal. If the change affects a lifecycle state, system boundary, KPI formula, or policy, Leadership review is required.
3. The domain owner (or Leadership) approves, rejects, or requests modification.
4. If approved: the Ops Systems Owner updates the canonical Markdown, creates a change-log entry, and publishes the updated DOCX to the SOP Vault.
5. Affected team members are notified with the effective date.
6. If rejected: the rejection is documented with the reason. The proposer may resubmit with additional evidence or accept the decision.

How a Staff Member Proposes a Change

Any team member may propose a change to the framework. Proposals are submitted to the relevant domain owner (see Section 16 SOP Vault Domain Map) in writing, using the following format:

• What section of the framework is affected
• What the current language or rule says
• What the proposed change is
• Why the change is needed (operational evidence, policy update, or error correction)

The domain owner responds within 5 business days with a decision or a request for more information. Proposals that have been pending for more than 10 business days without a response are escalated to Leadership.

Change Log

Date	Change	Sections	Approved by
2026-03-22	Initial audited v1.1 Bible published	All	Leadership
2026-03-23	Early-owner boundary override adopted: linked Leap lead at intake; SPD contact = working-system shift; Leap = booking authority; manual leads bypass GHL	Sections 3–7, 14	Leadership
2026-03-23	Insurance overlay merged into canon	Section 10	Leadership
2026-03-23	All P0, POL, SYS, OWN, and LIFE decisions adopted; V2 rewrite issued with lifecycle-first structure, Pending Config/Tenant Validation Required labeling	All sections	Pending leadership review
2026-03-23	V3 published: lifecycle-first structure established; Sections 1–12	All 12 sections	Pending leadership review
2026-03-23	V4 published: interim manual protocols added to all state blocks; backward/lateral transition rules added to Section 6; interim manual protocols added for all Validate-External lead channels; behavioral enforcement descriptions added to Section 9; exception path examples added to Section 11; KPIs restored as Section 13; Automation Register restored with fallbacks as Section 14; Management Cadence restored and expanded as Section 15; SOP Vault Governance restored and expanded as Section 16; AI Governance restored and operationalized as Section 17; Change Control restored as Section 18	All 18 sections	Pending leadership review
2026-03-23	V5 published: Leap SalesPro documented as adopted proposal tool with full capability description; JobNimbus documented as current interim estimating tool pending SalesPro pricing configuration; three separate automation behavior fields consolidated into single Automation summary field in all 12 state blocks; lifecycle phase groupings (Sales Phase, Production Phase, Financial Close) added to Section 3; state block reading guide added to Section 3; language-clarity pass applied throughout; Section 8 expanded to five tools; SalesPro moved from Validation Required to Explicitly Supported in Section 12; State 4 interim manual protocol updated to document the current JobNimbus-to-SalesPro transition	All 18 sections	Pending leadership review

---

End of Locke & Ladder Master Operating Framework V8 — 2026-03-23