Quartz 5

clg_delivery_blueprint

7 min read

📋 CLG & MemberDev Strategic Alignment Blueprint (REVISED v2)

WayCup Fractional CTO Deliverable — June 2026

This document details the functional specifications, visual data architectures, and strategic alignment questionnaires for the Conscious Leadership Group (CLG) Leadership Team and MemberDev Development Team (ali@memberdev.com).

💡 How to Use This Document

  1. Google Docs: This file is written in standard markdown. You can copy/paste any section directly into your client Google Docs, and formatting will persist beautifully.
  2. Miro.com: The diagrams below are written in Mermaid.js syntax. In Miro, open the Mermaid app, paste the code block, and Miro will instantly render it as a fully editable visual flowchart.

SECTION 1: MemberDev Client Portal Integration Spec

Target Audience: Ali Jafarian (ali@memberdev.com) & WordPress Dev Team

The goal is to establish HubSpot as the Single Source of Truth (Main Brain) for operational state, pushing instant updates to WordPress (The Client Window) using real-time webhook endpoints.

1.1 Webhook & Sync Architecture Diagram (Miro-Ready)

Paste this code block into Miro’s Mermaid app:

flowchart TD
    subgraph HubSpot [HubSpot - Single Source of Truth]
        A[Trigger: Project Created / Updated] -->|POST Webhook payload| B(Developer Outbound Webhook)
        H[Contact Status Changed] -->|POST Webhook payload| B
    end

    subgraph WP [WordPress Portal - MemberDev]
        B -->|Ingest API Endpoint| C{WP Router / Webhook Controller}
        C -->|Action: Create/Update| D[Custom Post: Learning Path]
        C -->|Action: Sync Status| E[WP User Meta Data]
        D -->|Save Success| F[Return WordPress Program ID]
    end

    F -->|Callback Sync| G[HubSpot Field: portal_user_id]

1.2 Data Schemas & Handshakes

A. WP User Profile Sync (Contact Record Trigger)

When a WordPress User profile state transitions, HubSpot updates matching properties, and vice-versa.

HubSpot Contact PropertyInternal API NameExpected Ingestion ValueContext / Notes
Contact IDid12345678 (Integer)HubSpot Unique ID; must be stored in WP user meta as user_hubspot_cid.
CLG Portal User IDportal_user_id9876 (Integer)WordPress User ID; synced back to HubSpot to lock associations.
Portal User Typeportal_user_typeSuper Admin, Coach, Client, SubscriberDetermines user layout capabilities in the WordPress front-end.
Portal Statusportal_user_statusInvited, Active, InactiveDrives registration triggers and access controls.

B. Project to Learning Path Ingestion (Project Object Trigger)

When a client program cohort is initialized, a HubSpot Project custom record is created, prompting HubSpot to push a webhook payload to WP.

Expected Webhook POST Payload Schema (HubSpot ➔ WordPress):

{
  "event": "project.created",
  "project_id": "56690715060",
  "properties": {
    "task_name": "Conscious Leadership Foundations - June 2026",
    "hs_type": "FOUNDATIONS",
    "hs_start_date": "2026-06-30T00:00:00Z",
    "hs_target_due_date": "2026-08-31T00:00:00Z",
    "coach_assigned": "Joyce Chen"
  }
}

1.3 Strategic Questions for MemberDev (ali@memberdev.com)

IMPORTANT

Please review and answer the following questions to help us finalize the API/Webhook endpoint setups:

  1. Authentication Strategy: What is the preferred authorization protocol for HubSpot webhook payloads hitting your custom WordPress REST API endpoint? (Recommend: HMAC signature verification using HubSpot’s secret, or standard Bearer JWT).
  2. Error Handling & Queues: If a webhook fails to deliver (e.g., due to temporary server maintenance), how should we handle retries? HubSpot automatically retries failed webhooks over 24 hours, but does MemberDev have an ingestion queue or idempotency keys to prevent duplicate creation of Learning Paths?
  3. Program ID Synchronization: Once WordPress creates a custom post for a Learning Path, how will the WordPress Post ID be synced back to the HubSpot Project record? Should WordPress make a PATCH API request to HubSpot, or should the webhook response payload return the ID for HubSpot to process?

SECTION 2: Custom JS Commission Engine Spec

Target Audience: CLG Leadership, Accounting/Finance, & Kevin (Reviewers)

The objective of the Commission Engine is to calculate multi-coach attribution margins dynamically per Deal/Line Item and auto-generate detailed earnings ledger lines.

2.1 Multi-Coach Commissions Architecture (Miro-Ready)

Paste this code block into Miro’s Mermaid app:

