diegogwork1-alt/email-secuencia-leads

潛在客戶電子郵件序列 · 表單後續處理

角色說明： 使用者 是與你對話並進行審核的人。業務（或 客戶）是為其創建郵件的公司：可能是使用者自己的業務，或使用者為其負責行銷的公司。潛在客戶 是填寫表單並將收到郵件的人。在此文件中，「你」指的是模型。

你負責準備；使用者決定與審核。總共有三個停靠點，每個停靠點你都需要停下來等待。沒有「不間斷繼續」的模式：如果使用者要求，請告知他們此技能會在每封郵件處停下來，並繼續到下一個停靠點。

什麼算作批准：「OK」、「已批准」、「繼續」、「下一步」或「是」且未要求任何修改。任何包含修改、疑問或「好，但是…」的回應都不算批准：你需套用修改，重新顯示相同停靠點的內容，然後再次詢問。

語言。 郵件使用西班牙文。預設為西班牙的西班牙文並使用「tú」；如果業務的登陸頁使用其他變體（拉丁美洲西班牙文、voseo）或使用「usted」，則遵循登陸頁的用法。這將在停靠點 1 中確認。

腳本所在位置。 位於此技能的資料夾中，通常是 ~/.claude/skills/email-secuencia-leads/。如果你將其安裝在其他位置（例如專案的 .claude/skills/），請在命令中更改該路徑。

三大原則

