sales-enablement

sales-enablement 技能總覽

sales-enablement 技能用來產出業務團隊真正能拿來用的 B2B 銷售素材：sales decks、one-pagers、異議處理文件、demo scripts、playbooks，以及提案支援材料。它最適合已經有明確產品、目標買方與銷售流程的團隊，但需要的是能支援真實交易的精準銷售內容，而不是泛泛的行銷文案。

sales-enablement 技能適合哪些人

如果你需要的是以下類型的材料，就適合使用 sales-enablement 技能：

• 用於銷售對話與後續跟進的內容
• 針對特定 deal 的 proposal 支援材料
• 給業務與內部 champion 使用的 enablement 文件
• 適用於 discovery、demo 與異議處理的結構化 talk tracks

其中，若你需要的是 sales-enablement for Proposal Writing，而且希望 proposal 內容能建立在買方痛點、證據、差異化與下一步邏輯之上，這個技能尤其實用。

它真正解決的是什麼工作

這個技能真正要做的，不只是「幫你寫一份 deck」。它的核心價值，是把分散的產品知識整理成可直接用於銷售的資產，並對應到特定買方、使用情境與 deal 階段。當你需要的是貼近實際銷售情境的內容，而不只是表面上寫得漂亮，這個技能的優勢會特別明顯。

它和一般 prompt 有什麼不同

一般 prompt 很容易產出功能清單與制式說服話術；sales-enablement skill 則會更偏向以下幾件事：

• 依受眾調整 framing
• 反映實際 sales motion 的內容設計
• 補上 proof 與 objection handling
• 使用 repo 內附 references 的結構化格式
• 產出業務可在現場直接使用的材料，而不只是內部審稿用文件

最適合產出的內容

從 repository 內容來看，這個技能特別適合支援：

• 10–12 頁的 sales decks
• objection handling 文件
• discovery 與 demo scripts
• 產品與 use case one-pagers

什麼情況下不適合用這個技能

如果你的主要需求是以下內容，建議不要使用這個技能：

• website copy 或 homepage messaging
• cold outbound email sequences
• 純粹做 competitor battlecards

這些工作在 repo 裡本來就被導向其他更專門的技能處理。

如何使用 sales-enablement 技能

sales-enablement 的安裝情境

上游的 SKILL.md 沒有提供自己的安裝指令，因此常見的安裝方式會是：

npx skills add https://github.com/coreyhaines31/marketingskills --skill sales-enablement

如果你的環境使用的是不同的 skill loader，就從 coreyhaines31/marketingskills 加入這個 skill，並指定 skills/sales-enablement 路徑。

先讀這些檔案

如果你想快速判斷值不值得裝、也想更快上手，建議依序先看：

1. skills/sales-enablement/SKILL.md
2. skills/sales-enablement/references/deck-frameworks.md
3. skills/sales-enablement/references/objection-library.md
4. skills/sales-enablement/references/demo-scripts.md
5. skills/sales-enablement/references/one-pager-templates.md
6. skills/sales-enablement/evals/evals.json

這個順序重要，原因是：

• SKILL.md 會說明觸發條件與 workflow。
• references/ 放的是實際會左右輸出品質的模板與框架。
• evals/evals.json 則能看出這個技能認定「好答案」應該包含哪些元素。

在下 prompt 前先確認產品背景資料

sales-enablement usage 的流程有一個很關鍵的前置檢查：先找 .agents/product-marketing-context.md 或 .claude/product-marketing-context.md。這個技能明確希望先讀這些背景內容，再決定還缺哪些資訊，而不是每次都從頭做 discovery。

如果檔案存在，就直接使用。若不存在，再只補齊缺漏資訊即可。

這個技能最低限度需要哪些輸入

想讓輸出真正有用，至少要提供：

• 你賣的是什麼
• 買方是誰
• 主要痛點／問題是什麼
• 相較替代方案的差異化
• proof points 或證據
• sales motion 與 deal 背景
• 你要的資產類型

如果缺少這些資訊，技能還是能起草，但內容通常會開始變得很 generic。

怎麼把模糊需求變成有效 prompt

弱的提問方式：

• 「幫我做一份 sales deck。」

