---
name: overhear-leads
description: Set up or refine an Overhear lead profile, suggest social search phrases, and qualify lead results using customer fit, buying intent, and source evidence. Use for Overhear lead discovery and triage; ordinary brand mention monitoring does not need this workflow.
---

# Overhear leads

Lead finding is in beta; describe it to users as such, and expect a tracked phrase to surface a handful of genuine requests a month, not a daily feed.

Find people whose stated needs match the product. Keep customer fit, buying intent, and timing separate. A fit score is an assessment of suitability, never a percentage chance of purchase.

## Establish buyer context

Read the existing project and its profile before asking questions. With Overhear MCP, use `list_projects`; it returns `description`, `domain`, `lead_profile`, keywords and the minimum fit. Otherwise use the project's Leads page. Preserve user corrections over website suggestions.

Use these five profile fields:

- `ideal_customer`: roles, company types and relevant size or geography constraints.
- `problems`: the problems the product solves, in the customer's language.
- `alternatives`: known competitors and current workarounds.
- `buying_signals`: requests, complaints or switching language that indicate need.
- `exclusions`: explicit poor fits and unsupported requirements.

Infer a draft from the product website when useful. Leave unsupported constraints empty; do not invent company sizes, budget, geography or integrations. Ask only for missing facts that would materially change qualification. Keep each field within 1,000 characters.

The Leads page offers website prefill, profile editing, and **Save & suggest searches**. Website suggestions are reviewed before saving. To save through MCP, call `set_lead_profile` with `project_id` and all five fields. This replaces the full profile: read `list_projects` first and preserve untouched values when editing. An empty string clears a field; omitted fields are rejected. The tool returns the saved, trimmed profile and does not start searches. Profile changes affect future scoring; existing results retain their prior assessment.

## Choose searches

Suggest a small set of specific phrases buyers would actually write: a problem, a request for a tool, or a named competitor alternative. Avoid seller language, ambiguous single words and invented competitors. Use the saved profile for audience and exclusions.

Example: for demo-recording software, `product demo tool` or `Navattic alternative` may be useful; `growth` is too broad, and `Arcade alternative` finds games. Check ambiguous product names against the actual post.

Suggestions do not start monitoring. `add_keyword` with `kind: "lead"` starts recurring scans every 6 hours (fixed; YouTube, Hacker News and the web daily) and incurs a separate scan for each phrase across all sources, unless `sources` limits them. Check existing keywords for duplicates. Add keywords only when the user has requested tracking, within their stated cost constraints. A request for recommendations alone authorizes suggestions, not recurring spend.

Overhear currently searches X, Reddit, LinkedIn, YouTube, Hacker News and the web, unless a source is turned off for a keyword under Settings. It does not automatically expand into comments, enrich contacts, or monitor hiring/funding/technology changes. Do not imply those integrations exist. If the user requests additional research through Treg, inspect its current catalog and price before spending; do not hard-code remembered endpoint IDs.

## Qualify results

Use `list_mentions` with `leads: true` for the selected project. Results carry `fit`, `intent`, `fit_reason`, `evidence`, `posted_at`, and `url`.

1. Check customer fit first. Reject explicit exclusions, sellers pitching their own products, job ads and irrelevant needs. Unknown role or company information remains unknown.
2. Read intent independently: `active` means explicitly seeking a solution; `exploring` means first-person pain without a request; `none` means no buying signal; `unknown` means insufficient evidence. A strong fit can still have no buying intent.
3. Check the original evidence and source link. A quote must occur in the post. Do not infer intent from a like or generic praise. If intent is null, the result has the previous combined score; do not relabel it as a separate fit assessment.
4. Use the post date for timing, not the discovery date. Missing dates stay unknown. Do not describe an old request as someone shopping now.
5. When researching multiple posts, deduplicate identical sources. Combine signals only when evidence establishes the same person or company; repeated copies of one post are not independent corroboration.

Present a short ranked list with person, fit, intent, quoted evidence, date and source link. State material unknowns. Do not turn weak signals into confident sales claims to fill a quota.

`draft_reply` produces editable text. Do not send or publish it unless explicitly asked. `mark_replied` records an actual posted reply; drafting alone does not justify it. If asked to monitor new results over time, retain source IDs or URLs and report only new evidence; do not create an extra schedule when existing keyword scans already cover the request.

## Reference

This workflow draws on the qualification, recency and evidence principles in [Treg's lead-signals guide](https://github.com/superdesigndev/treg/blob/main/skills/lead-signals/SKILL.md). Treg's broader [signal catalog](https://treg.to/leads-signals) describes possible research sources, not features already implemented in Overhear.