/lynqu-sales-playbook

name: lynqu-sales-playbook
description: Turn a written sales playbook into a live Lynqu pipeline — contacts, timed tasks, follow-up templates, the playbook attached to each lead, and stage rules that deliver the prep at the right moment.

Lynqu Sales Playbook

A playbook that lives in a folder is a document. A playbook that lives in Lynqu is a process: the contacts are on leads, the touches are dated tasks, the meeting prep appears when the deal reaches the stage it belongs to, and the whole thing is attached to the lead so the next rep inherits it.

You do that conversion. You read a playbook doc set — decision makers, an outreach sequence, meeting prep, the send order — and you provision it.

The measure of a good run is that a rep who has never read the playbook still executes it, because the next action is already on their board with a date on it.

Invocation

/lynqu playbook <folder | file | pasted plan>

Step 1: Read the playbook before touching the account

Ask for the documents, or take what's pasted. A typical set:

| Document | What you extract | | --- | --- | | Decision makers | The people: name, title, company, role in the deal (champion / sponsor / economic buyer / blocker) | | Outreach sequence | The touches: channel, day offset, purpose | | Meeting prep | The briefing that belongs on a booked meeting | | Send playbook / send order | Per-person copy and the order to work them |

Read all of them first. A sequence means nothing without the tracks it applies to, and the send order usually overrides the generic sequence.

**Then read the account.** `get-org-summary` for the shape, `list-lead-pipelines` and `get-pipeline-stages` for the stages you will be attaching rules to, and `search-contacts` for every person the playbook names. Provisioning a playbook into a pipeline you have not looked at produces a second, parallel process nobody uses.

Step 2: Confirm the plan before you write anything

Show the user, in one block:

• how many leads you will create, and in which pipeline
• how many contacts already exist (matched) versus will be created
• the tasks per lead, with their day offsets
• which stages get which rules
• what will be attached to each lead

Wait for a yes. This step writes to a shared workspace that other people are working in; a playbook provisioned into the wrong pipeline is tedious to undo.

Step 3: The people

For each named person:

• **`search-contacts`** first — match on email, then name + company. A playbook

usually names people the org has already met.

• **`create-contact`** only for genuine misses. Never create a second contact

for someone who is already in the roster.

• **`create-lead`** for the ones you are actually going to work, in the pipeline

the user confirmed.

• **`manage-lead-participant`** for the rest of the buying committee. A

corporate track with a champion, a technical sponsor and an economic buyer is ONE deal with three participants, not three leads. Promote the champion to primary — that is what points the lead at the right contact record.

Multiple people at one company who are each their own opportunity (separate teams, separate budgets) are separate leads. People who must all say yes to the same purchase are participants on one lead. Ask if it is genuinely ambiguous.

Step 4: The touches

Each touch in the sequence becomes a task via **`add-lead-contact-point`**:

• `title` — what the rep actually does ("Send the 90-day pilot one-pager")
• `kind` — `call`, `demo`, `proposal`, `follow_up` or `other`
• `due_at` — the sequence's day offset, counted from today
• `description` — the angle, and the copy if the playbook supplies it
• leave `assigned_to` unset unless the playbook names an owner; an unassigned

task already routes to whoever owns the lead

Cap is 25 per lead. A six-touch sequence fits comfortably; a sequence that doesn't fit is a sign the playbook is describing two plays, not one.

For email touches that are genuinely templated across every lead, build the template once with **`create-followup-template`** and reference it from the stage rule in Step 6 rather than pasting the copy into 20 tasks.

Step 5: Attach the playbook itself

**`add-lead-document`** takes a file as base64 and accepts Markdown. Attach the send playbook — the per-person copy, the objection handling, the value props — to each lead it covers.

It renders in the browser: the lead's Engagement tab shows the Documents panel, and a `.md` file opens as formatted text, not a download. So the rep opens the lead and reads the play, in the place they were already looking.

Attach the section that applies to that person where the playbook is per-person. A rep opening Kyle's lead should find Kyle's angle, not a 45-page document they have to search.

Step 6: Make the pipeline deliver the prep

This is the part that turns a provisioned playbook into a live one. Stage rules need the **Workflow Automation add-on**; check with `list-automation-rules` first — if it returns `ADDON_REQUIRED`, everything above still worked, and you say so plainly rather than failing the whole run.

**`create-automation-rule`** with `trigger_type: stage_changed` and the `stage_to_id` you want to hang content on:

Stage "Discovery booked"
  → add_note           the meeting-prep briefing for that track
  → add_contact_point  "Send agenda 24h before", due_in_days 1

Stage "Proposal sent"
  → add_contact_point  "Follow up on proposal", kind follow_up, due_in_days 3
  → send_template      the proposal follow-up email

Stage "Negotiation"
  → add_note           the objection-handling section
  → notify             target managers

Four things about these rules that decide whether the result is usable:

1. **They are per-stage, not per-lead.** One rule serves every lead that ever reaches that stage, including ones created long after this run. That is the whole point — you are configuring the pipeline, not decorating 20 records. 2. **`due