更強的 sales-enablement guide prompt：

• 「Create a 10–12 slide sales deck for our B2B SaaS product. Buyer: HR directors at 500–5000 employee companies. Main pain: low employee engagement visibility across distributed teams. Differentiator: real-time pulse surveys with AI-generated insight summaries. Proof: one customer improved manager response time by 38%. Sales motion: mid-market inside sales, 45-day cycle. Include slide goals, core copy, speaker notes, and what proof is still missing.”

這些額外細節能幫助技能挑對敘事弧線、安排 proof 位置，並用更合理的方式處理異議。

善用內建 deck framework

如果要做 deck，repository 提供的指引比單純下「pitch deck」prompt 更具體。references 指向的故事結構大致像這樣：

• current world problem
• cost of the problem
• why current solutions fail
• a better way
• your solution
• how it works
• proof
• pricing or commercial shape
• urgency / why now
• next steps

這也是為什麼在這類任務上，安裝 sales-enablement 會比從零即興發揮更實際。

用 sales-enablement 處理 Proposal Writing

如果你要做的是 sales-enablement for Proposal Writing，不要只要求輸出 proposal narrative。本技能更需要你先提供 proposal 背後的銷售情境，例如：

• buyer stakeholders
• deal stage
• success criteria
• rollout scope
• 已經被提出的 objections
• pricing shape
• 預期 ROI 或 cost-of-delay 邏輯

接著再要求它產出 proposal 元件，例如：

• executive summary
• problem framing
• solution fit
• implementation approach
• success metrics
• proof points
• commercial assumptions
• next-step CTA

這樣做出來的內容，才會像是和該 deal 緊密相連的 proposal 材料，而不是從行銷文案重組出來的版本。

依資產類型安排最佳 workflow

可以用這個簡單流程：

1. 先整理或載入 product marketing context。
2. 一次只選一種 asset type。
3. 清楚告訴技能受眾、deal 階段與 use case。
4. 要求輸出採用 repo references 裡的結構。
5. 檢查缺少的 proof、數字與案例。
6. 進行一次以「提升具體性」為主的修訂，而不是只改文風。

這個技能比較適合逐一處理單一資產；如果你一次要求它生成整套 enablement library，效果通常會比較差。

與 repository 最契合的實用 prompts

以下這類要求通常會有不錯的結果：

• 「Create an objection handling doc for these six recurring objections.」
• 「Write a discovery-to-demo script for a 30-minute first call.」
• 「Draft a use-case one-pager for IT leaders evaluating vendor consolidation.」
• 「Build a sales deck with slide-by-slide copy and presenter notes.」

這些需求和 reference files 及 evals 的設計方向一致，所以輸出通常會更扎實、更貼近實戰。

sales-enablement 使用時常見的錯誤

最常見、而且本來可以避免的錯誤包括：

• 沒有提供買方或 deal 背景
• 要求的是「marketing copy」而不是 sales asset
• 跳過 proof points
• 在同一個 prompt 裡混入太多輸出
• 沒有說清楚資產是 generic、vertical、persona，還是 deal-specific

大多數品質不佳的輸出，其實不是技能格式有問題，而是輸入資訊太弱。

sales-enablement 技能 FAQ

sales-enablement 技能適合新手嗎？

適合，前提是你已經清楚自己的產品與買方。裡面的 templates 能降低摸索成本。不過，如果你無法提供差異化、proof，或銷售階段背景，初學者還是很容易卡住。

sales-enablement 比一般 prompting 強在哪裡？

sales-enablement skill 的強項在於結構更完整。它不只是產出寬泛的說服性文案，而是傾向圍繞買方痛點、proof、objections，以及業務實際可用性來組織內容。內建 references 才是它最有價值的地方。

這只適用於 SaaS 嗎？

範例與 objection library 明顯偏向 B2B SaaS，所以這是最穩妥的使用情境。不過，只要你的其他 B2B 場景在購買流程、proof 形式與 sales assets 上相近，仍然可以套用。

不看 references，也能直接安裝 sales-enablement 使用嗎？

