解決方案建議書提示詞（銷售方案書：客戶現狀與目標、方案設計、投入與回報、實施計劃、為什麼選我們）
需求溝通之後要給客戶提交正式方案時用：把訪談記錄和產品能力組織成一份以客戶問題為主線的建議書大綱與正文初稿，而不是產品說明書的堆疊。
通用大模型 對話模型通用
你是一名售前顧問，寫過上百份中標的方案建議書。你的結構原則：客戶的問題佔前三分之一，我方產品排在問題和目標之後出現；每一個方案模組都要能對應到客戶說過的一句話。 客戶名稱、行業與規模：[客戶概況] 需求溝通記錄（客戶原話盡量保留）：[需求記錄] 客戶希望達到的目標與衡量方式：[客戶目標] 我方產品 / 服務能力清單：[我方能力] 可引用的真實案例（沒有就寫無）：[可用案例] 報價與週期的大致範圍：[報價與週期] 這份方案的讀者（使用部門、IT、財務、老闆）：[方案讀者] 請輸出： 1. 方案書目錄（8～10 節），並說明每節回答讀者的哪個問題。建議順序：摘要 → 我們對現狀的理解 → 目標與成功標準 → 方案總覽 → 分模組說明 → 實施計劃與雙方分工 → 投入與回報 → 風險與應對 → 為什麼是我們 → 下一步。 2. 一頁摘要：不超過 300 字，包含客戶的核心問題、方案要點三條、預期結果、投入與週期、需要客戶決定的事。 3. 「我們對現狀的理解」一節正文：用客戶原話引出 3～4 個問題，每個問題寫出現象、影響、根源；我沒有證據的推斷標「待與貴司確認」。 4. 需求—方案對應表：客戶需求 | 對應的方案模組 | 交付成果 | 驗收方式。需求記錄裏有而我方能力覆蓋不了的，單列為「本期不包含及原因」。 5. 實施計劃：階段、週期、我方工作、需要客戶配合的事項。 6. 投入與回報：只用我提供的數字和案例；沒有數據時給出測算公式和需要客戶提供的參數，不要自行估算回報。 7. 針對 [方案讀者] 中每類讀者各寫一句他最關心的話，標明放在哪一節。 約束：不寫「行業領先」「全面賦能」這類無法驗證的表述；不貶低競品；能力清單裏沒有的功能不得寫進方案。
高亮處換成你自己的內容：[客戶概況]、[需求記錄]、[客戶目標]、[我方能力]、[可用案例]、[報價與週期]、[方案讀者]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[需求記錄] 裏保留客戶原話，哪怕是口語，比如「月底對帳要三個人幹四天」。方案書裏引用這句話，比任何修飾都更能讓客戶覺得被聽懂了。[可用案例] 沒有就老實寫「無」，AI 會改用測算公式，不會給你編一個。
常見失敗與調整：
- 寫成產品手冊：檢查前三節裏產品名出現了幾次，多了就讓它把產品介紹後移。
- 需求全部「滿足」：對應表裏沒有任何「本期不包含」，通常意味着範圍沒想清楚，交付時會吃虧。
- 摘要像目錄：摘要要有結論和數字，追問「把摘要改成老闆只讀這一頁也能做決定的版本」。
迭代追問：「按這份方案生成 12 頁講解用的幻燈片提綱」「客戶財務總監會質疑哪三點，先替我準備回答」。
示例輸出
示例，僅供參考（虛構：為一家區域建材經銷商提供對帳與應收管理方案）
我們對現狀的理解（節選）
訪談中財務王經理提到：「月底對帳要三個人幹四天，還總有兩三家對不上。」我們的理解是：
- 現象：發貨單、簽收單、開票記錄分別在三張表裏，靠人工按客戶名匹配。
- 影響：每月約 12 個人日用於對帳；對不上的金額在次月才發現，催收被動。
- 根源：單據之間沒有共同的編號（待與貴司確認）。
需求—方案對應表（節選）
| 客戶需求 | 方案模組 | 交付成果 | 驗收方式 |
|---|---|---|---|
| 月底對帳少花時間 | 單據自動匹配 | 對帳差異清單 | 抽取 3 家客戶，系統結果與人工結果一致 |
| 想按業務員看回款 | 應收看板 | 按業務員、帳齡兩個維度的報表 | 財務確認口徑 |
本期不包含：與銀行流水的自動核銷——需貴司開通銀企直連，建議列入二期。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～