k2f-sales-deck

K2F Sales Deck — AIネイティブな美的デザイン

目的

エージェントに、レイアウトに入る前にセールスデッキの設計図を作成する方法を教えます。1回の商談、1つの案件ステップを対象とし、見込み客を主役に、相手の言葉で課題を語り、成果に結び付いた証拠を示します。ユーザーが提供していないROI、ロゴ、成果を捏造してはいけません。

K2Fを基盤に構築

このスキルは、.K2F パッケージとしてセールスデッキを作成します。作成時はk2fスキルに従い、ワークスペースを展開または初期化し、セマンティックツリーを編集して、パッケージ化・検証・エクスポートを行います。K2Fでは、エージェントは座標ではなく、意味（スライドの役割、ナラティブ、ビジュアルの意図）に集中でき、エンジンがレイアウト、タイポグラフィ、テーマをコンパイルして、エクスポート可能な出力を生成します。

作成を始める前に、コアスキルをインストールします：npx skills add suzheng/k2f --skill k2f。

使用する場面

• 商談メモやCRMの情報をもとに、ディスカバリー、デモ、提案、経営幹部向けブリーフィングのデッキを作成する場合。
• 企業名と購買段階に合わせてテンプレートデッキをパーソナライズする場合。
• 機能の紹介が中心のスライドを、課題–解決策–証拠の流れと明確な次のステップの提案に置き換える場合。

ワークフロー

ステップ1. content_and_design.mdを生成する

セマンティックなコンテンツと美的意図をまとめた単一の設計図を作成します。スライドごとにラベル付きブロック（役割、見出し、本文、ビジュアルの種類）を使用し、後でk2fスキルがマッピングできるようにします。

サブステップ

1. 商談の枠組み — 種類は1つ、目的は1つにします。ディスカバリー、デモ、提案、経営幹部向けブリーフィングのいずれかを選びます。参加者の構成、購買段階、異議、望ましい次のステップを記録します。1つのデッキに複数の商談目的を盛り込んではいけません。

2. 入力の監査 — 検証済みの入力情報を一覧にします。見込み客の名前・背景、相手の言葉で表された課題、対象範囲、価格設定ルール、承認済みの導入事例、製品のスクリーンショット、競合に関する事実を確認します。証拠が不足している場合は NEEDS USER INPUT と明記し、指標、顧客名、ROIを捏造してはいけません。

3. ナラティブの軸 — 商談に合った軸を選びます：

   • 課題–解決策–証拠（デフォルト）：現在の相手の状況 → 自社のアプローチによる望ましい将来像 → なぜ自社なのか（信頼性）。
   • SPIN形式のデモ：状況の振り返り → 明確化された課題 → 現状維持のコスト → 相手のユースケースに結び付いた効果。
   • 経営幹部向けブリーフィング：本日の目的 → 分かったこと → 提案 → 投資・タイムライン → ディスカッション。 見込み客を主役にし、自社製品はガイドとして位置付けます。会社の沿革ではなく、「皆さま」が得られる成果を先に示します。

4. スライド構成（含める／削る） — スライドをナラティブの軸に沿って配置します。一般的な枚数は、ディスカバリーが5～10枚、デモが5～15枚、提案が10～20枚、経営幹部向けが10～15枚です。

   • 基本の流れ：タイトル → アジェンダ（項目は3～5個、最後は次のステップ） → 相手の課題 → アプローチ・成果 → 証拠 → デモ・製品（必要な場合） → 投資・ROI → 双方の次のステップ。
   • 削るもの：冒頭の会社沿革、一般的な「業界最高水準」という主張、機能の網羅的な紹介、重複する課題・解決策のスライド、投資家向けのみの内容（TAM、資本政策表）。
   • 分割するもの：1枚のスライドに2つの要点が含まれる場合（例：課題と提案、または価値の説明なしの価格）。

