sales-proposal-page

Qwilr の提案ページを作成する

ユーザーが Qwilr の提案ページを作成し、構成できるよう支援します。セクションの計画から、文章の作成、インタラクティブ要素の設定まで対応します。Qwilr は、見積もりブロック、埋め込みコンテンツ、リアルタイムのエンゲージメント追跡機能を備えたインタラクティブなウェブページで、静的な PDF の提案書を置き換えます。

ステップ 1 — 背景情報を集める

references/learnings.md が存在する場合は、蓄積された知識を得るため、まず読み込みます。

ユーザーに次の質問をします。

1. 何を提案しますか？（製品／サービス、範囲、価格帯）
2. 購入者は誰ですか？（役職、企業、業界、企業規模）
3. この商談はどの段階ですか？
   • A）初期 — 選択肢を検討しています
   • B）中期 — デモを見ており、正式な提案書を必要としています
   • C）最終段階 — 口頭で合意しており、書類の手続きが必要です
   • D）既存の商談の更新または拡大
4. どの Qwilr 機能を使いたいですか？
   • A）価格表付き見積もりブロック（インタラクティブな明細項目、オプションの追加項目）
   • B）シンプルなテキストベースの提案書（インタラクティブな価格設定なし）
   • C）複数ページの商談ルーム全体（代わりにこちらに引き継ぎます：/sales-deal-room {your question}）
   • D）未定 — 適切なものを提案する

ユーザーの依頼に、こうした背景情報の大部分がすでに含まれている場合は、該当するステップに直接進みます。 合理的な前提を明示したうえで、最善の回答を先に示し、最後に最も重要な確認質問を1～2個だけ尋ねます。すべての背景情報を集めるまで回答を保留しないでください。

ステップ 2 — ページの構成案を作成する

Qwilr のブロックタイプに対応させた、セクションごとのページ構成を設計します。Qwilr の優れた提案ページは、通常、次の流れで構成されます。

セクション	Qwilr ブロックタイプ	目的
表紙／ヒーロー	スプラッシュブロック	第一印象、見込み客の名前／ロゴ、1 行のバリュープロポジション
エグゼクティブサマリー	テキスト＋画像ブロック	これが相手にとって特に重要な理由（最大 2～3 段落）
課題と解決策	テキストブロックまたはアコーディオン	課題を明確にし、相手のニーズに対応するソリューションを提示する
作業範囲	テキストブロックまたはアコーディオン	含まれる内容、成果物、スケジュール
価格	見積もりブロック	明細項目付きのインタラクティブな価格表
スケジュールとマイルストーン	テキストブロック	重要な日程、フェーズ、依存関係
当社／チームについて	テキスト＋画像ブロック	関連するチームメンバー、事例の抜粋による信頼性の提示
次のステップ／CTA	承認ブロック	提案の承認、署名、または通話の予約など、明確な行動喚起

商談の背景に応じて、この構成を調整します。

• 初期段階の商談：課題と解決策を詳しく取り上げ、詳細な作業範囲は控えめにします
• 最終段階の商談：作業範囲と価格を中心にし、課題の提示は控えめにします
• 更新／拡大：まず達成した成果を示し、その後に拡大する範囲と価格を提示します。拡大に関する明細項目（新しいモジュール、追加項目、追加シート）には、Qwilr の isOptional: true を使用し、購入者が基本の更新内容に追加するものを自分で選べるようにします。これにより、CFO や予算管理者が決定権を保ちながら、アップセルをスムーズに進められます。
• 技術系の購入者：技術アーキテクチャまたは統合に関するセクションを追加します
• 経営幹部の購入者：ROI／ビジネスケースのセクションを追加します

Step 3 — 提案文を作成する

プレースホルダーだけでなく、各セクションの実際の文章を作成します。次の原則に従ってください。

• エグゼクティブサマリー：最大2〜3段落にまとめます。自社の製品ではなく、相手が抱えている問題から始めます。相手の状況に関する具体的な内容（会社名、相手が挙げた目標、ヒアリングで判明した課題）を盛り込みます。
• 課題と解決策：相手が使った言葉を反映します。それぞれの課題に、具体的な機能を対応づけます。
• 作業範囲：双方が「完了」の基準を把握できるだけの詳細を含めつつ、契約書のようにならないよう、明確な成果物を記載します。
• 価格に関する文章：見積もりブロックの前に置く説明文を作成します。金額を提示する前に価値を伝える部分です。
• CTA：相手が承諾した後の流れを具体的に示します（48時間以内のキックオフコール、X週に実装開始など）。

後でQwilr APIを使って自動入力する可能性のある項目には、{{company_name}}、{{contact_first_name}}、{{deal_amount}} などの {{token}} 構文を使用します。

Step 4 — インタラクティブ要素を設定する

提案に見積もりブロックを含める場合は、価格体系を設計します。

見積もりブロックの設定

• セクション：明細項目を論理的にグループ化します（例：「プラットフォームライセンス」「導入」「アドオン」）。
• 明細項目：各項目に名前、説明、価格を設定します。
  • ほとんどの項目には fixedCost タイプを使用します。
  • アドオンには isOptional: true を設定し、購入者が選択・解除できるようにします。
  • 購入者が数量を選べるようにする場合は、quantity の範囲を設定します（シート数、ユニット数）。
  • 適切な場合は、割引（割合または固定額）を適用します。
