Specification & Product Requirements
An automated system that keeps a standing, always-available shelf of warm referral targets for every member — researched continuously, ranked by connection strength, and surfaced wherever a Group Leader needs it.
The one-paragraph version, and the numbers that define the operating model.
Our members are our best source of new members — but knowing which member to ask about which prospect is slow, manual research today. This pipeline does that research continuously and keeps the answer on the shelf: for every member, a short, ranked list of prospects they're genuinely connected to (a shared employer or board seat, a LinkedIn connection, a shared conference chair role, or another executive network), ready whenever it's useful. When a Group Leader is about to talk to a member, they open that member's list, pick the single strongest target, and make that one ask. Nothing is ever sent to a member automatically — the list is a tool for the Group Leader, and the system is built around member fatigue so we never over-ask. It also gets smarter every month by learning from which referrals were accepted and which converted.
| Metric | What it tells us |
|---|---|
| Coverage — % of members with ≥5 ready targets | The north star: are we actually achieving year-round coverage? |
| Inventory depth — avg ready targets / member | How deep the shelf is across the membership |
| Inventory freshness — age of targets | Whether the shelf is current, not stale |
| Member acceptance rate | Whether we're surfacing the right member–prospect pairs (relationship strength signal) |
| Prospect → member conversion | The bottom line — referrals that become members |
| Fatigue adherence | Zero members over-asked; the program protects our relationships |
The whole system on one page. We kept your sketch's convention: solid = live today, dashed = still to build. The teal band is the human + learning loop. Note the data-acquisition sources fanning in on the left — that's where coverage depth comes from.
A continuous process pulls valid prospects from Snowflake and removes anyone we shouldn't touch. It then enriches each remaining prospect with the member connections we can find — today via Equilar (shared employers and board seats), and over time via Clay (LinkedIn / social connections) and two research agents (professional chair positions at conferences and governing bodies, and membership in other executive networks like the WSJ groups). It builds a master list of prospect ↔ member ties, then runs three steps: associate each prospect with every member it's genuinely connected to (no cap); filter out members who can't take the referral (an open referral, recently asked, a new member, or a "down-referral" up the seniority ladder); and, only when a prospect still maps to more than one eligible member, tie-break to the best one — by strongest connection, same World 50 group, and seniority. The result is written into Salesforce and surfaced in an always-available list view on each member and prospect. A Group Leader opens that list whenever it's useful — typically before a member call — picks the best target, and makes the ask. What happens next is recorded and, once a month, used to make the matching better.
Follow one prospect — Marcus Liu — end to end: how he’s picked, what the data sources find, how he gets assigned to one member (Dana) over another (Paul), lands on her shelf, gets worked by a Group Leader, and how the outcome makes next month smarter. Press play, or step through.
Illustrative walk-through with example names. The fatigue, filter, and feedback behaviors shown are exactly as specified above.
A common misread is that prospects and members narrow down the same funnel — implying we only have a handful of connected prospects. They’re actually two independent filters. We screen prospects (≈60,000) by one set of rules to decide who we may pursue, and — separately — we manage members (≈3,500) by availability and fatigue. The two tracks only meet at the matching step. Here they are on their own.
The two tracks meet at matching: every eligible prospect is tied to a member only by a real, evidenced connection (Equilar, Clay, chair roles, executive networks), and each prospect serves at most one member.
The open questions from the original sketch, now answered. These are the load-bearing choices the rest of the spec depends on.
| Question | Decision | Why |
|---|---|---|
| What's the program's actual goal? | Year-round coverage — keep ~5 ready targets stocked per member | Group Leaders should always have research waiting, member by member, not have to request it |
| What Salesforce status do we write referrals with? | "Research Proposed" — staged research, surfaced for the Group Leader | The list is a tool the Group Leader acts on; a human chooses and makes every ask |
| Can the same prospect go to multiple members? | No — each prospect is assigned to one best member | Avoids two members being asked about the same person; keeps the coverage math clean |
| Does Group Leader review capacity throttle the pipeline? | No — we keep the list stocked regardless; GLs pull on their own schedule | Standing inventory is the whole point; capacity is why it's valuable, not a gate on generation |
| When does a member's fatigue cooldown start? | When the member is actually asked, not when a target is shelved | A target sitting on the shelf, unused, must never freeze a member out |
| How automated is the improvement loop in v1? | Instrument fully; data science recalibrates by hand, monthly | Prove the outcome data is clean before automating any model |
| The "Prospect Deep Research Gem"? | Phase 3 — on-demand deep dive on a high-value prospect before the ask | Gives it a clear job instead of sitting unplaced |
The system maintains standing inventory. The job of every run isn't to produce a batch — it's to keep each member backed by a healthy roster of ready targets (an aim of ~5+, no fixed cap).
| Trigger | What it does | Why |
|---|---|---|
| Weekly replenishment (backbone) | Top up any member below ~5 ready targets; refresh stale or invalidated targets; re-run member/prospect filters across the whole pool so expiring cooldowns re-open eligibility | Keeps the shelf full and current with steady, predictable load |
| New-member event | Build that member's initial shelf (~5) against the full prospect pool | A new member should have coverage from day one, not after the next weekly tick |
| Bulk prospect import | Run new prospects through enrichment; associate them to members who need more targets | New supply should deepen coverage promptly |
| On-demand | Group Leader refreshes a specific member's list (e.g., right before a call) | Operational flexibility at the moment of use |
| Monthly full rebuild | Recompute everything; absorb wholesale list changes | Doubles as the data-science recalibration checkpoint (see Feedback loop) |
The part not yet on the original sketch. v1 is "instrument everything, recalibrate by hand monthly" — earn trust in the data before automating.
| Event | Captured fields | Source |
|---|---|---|
| Shelved | prospect, member, source(s), connection strength, explanation, run ID, rank in member's list | Pipeline |
| Group Leader action | used / dismissed, dismissal reason (structured), free-form comment, reviewer, timestamp | Salesforce |
| Member response | accepted / declined to refer, decline reason, timestamp | Salesforce |
| Outcome | prospect → member conversion (y/n), time-to-convert | Salesforce |
The original sketch's note — "need better Decline Reason + free-form comments" — is exactly the hook this loop runs on. Structured reasons are what let DS tell "wrong member" from "wrong timing" from "bad prospect," and tune accordingly.
Once a month (aligned to the full rebuild), data science reviews the captured outcomes and adjusts — by hand — the weights driving connection-strength scoring and assignment ranking. For example: learning that board-overlap targets convert better than LinkedIn-only connections, or that a given source's "strong" matches underperform and should rank lower on the shelf. No model retrains automatically in v1; humans hold the pen. Automation is a later phase, gated on the data proving itself.
Stage-by-stage logic, data contracts, and the Salesforce object model. Each stage is tagged LIVE (built today) or BUILD (new work).
Source: Snowflake list of valid prospects, where status ∈ {lead, suspect-medium, prospect}.
Prospect exclusion filters (all hard — removed, not flagged):
| Filter | Rule |
|---|---|
| Exclude Innovation Members | Drop prospects who are any IR person type |
| Exclude Program Participants | Drop "Next" program participants |
| Exclude Do Not Contact | Drop prospects with a DNC "Red" reason on their Salesforce account |
| Exclude Alumni | Drop World 50 alumni |
| Membership-status filter (merged) | Drop prospects found to be existing members, or with member status "Disqualified" / "Retired". Replaces the redundant "Exclude Existing Members." |
| Exclude Prospects With Open Referrals | Drop prospects with a pending referral request already in flight |
Note: "Exclude Weak Connections" is a deliberate non-exclusion — weak connections are kept and marked, never dropped (see Stage 4).
The depth of coverage comes from here. Four matchers run in parallel against the filtered prospect set, each emitting prospect ↔ member connection records with an explanation and a strength signal. These roll out in sequence (see Phasing) — Equilar is the only one live today.
| Matcher | Connection basis | Status |
|---|---|---|
| Equilar | Employment overlap and board overlap (incl. education boards) between prospect and member | LIVE |
| Clay | Social-media connections — specifically LinkedIn — between prospect and member (capability exists in Clay; not yet stood up) | Phase 2a |
| Chair-positions research (Claude agent) | Shared professional chair positions — conference and governing-body chairs and the like. Seeded by known list (Appendix A) + snapshot sheet (Appendix B), then agentic discovery beyond them | Phase 2b |
| Executive-network research (Claude agent) | Shared membership in other executive networks (e.g. the WSJ groups). Seeded by known list (Appendix C), then agentic discovery | Phase 2c |
Google Sheets — connection snapshot
List of executive networks to be supplied by the team (referenced in the sketch, contents TBD).
Converge all active matchers into a single master list of prospect↔member connections.
Fields: Prospect Name, Member Name, Source, Explanation.
Dedup rule (open — see Open items): when the same prospect↔member pair appears from multiple sources, collapse to one record, combining sources and taking the strongest connection signal. The "winning" explanation and source-precedence order needs to be defined as new sources come online.
// Connection record { prospectId: "...", memberId: "...", sources: ["equilar", "clay"], tieType: "board_service" | "linkedin" | "exec_network" | "employment" | "chair", tieRank: 1, // 1 = strongest; see connection hierarchy explanation: "Shared board seat: Acme Corp (2019–present)", basis: "board_overlap" }
Member-side eligibility rules — do we ask this member about this prospect right now? A soft rule puts the pairing on a temporary hold (no referral object now; eligible again once the condition clears); a hard rule blocks it outright. These are filters, not tie-break inputs (see Stage 5). The loop still learns from what we hold. This logic largely already exists in Salesforce.
| Filter | Rule | Mode |
|---|---|---|
| Referring Members with Open Referrals | Don't ask a member for another referral while one is still pending | soft · hold |
| New Members | Don't ask within 3 months of membership start | soft · hold |
| Recently Asked Members | No 2nd referral within 3 months of any previous referral | soft · hold |
| Previously Attempted Referrals | Don't ask the same member about a prospect we've previously asked them about | hard |
| Prospects With Open Referrals | Don't surface a prospect with a pending request | hard |
| Weak Connections | Do not exclude — keep, marked "weak" by the agentic pipeline | keep + mark |
This is the net-new heart of the pipeline. It runs in three distinct steps — and it's important not to conflate them (especially the filter and the tie-break):
We triangulate on three signals — to be finalized by Data Science and Sales:
| Signal | What it favors |
|---|---|
| 1 · Strongest connection | By tie type (hierarchy below) — a shared board seat beats a LinkedIn link, etc. |
| 2 · Same World 50 group | A peer-group match — e.g. a Security 50 prospect to a Security 50 member — even at different companies. |
| 3 · Seniority / direction | Never a down-referral; prefer peer or upward introductions (the member is a peer of, or senior to, the prospect). |
Signal 1 ranks the type of connection, strongest first — a starting point to finalize:
| Rank | Tie type | Source |
|---|---|---|
| 1 | Shared board / educational-department-chair service | Equilar |
| 2 | Proven LinkedIn (1st-degree) connection | Clay |
| 3 | Professional group / executive-network affiliation | Exec-network agent |
| 4 | Employment / work overlap | Equilar |
| 5 | Conference / committee chair co-service | Chair agent |
Members with few genuine connections will simply have fewer targets — surfaced as a coverage gap to fill as deeper sources (Phase 2) come online, not an error.
Write a referral object to Salesforce and surface it in an always-available list view on both the member and the prospect. The list view is the product from the Group Leader's perspective — it's what they open before a member call.
| Field | Value / notes |
|---|---|
Request status | "Research Proposed" (staged research, available on the shelf) |
Comments | Explanation of the connection (from Stage 3) |
Referral Type | Set per match |
Data Source | Source(s) the connection came from (taxonomy TBD) |
Cross Group | Flag — semantics to be confirmed (open item) |
Prospect Info / Member Info | Linked records |
Decline Reason (structured) + free-form | Phase 3 enhancement — feeds the feedback loop |
The Group Leader opens a member's list whenever it's useful — most often skimming ahead of a member call — and makes one ask: the single strongest available target (which is exactly why the list is ranked — a call yields one ask, not several). The pipeline never contacts a member. There is no review queue gating generation: the shelf is always stocked and waiting. Once an ask is made, the member's fatigue cooldown starts and the outcome is captured for the loop.
Get end-to-end functionality live by mid-July on the data source we already have, then deepen coverage by rolling in sources one at a time.
Wire the pieces that already exist — Snowflake source, Equilar matcher, master list, member filters — through the new glue we must build: the assignment step (associate → eligibility filter → tie-break), the Salesforce referral object (Research Proposed), and the always-available member/prospect list view. Weekly replenishment cadence. One data source (Equilar). Outcome: every member has a live, always-available list (Equilar-depth), and Group Leaders can use it before calls. The whole loop runs; we then make it deeper.
Add data-acquisition sources in sequence, each increasing depth toward the ~5/member goal. Introduces the connection hierarchy, cross-source dedup, and the new-member / on-demand triggers.
| Step | Adds | Coverage effect |
|---|---|---|
| 2a · Clay | LinkedIn / social connections | Biggest depth jump; most members gain targets |
| 2b · Chair-positions agent | Conference / governing-body chair positions (discovery beyond Appendix A/B) | Coverage for chair-connected members |
| 2c · Exec-network agent | Membership in executive networks, e.g. WSJ groups (beyond Appendix C) | Fills remaining network-based gaps |
Monthly data-science recalibration from captured outcomes, the structured decline-reason / free-form fields that feed it, and a home for the Prospect Deep Research Gem — an on-demand deep dive on a high-value prospect just before the ask.
| Risk | Mitigation |
|---|---|
| Over-asking members damages relationships | The pipeline never asks — a Group Leader does. Hard/soft cooldown rules + cooldown clock pinned to the actual ask mean a full shelf never translates into more asks than fatigue rules allow |
| Coverage gaps — members with few connections | Coverage is best-effort and visible as a metric; Phase 2 sources (Clay, the two agents) are sequenced specifically to fill these gaps |
| Stale shelf — old targets lingering | Weekly replenishment refreshes and ages out targets; freshness is tracked as a metric |
| Low-quality targets erode Group Leader trust | Every target carries an explanation to sanity-check; ranking surfaces the strongest first; weak matches kept but de-prioritized |
| Mid-July deadline slips | Phase 1 deliberately ships end-to-end on the one source already built (Equilar); new sources are additive and post-launch, so the deadline rides on glue work, not data integrations |
Decisions still needed before or during build. None block the Phase 1 mid-July target.
| Item | Needs | Owner |
|---|---|---|
| Tie-break signals | Finalize the three ranking signals (connection hierarchy, same World 50 group, seniority) and define the exact down-referral / "don't refer up" rule. Note: fatigue is an eligibility filter, not a ranking weight | Data Science + Sales |
| Coverage target tuning | Confirm ~5 as the per-member target; decide behavior when supply can't reach it | Sales |
| Cross-source dedup | Source-precedence order and which explanation "wins" when a pair appears multiple times (matters once Clay/agents land) | Eng + Data Science |
| Connection hierarchy | Finalize and order the tie-type hierarchy (board service, LinkedIn, exec network, employment, chair) used for ranking | Data Science + Sales |
Cross Group field semantics | Define what the flag means and how it's set | Salesforce + Sales |
Data Source taxonomy | Controlled vocabulary for the field | Salesforce |
| Appendix C contents | Supply the executive-network list (e.g. WSJ groups) referenced in the sketch | Sales |
| Structured decline reasons | Design the reason taxonomy (Phase 3 dependency) — the sketch flagged this as needed | Sales + Data Science |