5. スライドごとのコンテンツ仕様 — 各スライドについて、次の内容を指定します：

   • 見出し：買い手の視点から示したスライドの要点（「当社のプラットフォーム」ではなく「御社に似たチームのオンボーディング時間を40％短縮」）。
   • 本文：箇条書きは最大3～5項目、またはビジュアル1点。比較では並列構造を使います。課題を扱うスライドでは、可能な場合は相手の言葉を引用します。
   • ビジュアルの種類：ワークフロー図、製品画面、ロゴと成果の一覧、ROI比較、タイムライン、双方のアクションプランなど。定量的な効果は、段落に詰め込まず、チャート・コールアウトの意図で示します。
   • 証拠に関する注記：各数値に「測定済み」「ユーザー提供」「未定」のラベルを付けます。導入事例には類似の業界・ユースケースを選び、必要に応じて匿名化します。

6. 対象者に合わせた深さ — 経済的な意思決定者には、成果、ROI、リスク、タイムラインを最初に示します。技術的な意思決定者には、統合・適合性に関するスライド、または付録への案内を用意し、デッキ全体を技術説明にしないようにします。参加者が混在する場合は、スライド数を倍にせず、「経営層の皆さまへ…／チームの皆さまへ…」のように要点を分けます。

7. デザイン意図 — エンジン向け：

   • トーン：相談に乗る姿勢で、信頼感があり、相手に合わせた内容にします。定型的な誇張表現は避け、見込み客のフォーマルさに合わせます。
   • 階層：見出しで要点を示します。裏付けがある場合は、各スライドに主要な指標またはフレーズを1つ配置し、出典は補足脚注に記載します。
   • 情報量：1枚につき1つのアイデアにします。文字ばかりのスライドではなくビジュアルを活用し、アジェンダと次のステップのスライドは要点をすばやく把握できるようにします。
   • 配色：落ち着いたベースカラーを使い、指標と提案内容にはアクセントカラーを1色使用します。画面共有時のコントラストを確保し、ロゴと比較表示のスタイルを統一します。

ルールと制約

• 1回の会議の基準：デッキでは、目的と主要な次のステップをそれぞれ1つだけ扱います。
• パーソナライズの基準：一般的な製品紹介より前に、見込み客の名前、課題、ユースケースを盛り込みます。
• 実績の裏付け基準：ロゴ、成果、ROIには、ユーザーが承認した事実、または明示的なTBDを使用します。実績があったかのように示してはいけません。
• 1アイデアの基準：見出しに「および」が必要なら、分割するか削除します。
• 提案の基準：締めくくりのスライドでは、担当者、日付、明確な質問を示します。「何か質問はありますか？」のように受け身の表現は避けます。

よくある失敗パターン

• ベンダー側の一方的な説明 → 相手の課題から始め、「会社紹介」は信頼感を示す要素を最大1つにします。
• 汎用的、または相手に合わせていないデッキ → タイトル、アジェンダ、「ヒアリング内容」をパーソナライズします。
• 機能紹介に終始するデモ → 主要なユースケースを3つに絞り、ライブデモかスクリーンショットかを明記します。
• 価値を示す前の価格提示、または弱いクロージング → ROIと投資額を併記し、明確な提案を含む双方のアクションプランを作成します。
• 対象者に合わない情報の深さ → 調整するか、ブループリントで付録スライドに印を付けます。

品質チェックリスト

• 会議の種類、単一の目的、目標とする次のステップがブループリントの冒頭に記載されています。
• 解決策や製品のスライドより前に、見込み客固有の課題が示されています。
• すべてのスライドに見出しで示す主張が1つあり、ビジュアルの種類が明記されています。
• 裏付けを示すスライドには出典、承認、またはTBDが記載され、ラベルのない指標はありません。
• アジェンダと最終スライドの内容が一致しています（担当者と日付を含むディスカッションと次のステップ）。
• デザイン意図に、デッキ全体のトーン、主要な強調要素、アクセントカラーの使い方が記載されています。

ステップ 2. content_and_design.md と k2f スキルを使用して K2F ファイルを生成し、適切なファイル形式でエクスポートします。

k2f スキルに従って、ブループリントからスライドを作成し、デザイン意図に基づいて役割を適用し、検証して、会議ですぐに使える成果物をエクスポートします。