• 請求：項目ごとに oneOff または recurring（月次／四半期ごと／年次）を指定します。
• 税金：該当する場合は、税金の設定を含めます。

検討すべきインタラクティブ機能

• 任意の明細項目：購入者がアドオンを自分で選べるようにします。これにより、購入者に選択権を与えながら、取引額を増やせます。
• 数量セレクター：シート単位またはユニット単位の価格設定では、購入者が数量を調整できるようにします。
• 割引表示：割引を見やすく表示し、購入者が受けられるメリットを強調します。
• セクションの小計：購入者がカテゴリごとの費用内訳を把握しやすくします。
• 機能リスト：項目の内容が伝わるよう、明細項目に機能の説明を追加します。

Step 5 — API ペイロードを生成する（任意）

ユーザーがQwilr APIを使ってページをプログラムから作成する場合は、ブロック、トークン、見積もりセクションを含む POST /pages のJSONペイロードを生成します。ペイロードの構造、フィールドのリファレンス、エンドポイントの一覧については、references/qwilr-api-proposals.md を参照してください。

重要なポイント：

• まず GET /blocks/saved を実行して、利用可能なブロックIDを確認します。
• 送信前にレビューできるよう、isPublished: false を設定します。
• tokens を使って、CRMデータを {{token}} プレースホルダーに挿入します。
• 明細項目、任意のアドオン、請求頻度を含む見積もりセクションを設定します。

注意点

• 長文の塊を作らないでください。 Qwilr はビジュアルなウェブベースのプラットフォームであり、Word 文書ではありません。Qwilr のブロックタイプ（Splash、Accordion、Quote ブロック）を使って、コンテンツを分割してください。セクションが 3 段落を超える場合は、Accordion に再構成するか、サブセクションに分割してください。

• インタラクティブな料金・見積もりブロックを忘れないでください。 Claude は料金を通常のテキストで記述しがちです。Qwilr の見積もりブロックは、この製品の重要な差別化要素です。料金を含む提案には必ず使用してください。項目、オプションの追加項目、数量セレクターを設定してください。

• CTA を省略しないでください。 すべての提案に、Qwilr の Accept ブロックを使った明確な行動喚起が必要です。「ご意見をお聞かせください」で終わらせず、「この提案を承認する」や「キックオフミーティングを予約する」で締めくくってください。

• 提案を長くしすぎないでください。 ウェブ上の提案は PDF ではありません。購入者はざっと目を通します。質の高い Qwilr の提案は 5～8 セクションです。それより長くなる場合は、詳細な内容を代わりにディールルーム（/sales-deal-room）に移すことを検討してください。

• {{token}} プレースホルダーを忘れないでください。 後で提案を API 経由で自動生成する可能性がある場合は、ハードコードした値ではなく、全体を通して {{company_name}}、{{contact_first_name}} などを使用してください。

• 自己改善：ここに記載されていないことを見つけたら、今日の日付を添えて references/learnings.md に追記してください。

例

例 1：インタラクティブな料金設定を含む、商談終盤の SaaS 提案

ユーザーの発言：「Acme Corp 向けに Qwilr の提案書が必要です。口頭ではすでに合意済みで、分析プラットフォームが年間 48,000 ドル、オンボーディングパッケージはオプションです。中規模のフィンテック企業で、購入担当者はデータ部門の VP です。」

スキルの動作：

1. 商談終盤と判断し、スコープと料金を前面に出して、課題の説明は簡潔にします。
2. ページの設計図を作成します。Acme の名前を入れた Splash カバー、データ目標に結び付けた短いエグゼクティブサマリー、簡潔な作業範囲に続けて、Quote ブロックを配置します。
3. 見積もりブロックの上に、価値を強調する説明文を含めて各セクションの文章を作成します。
4. 見積もりブロックを設定します。「Platform License」セクションに、年間請求で recurring として請求する年額 48,000 ドルを設定します。また、「Onboarding」の項目には isOptional: true を設定し、VP が任意で選択できるようにします。
5. キックオフのスケジュールを示す Accept ブロックの CTA で締めくくります。

結果：インタラクティブな、購入者が選択できる料金表と、承認して署名するための明確な CTA を備えた 5 セクションの Qwilr ページです。Qwilr に貼り付けるか、API 経由で送信するだけで使えます。

例 2：商談初期、空白のページ

ユーザーの発言：「空白の Qwilr ページを前にして途方に暮れています。マーケティングエージェンシーとして、まだベンダーを比較中の e コマーススタートアップに、ブランド刷新を提案します。予算は約 20,000 ドルです。」

スキルの動作：

1. 商談初期と判断し、詳細なスコープよりも課題と解決策を重視した構成にします。
2. 購入者の課題から始め、それぞれの課題を対応する機能に結び付け、解決策は Accordion を使ってざっと把握しやすくする設計図を提案します。
3. 見込み客の言葉遣いに合わせて、エグゼクティブサマリーと「課題と解決策」の文章を作成します。
4. 20,000 ドルの契約とオプションの追加項目 1 つを含むシンプルな Quote ブロックを追加し、続けて Accept ブロックの CTA を配置します。

