Pro Church Tools — Company OS

Makeovers v2 — Eligibility & Tracking

8 min read

Makeovers v2 — Eligibility & Tracking

For agents: v2 opens makeover eligibility to existing Nucleus customers (v1 was new-only). Detection is self-identification at Screen 8 of the makeover modal — there’s no automated lookup. Design locked; engineering shipped 2026-05-03.

Why v1 vs. v2 differs

v1 was new-customer-only: every delivery = new MRR. v2 opens eligibility to existing customers via three paths:

  • Existing Essential (MRR < $99, any v1 status) → binary Standard-or-Complete choice via Template C
  • Existing Standard ($99 ≤ MRR < $199, any v1 status) → must commit to Complete via Template B
  • Existing Complete (MRR ≥ $199, any v1 status) → no plan change; gets Mission Control as a free retention add-on via Template A
  • New → standard funnel; lands on Standard with a Complete upsell during delivery

Tracking can no longer assume “deliveries = new customers.” The admin and dashboard must distinguish the three states.

How existing-customer detection works

Existing-customer status is self-identified at the moment of claim, not detected at audit submission. The Comms Dept Firebase app has no programmatic access to Nucleus’s customer database, and there’s no manually-maintained reference to query.

  1. Audit submission is universal. Same Church Chaos Index audit for everyone.

  2. The post-audit drip is universal until the customer self-identifies and agrees to the proposal. Same 7-email + 3-SMS sequence (follow-up-sequence) fires for every audit-delivered church. Drip suppresses only when the church is entered into the Existing Users sheet — which only happens after the customer agrees. The 15-min sync flips church.v2Eligibility.isExistingNucleusCustomer to true; the dispatcher’s next tick suppresses any remaining sends with reason entered_existing_customer_pipeline. Pre-agreement, the drip continues — fine, since nothing is committed.

  3. Branching happens on Screen 8 of the makeover sign-up modal (makeover-offer):

    • Primary CTA — “Let’s Go!” → nucleus.church/purchase/makeover → standard new-customer pipeline (V2 Makeover sheet, claim-to-delivery-ops).
    • Secondary CTA — “Already a Nucleus customer? Click here to claim your makeover.” → opens a follow-up modal with an “Email Us” button → pre-populated email to the team.

  4. The team validates, proposes, and only commits the church to the pipeline after agreement:

    • (a) confirm existing customer
    • (b) look up MRR + v1 history in Nucleus admin
    • (c) apply the resolution algorithm → outcome + reply template (A/B/C from existing-customer-reply-scripts)
    • (d) send the matching reply — this IS the proposal; no row exists yet
    • (e) on agreement, add the church to the Existing Users sheet with all fields populated. Sheet entry is the commitment moment: billing for the upgraded tier kicks in here; the makeover build follows.

    If the customer declines or goes silent, no row is created and no billing changes.

Resolution algorithm

Applied during team validation, in fixed order — first match wins:

1. MRR ≥ $199 (Complete tier, any v1 status)        → mission_control_only
2. MRR < $99 (Essential tier, any v1 status)        → eligible_no_gate
3. $99 ≤ MRR < $199, hadV1Makeover = true           → eligible_must_upgrade_first
4. $99 ≤ MRR < $199, no v1                          → eligible_must_upgrade_first

Tier short-circuits v1 history. Complete-tier always resolves to mission_control_only. Essential-tier always resolves to eligible_no_gate — even with v1 history, since Essential→Standard alone is a meaningful plan lift and forcing $40-ish/mo customers to commit $199/mo is too steep an ask. Only Standard-tier customers (with or without v1) hit the must-upgrade-to-Complete gate.

Reply template per outcome:

  • mission_control_only → Template A
  • eligible_must_upgrade_first → Template B
  • eligible_no_gate → Template C

Outcome matrix

