sales-proposal-template について
再利用可能な Qwilr 提案テンプレートを設計する営業向けスキルです。テンプレート構成、コンテンツの区分、CRM連携用トークン、チームへの展開を案内します。
主な機能
- 01取引タイプ別のテンプレート設計
- 02固定・可変・条件付きセクションの分類
- 03カスタム文面のコピー型
- 04CRM置換トークンの設計
- 05素材ライブラリとチーム展開の計画
活用シーン
- 01営業担当者間で提案書を標準化
- 02SMB向けとエンタープライズ向けのテンプレート作成
- 03CRM自動入力用のQwilrテンプレート準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sales-skills/ sales --skill sales-proposal-templateインストール後、Claude Code で/sales-proposal-templateを入力して読み込まれたか確認します。
同梱ファイルreferences/learnings.mdreferences/template-guide.md
詳細
再利用可能な Qwilr 提案テンプレートを設計する
営業チーム全体で使える、再利用可能な Qwilr テンプレートのシステムを設計できるようユーザーを支援します。構成を標準化し、ブランディングに一貫性を持たせ、API/CRM による自動入力に対応したフィールドを用意します。
ステップ 1 — 背景情報の収集
references/learnings.md が存在する場合は、蓄積された知識を確認するため、まず読み込みます。
ユーザーに次の質問をします。
-
チームでは何を販売していますか?
- 製品/サービスの説明、一般的な案件規模、購入者のペルソナ
-
案件の種類はいくつありますか?
- A) 製品も購入者の種類も 1 つ — テンプレートが 1 つあれば十分
- B) 2~3 種類の違いがある(例:中小企業と大企業、または製品の違い)
- C) 4 種類以上の違いがある(業種、地域、製品ラインなど)
- D) わからない — 一緒に整理してほしい
-
現在の提案書のどこに問題がありますか?
- A) 担当者が毎回ゼロから作成しており、品質にばらつきがある
- B) テンプレートはあるが、古い、またはカスタマイズしにくい
- C) 提案書の作成に時間がかかりすぎる
- D) 価格の提示方法に一貫性がない
- E) これから始めるところで、テンプレートはまだない
-
担当者には、これらのテンプレートをどのように使ってほしいですか?
- A) Qwilr で手動で使用 — テンプレートを選び、カスタマイズして送信する
- B) API 経由で CRM データから自動生成する
- C) 両方 — 自動生成した後、手動でカスタマイズする
- D) わからない — おすすめを知りたい
ユーザーの依頼ですでに背景情報の大部分が示されている場合は、該当するステップに直接進みます。 妥当な前提を明示したうえで、最善を尽くした回答を先に提示し、最後に最も重要な確認質問を 1~2 件だけ尋ねます。背景情報をすべて集めるまで回答を保留しないでください。
ステップ 2 — テンプレート戦略
背景情報に基づいて、テンプレートシステムを設計します。
必要なテンプレート数
案件の種類をカバーできる最小限のテンプレート数にします。目安は次のとおりです。
| ケース | 必要なテンプレート |
|---|---|
| 製品 1 つ、購入者の種類 1 つ | マスターテンプレート 1 つ |
| 製品 1 つ、中小企業と大企業の購入者 | テンプレート 2 つ(詳細度/フォーマルさを変える) |
| 複数の製品、購入者の種類は同じ | 製品ごとにテンプレート 1 つ |
| 複数の製品と購入者セグメント | マトリックス。ただし 5~6 個を上限とし、条件付きセクションを使用 |
固定セクションと可変セクション
各テンプレートには、次の項目を含めます。
固定セクション(すべての提案書で共通):
- 会社紹介/「当社について」 — ブランドストーリーに一貫性を持たせる
- チーム/連絡先セクション — 担当者ごとに自動入力する
- 法務/条件セクション — 標準条件。変更はまれ
- CTA/承諾セクション — 標準の承諾フロー
可変セクション(案件ごとにカスタマイズ):
- エグゼクティブサマリー — 見込み顧客の状況に合わせて調整する
- 課題/解決策の説明 — 購入者の課題に合わせて調整する
- 業務範囲 — 案件ごとに設定する
- 価格/見積もりブロック — 案件固有の明細と金額
条件付きセクション(案件によって含めるもの):
- 導入事例 — 見込み顧客の業種に最も関連するものを選ぶ
- 技術アーキテクチャ — 技術担当者が購入者の場合のみ
- ROI/ビジネスケース — 大企業または経営幹部が購入者の場合のみ
- セキュリティとコンプライアンス — 調達要件で必要な場合のみ
ステップ 3 — テンプレートの設計図、トークン設計、展開
references/template-guide.md を読んでください。構築の詳細については、テンプレートごとの設計図形式(セクションごとに「固定/可変/条件付き」を示す表)、可変セクション(エグゼクティブサマリー、課題/解決策)用の穴埋め式コピー作成フレームワーク、CRM の自動入力に使う標準およびカスタムの置換トークン一覧(トークンごとのチーム向けガイドライン付き)、そしてアセットライブラリとチーム展開の計画を確認してください。
次の順番でユーザーを案内してください。
- 各セクションを固定、可変、または条件付きに分類して設計図を作成します。固定コンテンツはそのまま再利用し、可変コンテンツは案件ごとにカスタマイズします。
- 可変セクションには空欄ではなく、コピー作成フレームワークを担当者に提供します(エグゼクティブサマリーと課題/解決策の穴埋めテンプレート)。これにより、品質を一貫させます。
- CRM で自動入力するトークン(会社、連絡先、担当者、案件金額)を設計し、適切なフォールバックの既定値を設定して、生の
{{token}}が購入者に表示されないようにします。判断を多く要するセクションは手動のままにします。 - 補助アセットライブラリを構築します。業界別のタグを付けたケーススタディ、顔写真、ロゴ、価格のプリセットを用意します。
- 展開します:構築 → テンプレートごとに 1 ページのガイドを作成 → 短時間のライブセッションでトレーニング → 担当者 2~3 名でテスト → エンゲージメントデータ(
/sales-proposal-analytics)を使って反復改善 → CRM の自動生成を自動化(/sales-qwilr-automation)。
注意点
-
テンプレートを厳格にしすぎないでください。 テンプレートは担当者に強力な出発点を提供するものであり、行動を縛るものであってはいけません。エグゼクティブサマリー、スコープ、価格を案件ごとに簡単にカスタマイズできなければ、担当者はテンプレートを使わなくなります。固定文ではなく、穴埋め式のフレームワークを使ってください。
-
可変のプレースホルダーを忘れないでください。 自動入力するフィールド(会社名、連絡先情報、担当者情報、案件金額)には、すべてのテンプレートで
{{token}}構文を使ってください。Claude はトークンではなく、値をハードコードした例をテンプレートに記載することがあります。 -
チームが複数の案件タイプに対応しているのに、1 種類の案件だけを想定して設計しないでください。 テンプレートを作る前に、案件タイプがいくつあるか確認してください。「SMB SaaS」と「Enterprise Financial Services」の両方に単一のテンプレートを使っても、どちらにも適しません。ただし、細分化しすぎるのも避けてください。多くのチームに必要なのは 15 個ではなく、2~4 個のテンプレートです。
-
モバイル対応を忘れないでください。 Qwilr ページはウェブベースで、スマートフォンやタブレットで閲覧されます。小さな画面で崩れる、横並びのレイアウトや幅の広い表に依存するデザインは避けてください。展開前に、モバイルでテンプレートをテストしてください。
-
展開計画なしにテンプレートを作成しないでください。 優れたテンプレートでも、担当者に知られていなかったり、使い方が分からなかったりすれば、努力が無駄になります。各テンプレートを使うタイミングと、可変セクションをカスタマイズする方法を必ず案内してください。
-
継続的に改善します:ここに記載されていないことが分かった場合は、その日の日時とともに
references/learnings.mdに追記してください。
例
例 1:SMB 向けと Enterprise 向けの 2 テンプレートシステム
ユーザーの発言:「チームの営業担当者は提案書を毎回ゼロから作成していて、見た目もばらばらです。中小企業にも大企業にも SaaS プラットフォームを販売しています。チーム全員で再利用できるテンプレートを作るのを手伝ってください。」
スキルの動作:
- 背景情報を収集します。製品は 1 つ、購入者は異なる 2 種類(SMB、Enterprise)であり、主な問題は営業担当者が個別に作成する提案書に一貫性がないことを確認します。
- テンプレートを 2 つ提案します(1 つでも 15 個でもありません)。簡潔で要点を押さえた SMB 向けテンプレートと、ROI/ビジネスケースおよびセキュリティ/コンプライアンスの条件付きセクションを追加した Enterprise 向けテンプレートです。
- 各テンプレートの設計表を作成します。表紙(Splash、可変)、エグゼクティブサマリー(テキスト、記入式の枠組みを含む可変項目)、価格(見積もりブロック、可変)、会社紹介(固定)、チーム(
{{rep_name}}で自動入力)、次のステップ(承諾ブロック、固定)です。 - 可変項目のエグゼクティブサマリーと課題/解決策の各セクションで、白紙から始めるのではなく、営業担当者が質の高い内容を書き始められるように、コピー作成の枠組みを追加します。
- 6 段階の導入計画を示します。保存済みブロックを使って作成し、各テンプレートの 1 ページ資料を用意し、30 分のセッションでトレーニングし、営業担当者 2~3 人でテストし、改善を重ねた後、自動化します。
結果:構成が標準化され、ブランドの一貫性が保たれ、トークン対応のフィールドを備えた、再利用可能な Qwilr テンプレートが 2 つ完成します。さらに導入計画も用意され、営業担当者がゼロから作成する必要がなくなり、チーム全体の提案書に一貫性が生まれます。
例 2:CRM の自動入力に向けたトークン設計
ユーザーの発言:「すでに Qwilr テンプレートはありますが、営業担当者は会社名、連絡先、価格を毎回手入力しています。CRM と連携して自動入力したいです。」
スキルの動作:
- 標準トークンセットを CRM のフィールドに対応付けます。
{{company_name}}、{{contact_first_name}}、{{rep_name}}、{{deal_amount}}、{{close_date}}を割り当て、これらを「必ず自動入力し、手入力しない」項目として明示します。 {{industry}}、{{seat_count}}、{{pain_point}}など、取引タイプ別のカスタムトークンを追加し、半自動(確認が必要)か、常に手動(人間の判断が必要)かを分類します。- CRM のフィールドが空でも、公開ページに
{{token}}がそのまま表示されないよう、代替値/デフォルト値を推奨します。 - CRM と Qwilr の実際の連携設定は
/sales-qwilr-automationに引き継ぎます。テンプレート設計と自動化の実装は別の作業だからです。
結果:チームがテンプレートにそのまま組み込めるトークンマップが完成します。自動入力される項目と営業担当者が記入する項目が明確になり、手入力やトークンがそのまま表示される問題を防げます。
例 3:業界別テンプレートをゼロから作成
ユーザーの発言:「営業チームを立ち上げたばかりで、テンプレートはまだありません。医療、フィンテック、小売業界に販売していますが、業界ごとに重視される点が異なります。」
スキルの動作:
- 3 種類以上の取引タイプに応じたバリエーションを特定しますが、テンプレート数は 5~6 個までに抑え、業界別に完全に独立した 3 つのテンプレートを作るのではなく、ベーステンプレート 1 つに条件付きセクションを追加する方法を推奨します。
- 会社紹介、法的条項、承諾フローなどの固定セクションを一度だけ定義し、そのうえで業界別の条件付きセクションを設けます。医療/フィンテック向けにはセキュリティとコンプライアンス、小売向けには事例ライブラリから小売業に関連する事例を追加します。
- 同時に整備するアセットライブラリとして、業界別にタグ付けした事例 3~5 件、プロフィール写真ライブラリ、顧客ロゴ、見積もりブロックのプリセットを推奨します。
{{industry}}と{{pain_point}}トークンを使い、各業界の課題に沿った内容を課題/解決策のセクションに反映できるよう、それぞれの業界に合わせたコピー作成の枠組みを提供します。
結果:条件付きセクションとタグ付きアセットライブラリを通じて 3 つの業界に対応する、保守しやすい単一のテンプレートファミリーが完成します。個別のテンプレートを 15 個作成するような保守負担もありません。
トラブルシューティング
営業担当者が新しいテンプレートを使わず、毎回ゼロから作成してしまう
原因:テンプレートの柔軟性が足りず、営業担当者が個々の案件に合わせてエグゼクティブサマリー、スコープ、価格を簡単にカスタマイズできません。そのため、テンプレートを調整するより最初から作り直すほうが早くなっています。
解決策:可変部分の制約を緩めます。エグゼクティブサマリー、スコープ、価格に含まれる固定文言を、営業担当者が編集できる、しっかりしたたたき台となる穴埋め式のフレームワークに置き換えます。本当に標準化すべき内容(会社紹介、条件、承認フロー)のみを固定します。
提案書のライブページに、{{token}} のテキストがそのまま表示される
原因:トークンが参照する CRM フィールドがその案件では空で、フォールバック値やデフォルト値も設定されていないため、プレースホルダーがページ上にそのまま表示されています。
解決策:任意のトークンすべてに適切なデフォルト値を設定し、フィールドが空でも {{token}} の構文が露出せず、自然に表示されるようにします。自動入力は、確実に存在するフィールド(会社名、連絡先、営業担当者の情報、案件金額)に限定し、それ以外は半自動として、送信前に営業担当者が確認するようにします。
テンプレートが多すぎて、どれを使えばよいのかわからない
原因:システムが細分化されすぎており、製品、購入者、地域の組み合わせごとに別々のテンプレートが用意されていました。そのため、営業担当者はどれを使えばよいかわからず、利用が定着していません。
解決策:テンプレート数を 5~6 個に抑えます。よく似たテンプレートは条件付きセクションを備えた基本テンプレートに統合し、各テンプレートに明確な「使用する場面」の説明を付けて、営業担当者が数秒で適切なものを選べるようにします。ほとんどのチームで必要なのは 15 個ではなく、2~4 個です。
関連スキル
/sales-proposal-page— テンプレートを使わず、提案書をゼロから作成する/sales-qwilr-automation— テンプレートを CRM に接続して自動生成する/sales-proposal-analytics— エンゲージメントの高いテンプレートを追跡する/sales-deal-room— 複数ページのディールルームを設計する(専用テンプレートが必要になる場合があります)/sales-content— 一般的な営業支援コンテンツを作成する/sales-do— どのスキルを使えばよいかわかりませんか?ルーターがあらゆる営業目標に適したスキルを選びます。インストール方法:npx skills add sales-skills/sales --skill sales-do