flowchart TD
    A[Deal Marked Closed-Won] --> B{HubSpot Custom JS Workflow}
    
    subgraph Calculation Engine [Dynamic Commission Splits & Kickers]
        B -->|Check Financing Fees| C[Net Amount Calculation]
        B -->|Check Coach YTD Commission| D{YTD >= $150K?}
        D -->|Yes| E[Apply +5% Work Kicker]
        B -->|Check Deal Split Property| F{Is Work Split Enabled?}
        F -->|Yes| G[Divide Work Commission 50/50 max 2 users]
        B -->|Check L/W/C Owners| H{Same Person L/W/C?}
        H -->|Yes| I[Apply +5% Network Builder Kicker]
    end

    subgraph Ledger State Machine [Invoice vs Payment Ledger]
        E & G & I --> K[Create clg_earnings: Contractual Claim - PENDING]
        L[Real Payment Received on Invoice] -->|Payment Event| M[Create clg_payouts: Cash Disbursement - ELIGIBLE]
    end

2.2 Custom Object Ledger Structures & Naming

To maintain complete accounting audit parity, we use a clean Double-Ledger system where the names are descriptive and the coach is tracked as the standard Owner property.

1. clg_earnings (Accrual / Contractual Claim Ledger)

Tied directly to the closed Deal and its associated Line Items.

  • Record Naming Format: [Customer] - [Product/LineItem] - [Category] (e.g., Stephanie Borman - Individual Coaching - work).
    • No prefix is used, and there is no need for the coach name in the record name.
  • Owner Property: Set to the assigned coach. The object itself is an earning, and the coach is represented as the standard “Owner” property.
  • Properties:
    • total_potential_commission: Maximum potential commission once the deal is fully paid.
    • balance_owed: The remaining amount that has not yet been disbursed.
    • amount_paid: Sum of all associated payouts.
    • status: Dropdown (Pending, Partially Paid, Fully Paid, Cancelled).

2. clg_payouts (Cash / Disbursement Ledger)

Tied directly to individual payments received against invoices. Each payout record represents physical cash due.

  • Record Naming Format: [Coach Name] - [Invoice Payment Date] (e.g., Joyce Chen - 2026-06-30).
    • Strictly no prefix in the name.
  • Owner Property: Set to the paid coach.
  • Properties:
    • disbursed_amount: Cash amount released from the clg_earnings balance based on the cash received.
    • payout_status: Dropdown (Eligible for Payout, Sent to Payroll, Disbursed).
    • transaction_reference: QBO invoice payment ID or Stripe transaction number.

2.3 Comprehensive CLG Commission Structure

The Custom JS engine parses Deal/Line Item properties and applies the following multi-tiered structural rules:

1. Lead Commission (10%)

  • Internal Lead: 10% commission follows indefinitely on all engagements sourced.
  • Outside Lead (Referral): 10% commission applies strictly once, at the time of referral.

2. Work Commission (45%)

  • Allocation: 45% of revenue allocated to the person(s) delivering the work.
  • Shared Delivery: This percentage can be split among multiple contributors if shared delivery. Multiple users, 45% split 50/50, between 2 users max — AM assigned (resulting in 22.5% Work commission for each contributor).

3. Additional Work Commission (+5%)

  • The Scale Kicker: Once an individual earns $150K in commissions (accumulated within the current calendar tax year after W-2 payback is cleared), they receive an additional 5% on all work commissions.
  • Data Ingestion Verification: Validate with Data Hub (Additional property, discover “where”). We will cover this with Tiffany at the end of October.
  • Visual Progress Bar: Must include a VISUAL progress bar tracking their progress toward this $150K scale milestone!

4. Close Commission (10%)

  • Awarded to: The person who closes/sells the engagement (Qualified the Lead and passed to the AM/Deal Pipeline).
  • Expiration Term: Applies for one year following the sale. After one year, this percentage shifts automatically to the “Work” allocation.

5. Network Builder Commission (5%)

  • Full-Stack Bonus: Paid when the same person is responsible for Lead, Work, and Close (L/W/C). Driven automatically by conditional if/then user field comparison checks in the script.

6. Partner Percentage (10%)

  • Partner Allocation: A flat 10% partner allocation applies on all engagements.
  • Split Partners: If two or more partners are on a deal, the partner percentage will get split. Never more than 3 partners, which is rare but possible.

2.4 Strategic Questions for CLG Leadership & Finance

IMPORTANT

Please review and answer the following questions to help us finalize the ledger and QuickBooks sync specs: We should ask CLG if they want the QBO chart of account account number [XXXX] as the prefix for both earnings (accrual) and payouts (cash) ledgers.

  1. QBO Chart of Account Prefixes: Would you like us to prefix both the Earnings and Payouts records with your QuickBooks Online Chart of Account numbers [XXXX] (e.g. [4011] Stephanie Borman - Individual Coaching - work) to streamline matching for your bookkeeper?
  2. Financing Fee Line Items: How are financing/payment-plan interest fees marked on the Deal? Is there a separate SKU, or is it a specific checkbox on the Deal record?
  3. W-2 Payback Metrics: For the $150K Work Kicker, is the “W-2 payback” deduction tracked as a custom HubSpot property, or does the script need to read this from an external data source?
  4. Data Hub Integration: For the Additional Work Commission Kicker, where does the “where” data tracking property reside, and is it ready for validation with Tiffany at the end of October?

Graph View

Backlinks