Customer statev2EligibilityOutcomeWhat they getNet new MRR
Used primary CTA — assumed neweligible_no_gateFull v2 makeover via V2 Makeover sheet; lands on Standard ($99); Complete upsell post-delivery$99 (or $199 if upgraded)
Secondary CTA, MRR ≥ $199 (Complete, any v1)mission_control_onlyMission Control installed on existing site; no plan change; Pro Church Certified scholarship optional$0 — retention play
Secondary CTA, MRR < $99 (Essential, any v1 status)eligible_no_gateFull v2 via Existing Users sheet; binary choice — lift to Standard ($99) or Complete ($199)$50–160 depending on starting MRR + chosen tier
Secondary CTA, $99 ≤ MRR < $199, hadV1 = trueeligible_must_upgrade_firstFull v2 via Existing Users sheet; must commit to Complete before fulfillment$100
Secondary CTA, $99 ≤ MRR < $199, no v1 (Standard)eligible_must_upgrade_firstFull v2 via Existing Users sheet; must commit to Complete$100
Self-identification miss(re-routed)Team manually re-routes to the correct pipelinePer the corrected outcome

The “must commit to Complete” gate applies only to Standard-tier customers ($99 ≤ MRR < $199). Essential-tier customers (any v1 status) get the binary Standard-or-Complete choice; the plan lift covers MRR justification without forcing the top tier.

The Mission Control-without-makeover path (Complete-tier only)

For Complete-tier customers resolved to mission_control_only:

  1. Mission Control gets installed on their existing Nucleus site — the 8-document private Posts collection (v2-package). No website rebuild, no photography, no Plan-A-Visit sequence rebuild.
  2. A short Loom walkthrough explains what was added.
  3. Pro Church Certified scholarship offer is available if they want team training.

The two-pipeline operational model

PipelineSheetCustomer scopeEntry point
New-customerV2 Makeover sheetPrimary CTA only — net-new customers who have never paid us beforeScreen 8 → “Let’s Go!” → nucleus.church/purchase/makeover → claim-to-delivery-ops
Existing-customerExisting Users sheet (1XOoKxLcL0bYFghFsMVHWyCjYDysHvasm5cM0KlN2Vfw)Secondary CTA — every existing Nucleus customer regardless of tier or v1 history (mission_control_only, eligible_must_upgrade_first, eligible_no_gate)Screen 8 → secondary CTA → “Email Us” → team validates → proposal → agreement → row added

An existing Nucleus customer is an existing customer, full stop. Tier and v1 history affect the offer (Template A/B/C), never the pipeline. If they’re paying us, they go through the existing-customer pipeline.

The Existing Users sheet is the operational tracker for existing-customer fulfillments — NOT a customer database. Rows get added only after customer agreement. Sheet captures customer-state data (existingPlanMrr, hadV1Makeover, v2EligibilityOutcome) plus operational columns (Application Date, Site URL, Delivery Date, etc.).

Sheet → Firestore mirror runs every 15 minutes (same cadence as the V2 Makeover sheet sync).

There is no automated post-delivery follow-up sequence for existing-customer fulfillments. The personal email exchange is the entire interaction.

Tracking (Comms Dept admin / Firebase)

The admin app at admin.thecommsdept.com (same Firebase app as Attribution v1, see attribution) tracks customer state through fulfillment.

Source of truth for existing-customer state: the Existing Users Google Sheet (1XOoKxLcL0bYFghFsMVHWyCjYDysHvasm5cM0KlN2Vfw). Mirrored to Firestore every 15 minutes; dashboard reads from the mirror.

Per-church fields

New-customer pipeline (V2 Makeover sheet → Firestore):

  • isExistingNucleusCustomer = false by default. Stays false unless the team flips it during validation (which re-routes to the existing-customer pipeline).