可以，但輸出品質通常會差一截。references 裡面放的是 decks、demo scripts、objections 與 one-pagers 的具體框架；想快速理解這個技能的運作方式，這些檔案是最有效率的入口。

它適合拿來寫 proposal 嗎？

適合，尤其是 sales-led proposals。當 proposal 需要更好的問題 framing、能反映 stakeholder 差異的訊息設計、清楚的 differentiators，以及可信的 proof 時，這個技能會很有幫助。不過，如果你要處理的是採購導向、法律格式很重的文件，它單獨使用就沒那麼合適。

什麼情況下不該用 sales-enablement？

當你的主要需求是以下任務時，不建議使用 sales-enablement：

• homepage 或 landing page 文案
• outbound prospecting emails
• 只做深入的 competitor alternatives research

這些工作需要不同的 skill，或至少需要額外搭配其他支援。

這個技能需要公司內部檔案嗎？

非常有幫助。它明確會檢查 .agents/product-marketing-context.md 或 .claude/product-marketing-context.md，這是一個很強的訊號：這個技能預期你有可重複利用的公司背景資料，而不是從空白頁面開始硬寫。

如何改善 sales-enablement 技能的輸出

提供更明確的商務脈絡

想最快提升 sales-enablement 輸出品質，建議補上：

• deal size 或價格區間
• 銷售週期長度
• self-serve、inside sales，還是 field sales
• buying committee 的角色組成
• 買方目前使用的替代方案

這些資訊會直接影響訊息設計、objection handling 與 CTA 的品質。

先補 proof，再來修文案

如果第一版聽起來很 generic，不要一開始就要求「寫得更好」。先補以下資訊：

• 客戶成果
• 可量化的結果
• 導入速度
• 節省了多少時間
• 替換舊方案或切換供應商的故事

這個技能的框架本來就假設：proof 是核心，不是附加項。

指定精準的受眾與階段

給 champion 的 one-pager，和給 economic buyer 的 one-pager，根本不是同一種東西。第一次 discovery 用的 demo script，也和後期客製化 walkthrough 不同。請清楚告訴技能：

• persona
• industry
• company size
• deal stage
• intended use

這些資訊通常比語氣指示更重要。

要求標記缺漏資訊

一個夠強的 sales-enablement usage prompt，可以加上：

• 「Mark assumptions clearly.」
• 「List missing inputs that would strengthen this.」
• 「Flag unsupported claims.」
• 「Suggest proof points we should gather.」

這樣做能讓草稿在真實銷售情境中更安全，也更容易後續補強。

用一次聚焦修訂提升成果

第一版出來後，建議只做一次明確聚焦的修訂，例如：

• 針對高階主管讀者收斂內容
• 改寫成特定 vertical 適用版本
• 把 claims 轉成 ROI language
• 減少 feature 細節、提高 business impact
• 讓 objections 更可信、少一點防禦感

這種聚焦修訂，比起籠統地說「幫我改好一點」更有效。

留意這些失敗模式

常見的弱輸出包括：

• 一開頭就在講產品功能，而不是買方痛點
• 回答 objections 時只是在否認，而不是重新 framing
• demo scripts 聽起來像單向獨白
• decks 裡沒有 cost-of-doing-nothing 的邏輯
• one-pagers 只有主張、沒有 proof

這些問題都可以修正，前提是你要把 prompt 重新錨定到 repo references 的模式上。

用 evals 自我檢查品質

evals/evals.json 很值得看，因為它會顯示「好的執行」通常包含哪些內容，例如：

• 先檢查 product marketing context
• 為不同資產套用正確 framework
• 依受眾與 use case 做調整
• 納入 proof 與 talk tracks

如果你的輸出缺了這些要素，問題通常不是技能本身，而是 prompt 定義得不夠完整。

改善 sales-enablement for Proposal Writing 的輸出

如果想讓 proposal 類輸出更好，建議提供：

• 用客戶原話表達的目標
• scope 邊界
• implementation constraints
• stakeholder concerns
• 30/60/90 days 的 success metrics
• 買方已經提過的 decision criteria

然後再要求技能把每個 proposal section 對應到一個 buyer concern。這樣做出來的 proposal 會更有說服力，也更方便 champion 帶回內部重複使用。