sales-script について
sales-scriptは、ディスカバリーコール、デモ、RFP/RFI対応、競合分析、POC、反論対応、クロージングを準備する営業向けスキルです。製品、見込み客、商談の情報から、構成済みの台本や分析、計画を作成し、担当者別のトークや要件カバレッジ評価にも対応します。
主な機能
- 01ディスカバリーコールとデモの台本
- 02RFP/RFI要件のカバレッジ分析
- 03競合比較マトリクス
- 04POCの範囲と成功基準
- 05反論対応とクロージング計画
活用シーン
- 01関係者別の製品デモ準備
- 02RFPの要件カバレッジと不足の評価
- 03成功基準を含むPOC計画の策定
- 04営業上の反論への対応準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ shawnpang/ startup-founder-skills --skill sales-scriptインストール後、Claude Code で/sales-scriptを入力して読み込まれたか確認します。
詳細
営業スクリプト
使用する場面
- ディスカバリーコール、製品デモ、またはクロージングミーティングの準備
- RFP/RFIへの回答にあたり、要件のカバレッジ不足を分析する
- 競合他社との機能比較表を作成する
- 概念実証(POC)の進め方を計画または評価する
- 関係者ごとの説明ポイントを盛り込んだ、技術デモのスクリプトを準備する
- 異議への対応や、受注・失注分析を行う
必要なコンテキスト
startup-context またはユーザーから取得します。
- 製品/サービス — 販売するもの、対象顧客、主な機能
- ターゲットペルソナ — 役職、職位、一般的な課題
- 商談の状況 — 段階、商談規模、関係者、把握している異議
- 競合状況 — 顧客が比較検討している他社、自社の差別化要因
- 実績 — 指標、導入事例、顧客の声
- RFP/RFIの詳細 — 正式な依頼への回答の場合、要件のカテゴリと優先度
ワークフロー
フェーズ 1:ディスカバリーと調査
- コンテキストを収集する —
startup-contextを読み込みます。必要なスクリプトの種類(ディスカバリーコール、デモ、RFPへの回答、競合分析、POC計画)を特定します。 - 顧客の要件を整理する — 見込み顧客の現在のアーキテクチャ、課題、統合要件、セキュリティ/コンプライアンスのニーズ、ビジネス上の推進要因を記録します。
- 競合状況を評価する — 商談に関係する競合他社を特定します。自社製品の機能を競合製品と照らし合わせ、差別化要因と弱点を見つけます。
- 要件の充足度を評価する — RFP/RFIへの回答では、各要件を「完全(100%)」「一部(50%)」「計画中(25%)」「未対応(0%)」に分類します。優先度に応じて重み付けします。「必須」は3倍、「望ましい」は2倍、「あるとよい」は1倍です。
フェーズ 2:ソリューション設計とポジショニング
- 課題を価値に結び付ける — 見込み顧客の各課題を、具体的な製品機能とその実績(指標、導入事例)に結び付けます。
- 競合との差別化を明確にする — 顧客の優先事項ごとに、少なくとも1つの強力な差別化要因を特定します。該当するものがない場合は、製品チームへのエスカレーションが必要であることを明示します。
- 説明の流れを設計する — 自社の機能一覧ではなく、顧客の優先事項を軸に会話や資料を構成します。
フェーズ 3:スクリプトとデモの準備
- スクリプトを作成する — 所要時間、説明内容、質問、話題の切り替え、関係者ごとの説明ポイントを含む完全なスクリプトを作成します。
- 異議への対応を準備する — 想定される異議を洗い出し、LAERモデルを使って回答の枠組みを作成します。
- デモ環境を構築する — デモ前チェックリストを作成します。環境のテスト、サンプルデータの読み込み、バックアップ環境の準備、顧客固有のブランディングの適用を含めます。
フェーズ 4:POCとクロージング(該当する場合)
- POCの範囲を定義する — 成功基準、期間(通常5週間)、段階的なテスト計画を設定します。機能、パフォーマンス、統合、使いやすさ、サポートの観点で評価します。進行を推奨するには、達成率が60%を超えることを条件とします。
- 商談を成立させる — POCの結果、デモのフィードバック、競合に対するポジショニングをまとめます。商談の段階に適したクロージング手法を適用します。
出力形式
依頼に合った形式で提供します。ディスカバリーコール用スクリプト(SPINの各段階に応じた質問、適格性の判断基準、次のステップの提示)、デモ用スクリプト(シーンごとの進行、所要時間、役職ごとの説明内容、デモ前チェックリスト、異議対応表)、RFP回答分析(充足度スコア、未対応項目数、入札/見送りの推奨)、競合比較表(重み付けスコア付きの機能比較、差別化要因、弱点)、POC計画(段階的なスケジュール、成功基準、評価表)、異議対応ドキュメント(異議、懸念、回答、根拠、フォローアップの表)、またはクロージングプレイブック(意思決定基準、手法、スケジュール)。
フレームワークとベストプラクティス
ディスカバリーコールのフレームワーク(30分)
| フェーズ | 所要時間 | 実施内容 |
|---|---|---|
| 信頼関係の構築とアジェンダ | 3分 | アジェンダを設定し、所要時間を確認して、手短に信頼関係を築きます |
| 現状に関する質問 | 7分 | 現在の状況とワークフローを把握します |
| 課題に関する質問 | 8分 | 問題点、その発生頻度、影響を掘り下げます |
| 影響に関する質問 | 5分 | 問題を解決しない場合のコストを検討します |
| 解決による価値に関する質問 | 4分 | ソリューションの価値を相手自身に説明してもらいます |
| 次のステップ | 3分 | 要点をまとめ、適合性を確認して、デモの日程を設定します |
デモの進行構成
デモ前のチェックリスト: 環境のテスト、サンプルデータの読み込み、バックアップ環境の準備、画面共有のテスト、ブラウザーのタブの事前読み込み、ネットワーク/VPN の確認、顧客のブランド要素の適用。
参加者の把握: 参加者ごとに、役職、評価における役割(意思決定者/推進者/技術評価担当者/エンドユーザー)、主な関心分野を記録します。
| セグメント | 所要時間 | 内容 |
|---|---|---|
| オープニング | 5分 | 参加者にお礼を伝え、ディスカバリーで得た知見を振り返り、アジェンダを設定します |
| ユースケース1 | 7分 | ビジネス上の背景と差別化要素を交えながら、主な問題点に対応するデモを行います |
| 確認 | 2分 | 「現在の対応方法と比べて、いかがですか?」 |
| ユースケース2 | 7分 | 二番目の問題点に対応するデモを行います |
| ユースケース3 | 6分 | 相手が予想していなかった差別化要素や魅力的な機能を紹介します |
| インテグレーションのデモ | 10分 | コネクターの設定、データフロー、エンドツーエンドのワークフローを紹介します |
| 管理とセキュリティ | 5分 | RBAC、監査ログ、SSO |
| 質疑応答 | 5分 | その場で寄せられる質問に対応します |
| クロージング | 5分 | 価値をまとめ、具体的な日付を挙げて次のステップを提案します |
デモの原則: デモはディスカバリーの後に行い、決して先に行わないでください。相手の用語やデータを使います。質問のための時間を確保します。その機能を開発した理由を共有します。機能を順に紹介するより、開発にまつわるストーリーのほうが心に響きます。
RFP の入札/見送りフレームワーク
- 入札: カバー率 >70% かつ必須要件の不足 <=3
- 条件付き入札: カバー率 50-70% または必須要件の不足 2-3
- 見送り: カバー率 <50% または必須要件の不足 >3
反論への対応(LAER モデル)
- 傾聴する — 相手が話し終えるまで待ちます。遮ったり、防御的になったりしないでください。
- 受け止める — 「おっしゃることは分かります」または「よく耳にします」と伝えます。
- 掘り下げる — 本当の懸念を理解するため、追加の質問をします。
- 回答する — 根拠を示して本当の懸念に対処し、その後、理解を確認します。
| カテゴリ | 反論の例 | 対応方針 |
|---|---|---|
| 価格 | 「高すぎます」 | ROI の観点から捉え直します。「これを解決しない場合、どのようなコストがかかりますか?」 |
| タイミング | 「今は適切な時期ではありません」 | 本当の障壁を明らかにします。「何が変わればよいでしょうか?」 |
| 競合 | 「すでに X を使っています」 | 相手固有の問題点に対する優位性を示します |
| 決裁権 | 「上司に確認する必要があります」 | 推進者が必要とする資料を用意します |
| 現状維持 | 「今使っているもので問題ありません」 | 表面化していないコストを数値化します。同業者の事例を共有します。 |
| 信頼 | 「規模が小さすぎます」 | 顧客、指標、投資家、チームなどの実績を示します |
デモのリカバリー
デモが動かなくなった場合:バックアップに切り替え、相手が本来見られるはずだった内容を説明し、録画を後日共有します。質問で進行が逸れた場合:受け止めて、フォローアップ事項として記録し、台本に戻ります。参加者の関心が薄れた場合:いったん止めて「必要な内容をお伝えできていますか?」と尋ね、最も関連性の高いセクションに進みます。
創業者向けクロージング手法
- 要約クロージング: 「[課題] によって [金額] のコストが発生しており、当社のソリューションは [ニーズ] に対応すると合意しました。前に進むには何が必要でしょうか?」
- タイムライン・クロージング: 「Q3 までに解決したいとのことですね。逆算すると、[日付] までに開始する必要があります。」
- パイロット・クロージング: 「[ユースケース] に絞ったパイロットから始め、価値を実証してから、そこを起点に拡大しましょう。」
- 創業者クロージング: 「オンボーディングが順調に進むよう、私が責任を持って対応します。30日間、私が直接サポートします。」
デモ後のアクション
24時間以内に録画を添えてお礼のメールを送信します。デモ環境へのアクセスを共有します。未回答の質問に対応するフォローアップを送信します。次回のミーティングを設定します。デモのメモと次のステップをCRMに記録します。バトルカードの更新に向けて、異議を記録します。
関連スキル
cold-outreach— これらの営業会話につながるミーティングの創出に使用しますproposal-generation— デモが成功した後、正式な提案書、SOW、または契約書の作成に使用します
例
プロンプト:「明日、フィンテック企業のエンジニアリング責任者にデモを行います。デプロイの失敗を減らすことに関心があります。」
デモの適切な開始例:
「お時間をいただきありがとうございます、[Name]さん。先週、チームではスプリントごとに約8時間をデプロイの失敗やロールバックへの対応に費やしているとおっしゃっていました。最大の悩みは、リリースの速度が落ち、チームの不満につながることだと伺いました。今も最優先事項でしょうか。それとも何か変わりましたか?
ありがとうございます。デプロイの信頼性向上に役立つ、具体的なワークフローを3つご紹介します。質疑応答の時間を含めて約25分です。よろしいでしょうか?
まず、[Similar Fintech Customer]が当社に切り替える前にどのように対応していたかをご紹介します……」
プロンプト:「大手企業からRFPが届きました。入札すべきでしょうか?」
出力例:
RFP Coverage Analysis:
- Overall coverage score: 68% (Conditional Bid range)
- Must-have gaps: 2 (within threshold)
- Recommendation: CONDITIONAL BID
Action items before proceeding:
1. Confirm planned roadmap items cover the 2 must-have gaps
2. Build differentiator narrative around your 3 strongest categories
3. Flag gaps to product team for timeline confirmation