The current shape of the work — and what we're proposing.
Pioneer Music currently re-engages dormant dealers (90+ days quiet) through informal branch effort and shared lists. The work is real — the structure isn't. We propose replacing list-chasing with a managed program every branch runs the same way.
Six components, all required
- Dormancy signal — calculated property on the dealer record, auto-flips at 90 days
- Reactivation Deal pipeline — one cycle per dormant dealer, six explicit stages
- Qualification playbook — attached to the initial contact stage, captures why / current state / receptivity
- Reactivation Tab on the dealer record — renamed from Trends; single-pane view of state, history, and next touch
- Branch ownership — reuses the existing WAR branch taxonomy; no new routing logic
- Reporting — branch reactivation health + dormancy reason aggregation
Why this matters to leadership
- Dormancy reasons stop being anecdotes — they become a strategic dataset that informs product, territory, and partnership decisions
- Branch reactivation performance becomes measurable, not opinion
- Cycle outcomes (re-engaged vs. closed-inactive) feed directly into the next planning cycle
- The same engine extends to dealer onboarding, lapsed-license recovery, and expansion outreach without rebuilding
The one upstream dependency
Larry's existing reactivation script. Stage names, offers, reason codes, and PMC's definition of "complete cycle" drive every other component. Once those surface, the architecture becomes a configured program in HubSpot.
How the components connect.
The diagram below shows the data and process flow. The Company record carries dormancy state and history; the Reactivation Deal pipeline carries the work; the Qualification Playbook turns each call into structured data; reports surface what's happening across branches.
flowchart TD
classDef signal fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f
classDef stage fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a
classDef record fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
classDef terminal fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d
classDef input fill:#f3e8ff,stroke:#9333ea,stroke-width:2px,color:#581c87
classDef report fill:#e0f2fe,stroke:#0891b2,stroke-width:2px,color:#164e63
A["Dealer (Company) Record"]:::record
B{"90+ days<br/>quiet?"}:::signal
Z["Active"]:::stage
C["Flag: Dormant"]:::signal
D["Reactivation Deal Created"]:::stage
E["1 — Identified"]:::stage
F["2 — Initial Contact"]:::stage
G["3 — Qualified"]:::stage
H["4 — Active Promotion"]:::stage
I["5 — Re-Engaged"]:::stage
J["6 — Closed: Stayed Inactive"]:::terminal
L["Larry's existing<br/>reactivation script"]:::input
P["Qualification Playbook"]:::input
M["Reactivation Tab<br/>on Company Record"]:::record
N["Branch Reactivation<br/>Health Report"]:::report
O["Dormancy Reason<br/>Aggregation Report"]:::report
A -->|Activity recency calc| B
B -->|No| Z
B -->|Yes| C
C -->|Auto-create + assign to branch| D
D --> E
E --> F
F --> G
G --> H
H -->|Order placed or<br/>meaningful next step| I
H -->|Cycle ends| J
I -->|Resets dormancy clock| A
J -->|Reason logged| A
L -.->|Stage names, offers,<br/>reason codes| E
L -.-> H
F --> P
P -->|Writes to Deal +<br/>copies durable data to Company| A
M -->|Live view of| D
M -->|History from| A
D --> N
P --> O Color key — purple: upstream input · amber: dormancy signal · blue: pipeline stage · green: dealer record / single-pane view · red: terminal (closed inactive) · cyan: report.
The full breakdown — six components, dependencies, and what leadership decides next.
Outcome
Pioneer Music can systematically re-engage dormant dealers (90+ days without meaningful activity), running a structured engagement cycle with visible progression — replacing list-chasing with a managed program every branch operates the same way.
Every dormant dealer has a deliberate next step. Every reason a dealer goes quiet becomes data the company can act on.
Target Architecture
Six components. They are interdependent — the program needs all of them to function.
Dormancy Signal (Company record)
A calculated property on the Dealer (Company) record that scores activity recency:
- Latest order date
- Latest WAR mention
- Latest meaningful contact engagement (meeting, replied email, opened call)
When > 90 days quiet, the dealer flips to Dormant. A scheduled signal opens a Reactivation Deal automatically and assigns it to the right branch owner.
Reactivation Deal Pipeline
A dedicated Deal pipeline — one Deal per dormant dealer per cycle. The pipeline carries the work; the Company record carries the history.
Stage architecture (final names from Larry's existing script):
- Identified → automated entry
- Initial Contact → branch manager call, playbook-driven
- Qualified → reason-for-dormancy captured + receptivity to offers known
- Active Promotion → specific offer or campaign deployed
- Re-Engaged → dealer placed an order or scheduled a meaningful next step
- Closed — Stayed Inactive → cycle ended without re-engagement; reason captured
Each stage transition has an explicit exit criterion. Branch managers cannot skip Qualified.
Qualification Playbook
Attached to the Initial Contact stage. Captures three things:
- Why the dealer went quiet (reason codes — fixed list)
- What their current state looks like (active products, capacity, market shifts)
- Which of Pioneer's offers/lines they're receptive to right now
Playbook output writes to the Deal and copies the durable bits to the Company record so the next cycle inherits the context. This is what turns reactivation from a phone call into a dataset.
Reactivation Tab on Company Record (renamed from Trends)
Single-pane dealer view:
- Current state — Active / Dormant / In-Cycle / Re-Engaged
- Open Reactivation Deal + current stage
- Last three cycle outcomes (history)
- Next scheduled touch
- Top reason codes from prior cycles
This is what a branch manager opens before a call. It is also what leadership reviews when asking "where does this dealer stand?"
Branch Ownership
Reactivation Deal owner is set automatically from the dealer's branch using the same submitter_team taxonomy already powering the WAR workflow. No new ownership logic — one source of truth for who owns what.
Reporting
Two cuts, refreshed continuously:
- Branch reactivation health — open cycles, time-in-stage, re-engagement rate, closed-inactive rate, by branch
- Reason aggregation — what is causing dormancy across the dealer base (this is the strategic dataset — informs product, territory, partner decisions)
Architectural Dependencies
Larry's script (stages + offers)
│
▼
Stage definitions ─────► Pipeline created
│ │
▼ ▼
Playbook content Branch routing
│ │
▼ ▼
Reactivation Tab on Company record
│
▼
Reporting Larry's existing reactivation script — stage names, offers, reason codes, what "complete cycle" means at PMC — is the upstream dependency for everything else.
What This Enables (for Leadership)
- Every dormant dealer has a documented next step visible to branch managers and leadership simultaneously
- Dormancy reasons become a dataset — not anecdotes from a Tuesday call
- Branch manager reactivation performance becomes measurable — not just opinion
- Cycle outcomes inform strategy — which lines are losing dealers, which offers re-engage them, which territories need attention
- The same engine extends — onboarding new dealers, lapsed-license recovery, expansion outreach all run on the same pipeline pattern
What Larry Provides
To move from architecture to a live program, Larry's existing reactivation script needs to surface:
- Stage names — from his current verbal/PDF playbook
- Offers and talking points — what gets deployed in Active Promotion
- Reason codes — fixed list of why dealers go quiet (used by every branch)
- Cycle definition — what counts as a complete cycle, when does the clock reset
Once those land, the architecture above becomes a configured program in HubSpot.
Open Questions for Leadership
- What is the right re-engagement metric — single qualifying order, sustained order pattern, scheduled training, signed agreement?
- Does "Re-Engaged" reset the 90-day dormancy clock, or does the dealer need to maintain activity for a window?
- Who reviews branch-level reactivation reports — Larry, branch managers, or above?
- Do dealers in Active Promotion get marketing-side support (email sequences, training invitations), or is this purely branch-driven?
Why This Approach Beats List-Chasing
Listing dormant dealers and asking branch managers to "work the list" produces inconsistent effort, no learning, and no visibility. The architecture above keeps the same human work — branch managers calling dormant dealers — but wraps it in structure: every call captures the same data, every dealer moves through the same stages, every cycle ends with a documented outcome.
The program scales because the data scales. Pioneer Music learns something about its dealer base every time a reactivation cycle runs.