/lynqu-lead-capture

name: lynqu-lead-capture
description: Capture leads into Lynqu from scanned badges, business cards, event lists or a pasted list. Deduped against existing contacts, tagged and routed. Requires the Lynqu MCP server connected.

Lynqu Lead Capture

You get people **into** the pipeline fast and clean. The moment after "nice to meet you". A stack of scanned badges is worth nothing on day one and less than nothing on day ten, when the context has evaporated and half of them are already in the CRM under a different spelling.

The two things that make this skill worth running instead of pasting into a spreadsheet: **dedupe before create**, and **every lead lands somewhere with a next step**. A capture run that produces 200 leads and zero tasks has moved the problem, not solved it.

Invocation

/lynqu capture <pasted list | csv | "the badges from SaaStr" | contact details>

> Lynqu's mobile apps do the AI badge/card **scanning** (OCR + vision), including > offline queueing and bulk mode. This skill takes the resulting contacts and > turns them into well-formed leads. If the user has photos, point them at the > app to scan, then bring the results here.

Step 1: Normalize the input

Parse into structured fields: first name, last name, company, role, email, phone, plus the free-text "where we met" detail.

• **Never guess.** A malformed row gets flagged, not repaired by invention. Ask

about the ambiguous ones in a single batch at the end, not one at a time

• Watch for the classic scan artefacts: OCR swapping `0`/`O`, a job title parsed

into the company field, two people on one card, a personal Gmail where a corporate address belongs

• Normalize company names *for matching* (strip Ltd/Inc/GmbH, casing) but store

what they actually gave you

• Keep the **capture context**: event, booth, date, who scanned it. This is the

single most valuable field on an event lead and the first one people drop

Report the parse before writing: *"48 rows → 44 parsed cleanly, 3 missing email, 1 looks like two people on one card."*

Step 2: Dedupe (non-negotiable)

For every person, before creating anything:

• **`search-contacts`**: the org address book, matched on email **and** name +

company. Email is definitive; name matching needs a human eye

• **`list-leads`** filtered by company: the same person may be in the pipeline

under a personal address

• **`list-lead-duplicates`**: Lynqu's own duplicate detection, if these people

may already have been captured by a colleague at the same event

Then branch per person:

| Situation | Do this | |-----------|---------| | Exact email match on an open lead | Don't create. `add-lead-note` with the new context. "met again at SaaStr, now evaluating" is a stronger signal than a new record | | Match on a **closed/won** lead | Flag it. This is an expansion or a re-engagement, and it belongs to whoever owns the account | | Contact exists, no lead | Promote: create the lead, linked to the existing contact | | Fuzzy match only | **Ask.** Show both records side by side. Never auto-merge on a name | | No match | Create |

Show near-matches as a group and let the user decide in one pass. Silently merging is how two real people called J. Smith at the same company become one corrupted record.

Step 3: Choose the destination

• **`list-lead-pipelines`**: which board. Event leads usually belong on their own

board, not mixed into outbound

• **`get-pipeline-stages`**: the entry stage on *that* board. Stages are

per-pipeline; the stage name you remember may live somewhere else

• Confirm the destination **once, for the batch**, before creating anything in bulk

Step 4: Create

Per person: **`create-lead`** with the normalized fields, a real `source` ("SaaStr 2026 booth"), and the chosen stage. Then **`add-lead-note`** with the capture context: what was said, what they asked for, how interested they seemed. That note is what makes the follow-up sound like a human remembers them.

The server is a backstop for Step 2, not a replacement: `create-lead` finds an open lead with the same email or phone and updates it instead of creating a second one. When the answer says `recaptured: true`, report that person under **Matched**, not **Created**. A refusal saying the lead already exists means the match is a lead the caller cannot see, and by design the server says nothing more about it. Hold that row back as "someone here already has this person" rather than retrying with a different spelling.

Assignment, if relevant: `list-team-members` then `assign-lead` (which takes the **user id**, not the `organization_user_id`. The same call returns both).

Step 5: Tag, attribute, and set the next step

• **`attach-leads-to-campaign`**: attribution is only possible at capture time.

Nobody backfills it later, and without it the event's ROI is unanswerable. Scans made at an event without the event picked get `attach-leads-to-event` too (≤ 100 per call); say first that it runs the event's follow-up sequence

• **`bulk-update-leads`** (≤ 100 per call) for tags and temperature across the

cohort. Chunk larger sets and report progress per chunk

• **`add-lead-contact-point`**: a dated first action for anything warm or hot.

The single strongest predictor of whether an event lead converts is whether it was touched within 48 hours

• **`start-enrichment`** on the thin rows if the org has credits

(`get-enrichment-quota` first). Show what it proposes and only **`confirm-enrichment`** with the user's yes: it fills empty fields, and that's their call

Output format

# Capture · {source}

Parsed {n} · created {n} · matched to existing {n} · needs a decision {n}

## Created
| Name | Company | Role | Stage | Temperature | Task |

## Matched, not duplicated
| Name | Existing lead | Owner | Action taken |

## Needs your call
| Input | Possible match | Why unclear |

## Written to Lynqu
- {n} leads in {pipeline} at {stage} · attached to {campaign} · tagged