| name | sales-outbound |
| description | Turn a pasted outreach conversation into a tracked lead AND a ready-to-send reply. Give it a copied DM / chat thread (Threads, IG, LINE, FB Messenger, WhatsApp, email — wherever a prospect showed interest), optionally with the person's profile link, and it does two things in one pass: (1) collects who they are — parsing the thread and enriching from any social/profile URL — and writes the client context into the Zynkr platform CRM (find-or-create company + contact, a new deal, a verbatim conversation note, and a follow-up task for the agreed next step); (2) drafts the outbound reply as a Gmail DRAFT in Peter's inbox (never sends), in the same language as the conversation and in Peter's voice, reflecting whatever was agreed (a demo, a call, sending info). Trigger on /sales-outbound or when Peter pastes a DM / outreach exchange and says "draft a reply", "draft an outbound mail", "回這個", "幫我擬回覆", "把這個 lead 建進 CRM 並擬信", "log this lead and draft the email", "turn this DM into a draft", or otherwise hands over a back-and-forth where someone agreed to a demo / call / next step and wants both the CRM record and the reply prepared. Distinct from consult-intake (a weekly BATCH sweep of inbound website consult EMAILS) and consult-project-specialist (documents ONE sales/consulting MEETING transcript into a project + Drive folder + deal): this one takes ONE short outreach/DM conversation and produces a lead record + a drafted reply, no Drive folder, no meeting parsing. |
| category | sales-consultant |
| project | sales-outbound |
| platform | claude |
| status | Done |
| author | Peter Tu |
| sheetId | 2.09 |
| input | A pasted outreach / DM conversation (any channel), optionally the counterparty's profile URL and the email address they gave. |
| process | Parse the thread → enrich from any profile link → write the client context into the CRM (find-or-create company + contact, new deal, conversation note, follow-up task) → draft the outbound reply as a Gmail draft → report. |
| output | A CRM lead (company + contact + deal + note + task) in the Zynkr platform, and a ready-to-send Gmail draft of the reply in Peter's inbox. |
| synergy | [] |
Sales Outbound
npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill sales-outbound
Peter does a lot of outbound and inbound on social (Threads, IG, LINE, FB, email).
When a prospect replies and the thread reaches "yes, let's do a demo / call / send
me info" with an email address on the table, Peter wants two things to happen at
once: the person should become a tracked lead in the CRM, and a reply should
be sitting in his inbox as a draft, ready to tweak and send.
This skill does both from a single paste. He copies the conversation in (and, if
handy, drops the person's profile link), and it:
- Collects the client context — parses the thread for name, the email they
gave, what they agreed to, and who initiated; enriches role / company /
industry from any profile URL.
- Writes it into the CRM — find-or-create company + contact, a new deal, a
verbatim conversation note, and a follow-up task for the agreed next step.
- Drafts the reply — a Gmail draft (never sent), in the conversation's
language and Peter's voice, that moves the agreed next step forward.
It runs autonomously: parse → enrich → write CRM → draft email → report. No
mid-run confirmation — the email lands as a draft (safe, Peter reviews before
sending) and the CRM write is one atomic statement.
How this differs from its neighbours
- consult-intake — a weekly BATCH job that sweeps inbound
website@zynkr.ai
consult emails and de-dupes them into deals. Use it for the inbox sweep, not a
single pasted DM.
- consult-project-specialist — takes ONE sales/consulting meeting transcript
and documents it as a project: Weekly Update + numbered Drive folder + kickoff
Doc + deal. Heavy. Use it after a real meeting.
- sales-outbound (this one) — takes ONE short outreach/DM conversation
(pre-meeting) and produces a lead record + a drafted reply. No Drive folder, no
meeting parsing, no Weekly Update.
Fixed facts (don't re-derive these)
- Supabase project_id:
uomieoqlkazknjgmfdda (the shared Zynkr project; CRM tables are crm_*)
- Google account for all Gmail tools:
peter_tu@zynkr.ai
- CRM record URLs for the report:
https://platform.zynkr.ai/deals/{id} · .../contacts/{id} · .../companies/{id} — {id} is the uuid the SQL returns.
- Owner (
Peter Tu), the caller's workspace_id, and the default pipeline (銷售流程) are resolved live inside the SQL — never hardcode their ids.
- Do NOT log the drafted email as a CRM activity. Peter's Gmail is already synced into the CRM (
app/lib/integrations/sync.ts, 15-min cron): the moment he sends the draft, it auto-appears on the contact's 電子郵件 timeline as an outbound email. Logging it here would duplicate that row.
Workflow
1 · Acquire + parse the conversation
The conversation arrives as pasted text (a copied DM / chat / email thread). Read
it directly. Also capture anything Peter hands alongside it:
- A profile URL (Threads / IG / LinkedIn / FB / a website) → for enrichment in step 2.
- A CRM record URL (
…/contacts/{id} or …/companies/{id}) → pass that uuid so
the deal links to the existing record instead of creating a duplicate.
Pull these fields from the thread (infer logically, never fabricate — leave blank if absent):
- Name / handle of the counterparty.
- Email they gave (the reply will go here; it's also the find-or-create key).
- What they agreed to — a demo, a call, "send me info", joining a beta, buying.
- The agreed next step — becomes the follow-up task and the email's ask.
- Who initiated — Peter reached out (outbound) vs they came to him (inbound) →
lead_source.
- Language of the conversation (zh-TW vs EN) → the draft matches it.
2 · Enrich from the profile link
If a profile URL (or a resolvable handle) is present, fetch it with WebFetch and pull:
display name, bio/role, company, industry, follower count, any public contact email
or links. Fold this into the contact's title + the company record + the note. If no
link is given, skip — don't guess a bio.
3 · Build the client card
Assemble a compact summary and keep it for the report:
客戶名片
- 姓名 / 帳號 · …
- Email · …
- 身分 / 公司 · … ← from enrichment
- 來源 · Threads DM(Peter 主動 / 對方來訊)
- 對話結論 · 同意看 30 分鐘 demo
- 下一步 · 約時間、寄會議連結
- 語言 · zh-TW
4 · Write the CRM lead
Read references/lead-insert.sql, fill the placeholders, run it via
mcp__supabase__execute_sql(project_id="uomieoqlkazknjgmfdda", query=...). One
statement:
- resolves owner + workspace + default pipeline live,
- find-or-creates the company (case-insensitive by name; skipped if no company),
- find-or-creates the contact (case-insensitive by email; reused if it already exists),
- inserts a new deal,
- logs a
note activity (the verbatim conversation + who they are) and a task
activity (the agreed next step, due in {{TASK_DUE_DAYS}} days, assigned to Peter).
It returns company_id, contact_id, deal_id, note_id, task_id, plus
contact_existed / company_existed booleans so you can say so in the report.
Escaping: every {{…}} placeholder is replaced with a SQL literal — quote
text and double any single quote (O'Brien → 'O''Brien'), or write NULL. For an
absent company, set {{COMPANY_NAME}} to an empty string '' (the SQL then creates
no company and the deal's company_id is NULL).
See Inference defaults below for the enum fields.
5 · Draft the reply (Gmail draft — never send)
Draft the outbound reply with
mcp__google-workspace__draft_gmail_message(user_google_email="peter_tu@zynkr.ai", to="<their email>", subject="…", body="…").
Rules for the draft:
- Match the conversation's language (zh-TW reply to a zh-TW thread, EN to EN).
- Peter's voice — warm, concise, peer-to-peer; mirror the tone of the DM (if it
was casual and friendly, so is the email). No corporate boilerplate.
- Move the agreed next step forward — if they agreed to a demo, propose scheduling
it and ask for their availability; if "send info", attach/point to it; etc.
- Concrete subject line.
- zh-TW house style: headings/taglines take no 句號 (。); if you list items use
emoji numbers 1️⃣ 2️⃣ 3️⃣ (never circled ①②③);
· for series separators.
- Create a draft, never send. Peter reviews and sends himself.
6 · Report
Show the client card, then a compact artifact table:
已建立 lead 並擬好回信草稿:超哥(行銷超哥 Chao.Marketing)
| 產出 | 連結 / 狀態 |
|------|------------|
| CRM Deal | <deal url> |
| 聯絡人 | <contact url>(新建 / 既有) |
| 公司 | <company url>(新建 / 既有) |
| 活動 | note · 1 task |
| Gmail 草稿 | 已放進收件匣,待你過目後寄出 |
If the contact already existed, say so (you attached a new deal to the existing
person rather than duplicating them).
Inference defaults (Peter overrides by just saying so)
Pick the closest enum from the conversation; use the fallback when there's no signal.
- stage (
new|contacted|qualified|proposal|won|lost) — they engaged and agreed
to a demo / call / clear next step → qualified; softer "sounds interesting,
maybe" → contacted; bare first reply → new.
- lead_source (
content|workshop|referral|outbound|other) — Peter messaged them
first → outbound; they came via a post/content → content; warm intro →
referral; unclear → other.
- contact lifecycle_stage (
subscriber|lead|mql|sql|opportunity|customer|…) —
demo/call agreed → sql; otherwise lead.
- priority (
low|medium|high) — default medium; eager / near-term → high.
- deal_type —
new_business (this is a fresh lead).
- value —
NULL unless a concrete figure was discussed (beta / early chats have none).
- close_date —
NULL unless a date was stated.
- task_due_days — default 3 (chase the demo/call within a few days).
Why it's built this way
- One paste → both outputs. The point is to kill the two-step (log the lead, then
go write the email). Peter pastes once; the lead is tracked and the reply is waiting.
- Email is a draft, not a send. Outbound to a real prospect is Peter's call —
the skill prepares, he approves. That's also why it needn't confirm before running.
- Find-or-create, always-new deal. A person can come back for a second deal, but
they shouldn't be duplicated as a contact — so contact/company are keyed
(email / name), while each run books a fresh deal (re-running = a deliberate redo).
- Don't log the email activity. The Gmail→CRM sync already captures it on send —
logging here would double the row. The skill writes the note (the DM thread,
which the sync can't see) and the task, and leaves the email to the sync.