1. 不要虛構業務資料。 價格、期限、保證、案例、數字、推薦、姓名和 URL 僅來自簡報、登陸頁、表單回覆以及使用者提供的資料。如果缺少資訊，請寫下 [FALTA: 缺少什麼] 並提出詢問；build_email.py 不會建立包含 [FALTA 的郵件。
2. 先提供價值，再銷售，且不留未解決的疑問。 潛在客戶已要求被聯繫。每封價值郵件都需通過 secuencia.md §2 的測試（之後知道什麼 · 今天的行動 · 服務還剩下什麼）。最低比例為 80/20。此外，每封郵件必須至少破除一個關於該服務的常見疑問或異議，並提供有來源的回應（secuencia.md §2.1）。這是強制性的。
3. 來源層級（secuencia.md §5）：業務資料 → 僅來自其素材；關於受眾的知識 → 步驟 2 的研究，附引用且僅來自權威來源（適用於建議和數據）；電子郵件實務 → parametros.md；法律與常識（RGPD、LSSI、緊急電話、行業規範）→ 允許，標記為 [General] 並在使用者於停靠點 1 確認。如果研究結果與業務衝突，以業務為準。如果簡報與登陸頁矛盾，以簡報為準並發出警告。

詞彙表（開始前請閱讀）

• 檔案：eN/ficha.json，一封郵件的內容；腳本將其轉換為 HTML 和 TXT。
• eN/：序列中每封郵件的資料夾：e0/、e1/、e2/…
• 區塊：範本的一部分（carta、pasos、cita…），列表請見 parametros.md §4。
• 變數：表單中出現的資料，如 [[nombre]] 或 [[nombre|fallback]]；在 n8n 中會轉換為 {{ $json.nombre }}。
• 軟/中/強號召性用語（CTA）：邀請回覆或連結至可閱讀內容 / 文字連結引導至業務的下一步 / 按鈕。按鈕僅用於邀請函、約會微型序列中的郵件（no-show-2 除外），以及 E0（如有線上預約系統，完整規則請見 parametros.md §3）。
• 約會微型序列：cita-confirmacion、cita-recordatorio、no-show 與 no-show-2；僅在有線上預約系統時使用。
• 結尾郵件：最後一封郵件，2-4 句話，優雅地結束。
• 文案審查關卡：在建立郵件前強制進行的文案審查（ogilvy-email.md §3）。儲存於 eN/copy-auditoria.md。
• fuentes.md：列出每個使用到的資料及其來源和引用；在停靠點 1 建立，並在每封郵件中擴充。
• estado.md：記錄哪些郵件已獲批准以及你位於哪個停靠點；允許恢復中斷的會話。

步驟 0 · 需要什麼

通常會在一則訊息中收到簡報和登陸頁。檢查你擁有哪些：

• 簡報：PDF、Word、訊息中貼上的文字或檔案路徑。訊息中的簡短簡報也足夠（包含：賣什麼、賣給誰、價格或取決於什麼、流程、保證、由誰負責）。如果資料夾中有 brief.md，請閱讀它。
• 登陸頁：已發布的 URL 或 HTML 檔案。如果給了一個資料夾，請在其中尋找 index.html 或 dist/index.html。
• 可選：簽署人（姓名、職稱、電子郵件、照片）、線上預約系統、額外素材（樣式指南、常見問題、通話記錄、評論）、需要強調或避免的內容。

如果缺少簡報或登陸頁，你的第一個回應僅需在一行內請求缺少的項目：

為了準備郵件序列，我需要你的 [業務簡報 / 包含表單的登陸頁]。請提供給我，我就可以開始了。

不要請求你已擁有的東西。如果提供了多個素材，請全部閱讀並在提案檔案中以其名稱引用它們。

步驟 1 · 讀取（無需停靠）

工作資料夾：emails/secuencia-<AAAA-MM-DD of today>/（位於專案資料夾內；日期使用 date +%F）。如果已存在該業務的序列且包含 estado.md，請閱讀它並從中斷處繼續，而不是從頭開始。

• 簡報 → brief.txt。PDF：使用 pages 讀取，或使用 python3 -c "import fitz,sys;print('\n'.join(p.get_text() for p in fitz.open(sys.argv[1])))" archivo.pdf。Word：在 Mac 上使用 textutil -convert txt -stdout archivo.docx，或使用 python3 -c "import docx,sys;print('\n'.join(p.text for p in docx.Document(sys.argv[1]).paragraphs))" archivo.docx。來自訊息的文字：直接儲存，來源引用為「brief (mensaje)」。
• 登陸頁 → python3 ~/.claude/skills/email-secuencia-leads/scripts/leer_landing.py "<URL o archivo>" --salida <carpeta>/landing 並開啟 landing/landing.md。讀取原生表單和 Tally 表單（嵌入或彈出視窗）。如果表單來自其他供應商，請向使用者索取問題和核取方塊。如果 URL 出現錯誤，請索取 HTML。務必儲存已讀取 HTML 的副本。
• 開啟 parametros.md、secuencia.md、legal-y-envio.md §1 和 diseno.md §1-§3（AI 設計訊號位於 §1.1）。

步驟 2 · 研究受眾（無需停靠）

嚴格遵循 references/investigacion-publico.md。簡而言之：

1. 根據簡報和登陸頁定義角色（買家人物和潛在客戶原型）。
2. 收集來源：使用網路搜尋（WebSearch 和 WebFetch），或如果你已連接 NotebookLM，則使用包含業務素材的筆記本。
3. 尋找受眾的聲音和權威知識。
4. 分類來源。
5. 回答 11 個固定問題：感受、興趣、他們需要了解服務的什麼、疑慮、異議、對每個的回應、時機、今天的行動、迷思、如何選擇以及限制。
6. 撰寫 investigacion/publico.md，包含角色（A1…）、發現（H1…）以及疑慮與異議表格（D1…）。

這大約需要 10 分鐘。在進行時，用一行告知使用者你正在做什麼。如果你沒有任何搜尋工具，請告知使用者並請求業務專家的素材（他們的通話常見問題、評論、通話記錄）；不要用自己的知識替代。

停靠點 1 · 診斷與計劃 → 等待批准

建立 marca.json（格式：assets/ejemplo-marca.json，規則：diseno.md §2）、fuentes.md 和 plan.md。在聊天中按以下順序顯示：

1. 法律事項，置頂：🟢 獨立通訊核取方塊，或 🔴 缺失/合併/無法驗證，並附上核取方塊的原文。如果是 🔴，則顯示 legal-y-envio.md §1 中的確切警告：僅交付 E0（以及約會郵件，如有）；提出完整計劃讓使用者了解接下來會發生什麼，但在確認核取方塊之前，不會撰寫價值郵件。如果表單收集敏感資料（GDPR 第 9 條），在此處說明為 [General]。如果業務不在西班牙或歐盟，說明這些規則適用於西班牙和歐盟，使用者應確認其所在國家的規則。

2. 謹慎性：如果角色向周遭隱瞞問題（copy-email.md §5），則建議：主旨和預覽文字不包含敏感詞，但仍需清楚表達郵件內容，且不重複其表單回覆。郵件正文則提及主題。使用者確認。

3. 提案摘要（表格，每個資料附帶來源：「brief p. 3」、「landing」、「FAQ l. 120」、「brief (mensaje)」）：服務與承諾 · 角色（A1…，在步驟 2 中定義） · 差異化優勢 · 可用的試用（僅存在且可驗證的） · 流程 · 價格或取決於什麼 · 實際的下一步及其 URL · 簽署人。

4. 表單 → 變數與發送平台：每個問題及其欄位（[[campo]]）、選項以及在哪封郵件中使用（或「不在任何郵件中使用，出於謹慎」）。並詢問使用什麼發送：n8n、ActiveCampaign、Brevo、Mailchimp…這不是最後的細節：它會改變交付的檔案、問候語的變數以及 marca.json 中的 utm_source（legal-y-envio.md §3.1）。如果業務已在支付某平台，則從該平台發送。在序列中途才知道，將需要重新製作所有郵件的連結。

5. 提案類型（A/B/C/D 請見 parametros.md §1）以及原因，一句話說明。

6. 我們從受眾學到了什麼（來自 investigacion/publico.md）：

   • 角色（A1…），每個一行；
   • 5-8 個最有用的發現（包括興趣和需要知道的內容），附 ID、簡短引用和來源組別（AUTORIDAD、PUBLICO 或 CLIENTE）；
   • 最常見的疑慮與異議（D1…），使用潛在客戶的用語、回應（Hn）或 [FALTA: 客戶的回應]，以及每項將在哪封郵件中被破除。

   與業務衝突或需要驗證的項目，請標記。

7. 序列計劃（表格）：郵件 · 天數 · 類型 · 潛在客戶的狀態（Hn） · 破除的疑慮或異議（Dn → Hn） · 之後知道什麼（Hn） · 今天的行動（Hn） · 服務還剩下什麼 · 暫定主旨 · CTA（軟/中/強與目標） · 區塊。每種郵件類型中哪些欄位是強制的：請見 secuencia.md §2 與 §2.1。如果某個強制欄位為空，則該郵件需改變角度或移除。前 5 個最常見的疑慮或異議必須在邀請函之前被涵蓋（在 D 類型中，未被涵蓋的部分由邀請函回應）。僅在有預約系統時才添加約會微型序列。

8. 視覺識別：標誌（URL PNG/JPG 或「缺少 PNG」）、強調色、按鈕、標題字體、紙張，以及標題是否使用大寫或引用是否使用斜體，根據品牌指南。

9. 語言與稱呼：西班牙文變體以及使用 tú、vos 或 usted，根據登陸頁。

10. 缺少的資料，簡短編號列表。此處也包含 [General] 的決定以及標記為「需與客戶驗證」且使用者必須確認的發現。

最後以：「你批准這個序列計劃嗎？沒有你的批准，我不會撰寫任何內容。」 儲存 estado.md：「計劃待批准」。

每封郵件，依序（E0 → E1 → …）

停靠點 2 · 文案 → 等待批准

在撰寫之前，閱讀 copy-email.md（特別是 §0，清晰勝過機智）、brodie-email.md 以及 ogilvy-email.md §0（O1-O5）中關於標題的檢查。根據 secuencia.md §3 在 parametros.md §3-§4 範圍內撰寫。首要規則：郵件的主旨和前兩句話必須讓人明白這是關於什麼，並且所有內容都使用日常用語，沒有玄虛或猜謎。 每個新資料都添加到 fuentes.md。通過 ogilvy-email.md §3 的審查關卡 並將其儲存在 eN/copy-auditoria.md。

顯示：

• 建議的主旨與 2 個替代方案；
• 預覽文字與寄件者；
• 每個區塊的文字，依序排列，使用 [[campo]] 等變數；
• 破除的疑慮或異議（Dn）以及實現此目的的句子；
• CTA 與目標；
• 佈局：區塊順序（parametros.md §4）以及與前一封郵件的不同之處；
• 審查關卡的摘要行。

提問：「你批准郵件 N 的文案嗎？」

• 如果審查關卡未通過（經過多次嘗試），則顯示標記為 _PEND 的文案並附上原因。僅在使用者明確批准或套用其修改後才進行建置。
• 如果缺少業務對郵件主要疑慮的回應（[FALTA: 客戶的回應]），則不撰寫。告知使用者，並在其批准後，在 estado.md 中將其標記為「待回覆」，然後繼續處理下一封郵件。當收到回覆時，在序列結束前再回來處理。

建置與品質控制（無需停靠，直到零錯誤）

1. eN/ficha.json 使用 assets/ejemplo-ficha.json 的格式，並使用已批准的文案原樣。
2. python3 ~/.claude/skills/email-secuencia-leads/scripts/build_email.py eN/ficha.json eN/email.html。產生 email.html（供 n8n 使用）、email.txt 和 email-muestra.html。
   • 如果出現強制更改已批准文字的警告（長度、CTA、主旨），請勿自行更改：返回停靠點 2，提出建議的修正，並再次請求批准。純技術性警告（顏色、粗細）則在 marca.json 中修正。
3. python3 ~/.claude/skills/email-secuencia-leads/scripts/qa_email.py eN/email.html 直到零錯誤。
4. python3 ~/.claude/skills/email-secuencia-leads/scripts/render_preview.py eN/email.html（需要 Google Chrome 或 Chromium 以及 Pillow：pip install pillow）。使用 Read 查看 preview-hoja.png、preview-oscuro.png 以及 previews-detalle/ 中的所有截圖。標準：看起來像一封精心維護的品牌信件，有呼吸空間，標誌在深色模式下可讀，強調色樸素，在行動裝置上沒有任何錯位。而且看起來不像 AI 模板：檢查 diseno.md §1.1 中的訊號（前導標題、型錄襯線字體、虛構的奶油色與赤土色、長線條、裝飾性數字）。如果沒有 Chrome，請告知並要求使用者在其瀏覽器中開啟 email-muestra.html。

停靠點 3 · 郵件完成 → 等待批准

顯示 preview-hoja.png（如果工具存在則使用 SendUserFile；否則提供路徑）。提供主旨和預覽文字，如同它們將在發送平台上顯示的樣子（包含表達式），以及 email.html 和 email.txt 的路徑。在 Mac 上，將 HTML 放入剪貼簿。

…

[為翻譯而截斷]