Existing-customer pipeline (Existing Users sheet → Firestore):

  • isExistingNucleusCustomer = true
  • existingPlanMrr (number) — the church’s current Nucleus MRR. Replaces the old existingPlanAtAudit enum (Nucleus has too many pricing permutations to bucket cleanly). Tier comparison happens at query time against $199/$99 thresholds.
  • hadV1Makeover (boolean)
  • v2EligibilityOutcome (enum: eligible_no_gate | eligible_must_upgrade_first | mission_control_only) — derived from the algorithm during validation; entered into the sheet only after customer agreement.
  • requiredCommitmentTier (nullable enum: complete) — currently always complete; field exists for future flexibility.
  • commitmentCapturedAt (nullable timestamp) — synonymous with the sheet’s Application Date column. Populated when the team enters the church into the sheet. Billing for the upgraded tier kicks in at this point. One-shot guarded — once set, sheet edits don’t overwrite it.
  • planAtDelivery (string) — plan at fulfillment. Compared against the tier inferred from existingPlanMrr to compute net new MRR.

What’s NOT in the build

  • No Cloud Function for email-exact lookup at audit submission — there’s nothing to look up against.
  • No Stage 1.5 routing in the new-customer pipeline — branching happens at Screen 8.
  • No not_eligible_other outcome — without automated lookup, the domain-match-without-email-match edge case doesn’t exist.
  • No automated post-delivery follow-up sequence for existing-customer fulfillments.

Implementation pointers (the-comms-dept repo)

Build shipped 2026-05-03.

SurfacePath
Screen 8 modal (secondary CTA + Email Us sub-modal)apps/audit/src/components/audit/sections/NextStep.jsx
Existing Users sheet → Firestore syncfunctions/src/sequences/syncExistingUsersSheet.js
Drip suppression gatefunctions/src/sequences/processQueue.js — suppressForExistingCustomer helper
Dashboard “Existing-customer v2 fulfillments” paneladmin.thecommsdept.com (mirrors Attribution v1 structure)

Gotchas

  • commitmentCapturedAt is one-shot guarded. Sync writes it only if currently null — Application Date drift on the sheet doesn’t overwrite captured timestamps.
  • v2Eligibility map populates only via sheet sync. New-customer audits never receive the map. Don’t query the field expecting a default; check for the map’s presence.
  • Drip suppression gate side effects (all logged with reason entered_existing_customer_pipeline): triggering row marked skipped; remaining sequence rows cancelled via cancelPendingForSequence; <sequence>.active flipped to false with removedAt + removalReason stamped. Idempotent — subsequent ticks no-op.
  • Suppressible sequences: main, comms_dept, makeover_delivery. Excluded: confirmation (one-shot at audit submission, fires before sync can flip the flag).
  • Removed-from-codebase artifacts (in case stale PRs/docs reference them): audit-submission lookup helpers, the v2EligibilityAlert module, not_eligible_other outcome + reconciliation queue, runMakeoverDelivery v2 gate. All gone.

Dashboard requirements

Add a new section to admin.thecommsdept.com/attribution: “Existing-customer v2 fulfillments” — sourced from the Existing Users sheet → Firestore mirror.

  • Count of existing → Complete upgrades (date, church, MRR delta) — from eligible_must_upgrade_first
  • Count of Mission Control-only fulfillments — from mission_control_only
  • Per-church timeline — entry MRR, makeover date, exit plan, days-to-upgrade

Essential customers redirected to the new-customer pipeline get tracked in the standard new-customer section, not this one.

MRR accounting rules

  • “New MRR from v2 makeovers” counts NET MRR per fulfillment, not gross plan revenue. Standard → Complete = $100 net, not $199.
  • Dashboard exposes both views — net new MRR (the honest number) and gross subscription revenue (for finance/cohort reporting). Don’t conflate them.
  • A Mission Control-only fulfillment to a Complete customer = $0 net MRR. Track the fulfillment for service delivery; don’t claim MRR growth.
  • First-bill payback math (paid-ads-formula) only applies to new customers — existing-customer fulfillments don’t qualify against the Day-60 payback constraint.

Graph View

Backlinks