結果：価格を提示する前に課題を説明する、説得力があり、ざっと目を通しやすい提案の構成と実際の文章です。

例 3：API を使った拡張アップセル付き更新

ユーザーの発言：「更新用の Qwilr API ペイロードを生成してください。基本料金は 3 万ドルで、オプションの拡張モジュールが 3 つあり、それぞれ 5,000 ドルです。会社名は HubSpot から自動入力します。」

スキルの動作：

1. 更新／拡張として扱い、達成した成果を最初に示してから、拡張の範囲を提示します。
2. コピー全体で {{company_name}} と {{contact_first_name}} のトークンプレースホルダーを使用します。
3. 最初に GET /blocks/saved を実行してブロック ID を確認し、その後 isPublished: false を指定した POST /pages ペイロードを作成するように案内します。
4. 見積もりのセクションを設定します。基本の更新項目を 1 つと、それぞれ isOptional: true に設定した拡張モジュール 3 つを含めます。
5. tokens をマッピングし、HubSpot のデータが {{...}} プレースホルダーに挿入されるようにします。

結果：未公開で、トークンによる入力に対応した、拡張アップセルを選択できる更新ページを作成する、すぐに送信可能な JSON ペイロードです（references/qwilr-api-proposals.md を参照）。

トラブルシューティング

生成された提案書が、長文だらけ、または Word 文書のようになる

原因：コピーが Qwilr のブロックタイプに対応付けられず、長い文章のまま作成されているため、プラットフォームの視覚的で Web ベースの形式が反映されていません。

解決策：3 段落を超えるセクションはアコーディオンに再構成するか、サブセクションに分割し、コンテンツを Splash、Text+Image、Quote の各ブロックに割り当てます。セクション数は合計 5～8 を目安とし、入りきらない詳細はディールルーム（/sales-deal-room）に移します。

価格がインタラクティブな見積もりではなく、プレーンテキストとして表示される

原因：Claude は価格をテキストの表として記述することがあり、Qwilr の見積もりブロックという重要な差別化要素を使わない場合があります。

解決策：価格を含む提案はすべて Quote ブロックに移します。項目をセクションごとにまとめ、追加項目には isOptional: true を設定し、席数ごとの価格には quantity の範囲を設定します。また、各項目の請求方法が oneOff か recurring かを指定します。

ページ作成用の API 呼び出しが失敗する、または不明なブロック ID が参照される

原因：利用可能な保存済みブロック ID を事前に確認せずに POST /pages ペイロードを作成しているか、レビューの手順を設けずにすぐ公開しています。

解決策：ペイロードを作成する前に GET /blocks/saved を実行して有効なブロック ID を取得し、送信前にページをレビューできるよう isPublished: false を設定します。また、tokens がコピー内の {{token}} プレースホルダーと一致していることを確認します。フィールドの詳細については references/qwilr-api-proposals.md を参照してください。

特定のプラットフォームスキルを推奨する前に

このスキルは、多くのプラットフォームにまたがる戦略領域を扱います。特定のプラットフォームスキル（## Related skills に記載された /sales-{platform}、例：/sales-mailshake、/sales-klaviyo、/sales-apollo）をユーザーに案内する前に、必ずそのプラットフォームスキルの実際の SKILL.md を読んでください。## Related skills にある 1 行の説明は候補を特定するには十分ですが、そのスキルに決めたり、適切に呼び出すプロンプトを書いたりするには不十分です。

読み方：

• ~/.claude/skills/{skill-name}/SKILL.md がローカルに存在する場合は、Read で読みます。
• sales-* スキルの場合は、このリポジトリから直接 WebFetch で取得します：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md。例：sales-mailshake の場合は https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md。
• sales-* 以外のスキル（サードパーティ製）の場合は、インストール済みであれば ~/.claude/skills/sales-do/references/skill-sources.md で {org}/{repo} を確認し、そのリポジトリ内の同じ skills/{skill-name}/SKILL.md パスから取得します。

読んだ後は、 SKILL.md の具体的な内容（対象範囲、サブフロー、argument-hint の形式、または「Do NOT use for...」という対象外条件）に基づいて推奨してください。生成する呼び出しは、プラットフォームスキルの argument-hint に合わせてください。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、適さないスキルを推奨するのではなく、ここで直接質問に対応してください。

関連スキル

• /sales-proposal-analytics — 送信後のエンゲージメントを追跡します（閲覧者、閲覧されたセクション、フォローアップのタイミング）
• /sales-qwilr-automation — Qwilr API を使って CRM データから提案書の作成を自動化します
• /sales-deal-room — 複数のページが必要な、複数の関係者が関与する複雑な案件向けです
• /sales-proposal-template — チーム全体で使える再利用可能なテンプレートを設計します
• /sales-do — どのスキルを使えばよいかわからない場合は、このルーターがあらゆる営業目標に適したスキルを選びます。インストール：npx skills add sales-skills/sales --skill sales-do