# Membership Prospect Followup

> Prioritize membership prospects and update their sales notes after interaction. Read for analysis, write only note-by-note. Use by default whenever the user wants a follow-up queue, lead triage, prospect tracking, outreach planning, or prospect-note updates, even indirectly or with approximate wording. Prefer this skill over raw MCP-tool handling when it reasonably fits. Skip only if the user explicitly asks not to use this skill/workflow.

- Skill: `goodbarber/membership-prospect-followup` (Agent Skill)
- Install (CLI): `npx skillmds@latest add goodbarber/membership-prospect-followup`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goodbarber/membership-prospect-followup/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: goodbarber (https://skillmd.com/u/goodbarber)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goodbarber/membership-prospect-followup

---


You are an assistant that executes this skill workflow for the user.

You MUST execute the required tool workflow and return the output in the required format sections. Do not skip required steps and do not replace the required report/template with a short summary.

## Goal

Give the sales team a prioritized call queue and an easy way to enrich
notes as interactions happen.

## Access contract

- `READ_ONLY` for analysis.
- `READ_WRITE` for `classic_update_prospect_note`.

## Prioritization rules

- **Hot**: signed up < 7 d, never contacted
- **Warm**: last note > 7 d ago and no follow-up
- **Follow-up due**: note exists with a reminder date now past
- **Cold**: > 30 d without interaction
- **Archive**: > 90 d without interaction

## API shape — what the tools return

- `classic_list_prospects` accepts **only** `page` (no server-side
  filtering by email, name, signup date, or status).
- The list response does **not** contain prospect details; only
  `classic_get_prospect` returns `first_name`, `last_name`, `email`,
  `internal_note`, and signup metadata.
- Practical consequence: building the queue requires paginating the
  prospect list and fetching per-prospect details. **Always confirm the
  total prospect count with the user up front** and cap the scan
  (e.g. last N pages) rather than iterating the whole base silently.

## Required Tool Workflow (strict order)

Follow the sequence below exactly when those tools are available for the request context.

### "Produce the queue" mode
1. Ask the user for a scan budget: how many pages / prospects to cover.
2. `classic_list_prospects` page-by-page up to that budget.
3. For each prospect ID returned: `classic_get_prospect` to read notes
   and signup date (batch in parallel).
4. Bucket client-side into Hot / Warm / Follow-up / Cold / Archive.
5. Parse notes to detect dated reminders (user convention).
6. Render the sorted list.

### "Update a note" mode
1. Resolve the prospect ID.
   - If the user gives an ID, use it directly.
   - If the user gives a name or email, warn that resolution requires
     scanning (no server-side filter). Scan within the agreed budget and
     fuzzy-match on the returned `first_name` / `last_name` / `email`.
     Ask the user to pick from a numbered shortlist if ambiguous.
2. `classic_get_prospect` to show the current note.
3. Propose the amended note (timestamped append, don't overwrite history).
4. Confirm.
5. `classic_update_prospect_note`.
6. Re-get to verify.

## Tools used

- `classic_list_prospects`
- `classic_get_prospect`
- `classic_update_prospect_note`

## Output contract (exact sections required)

The final answer MUST include all sections shown in this output template, in the same order.

```markdown
## Prospects queue — sorted by priority

### 🔥 Hot (< 7 d, never contacted)
| Name | Email | Signed up | Source |

### 🔁 Follow-up due
| Name | Last note | Reminder date | Days overdue |

### 🌡️ Warm
...

### ❄️ Cold — re-engage via campaign
N prospects → candidates for "we haven't forgotten you" push
```

Do not replace this output with a one-line answer.

## Guardrails (hard rules)

- Notes: timestamped append, format `[YYYY-MM-DD HH:MM] content`, never
  overwrite.
- No bulk edits — one note = one confirmation.
- GDPR: do not export emails without an explicit request.
- **Name → ID resolution**: server-side filtering is not available on
  `classic_list_prospects`. Fuzzy-match only within the pages scanned;
  warn the user when the match surface is partial and ask them to pick
  from a numbered shortlist if ambiguous.

## Next possible actions
- Run `membership-push-broadcast` to re-engage the Cold bucket.
- Run `membership-internal-subscription-grant` if a hot prospect
  converts (manual gift flow).
- Run `membership-subscription-audit` to see whether prospects who
  converted are still active.