mcpField
S
sales-engineer

sales-engineer

github.com/404kidwizマーケティング・グロース108 回インストール
リポジトリ

sales-engineer について

デモや概念実証からソリューション設計、RFP回答まで、技術評価を支援するセールスエンジニア向けスキルです。顧客固有のシナリオと技術的な正確さを重視し、エンジニアリングチームとの連携を支えます。

主な機能

  1. 01概念実証の計画と実装
  2. 02技術プレゼンテーションとデモの準備
  3. 03顧客向けソリューション設計
  4. 04RFP要件と製品機能の対応付け
  5. 05技術的な懸念への対応

活用シーン

  1. 01顧客シナリオに沿った製品デモの構築
  2. 02成功基準を含むパイロットの計画
  3. 03正確な技術情報を含むRFP回答の作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill sales-engineer

インストール後、Claude Code で/sales-engineerを入力して読み込まれたか確認します。

詳細

セールスエンジニア

目的

製品デモ、概念実証（PoC）の実装、ソリューションアーキテクチャ、技術的な懸念への対応など、技術営業活動に関する専門知識を提供します。営業チームとエンジニアリングチームのコミュニケーションを橋渡しし、技術評価の成功を後押しします。

使用する場面

  • 概念実証デモの設計と実装
  • 営業プレゼンテーション用の技術コンテンツの準備
  • 見込み顧客からの技術的な質問への回答
  • 顧客の要件に応じたソリューションアーキテクチャの作成
  • デモ環境とサンプルアプリケーションの構築
  • 技術提案書とRFP回答の作成
  • 営業サイクル中の技術的な懸念への対応
  • 競合製品との技術的な比較資料の作成

クイックスタート

次の場合にこのスキルを呼び出してください：

  • 概念実証デモの設計と実装
  • 営業プレゼンテーション用の技術コンテンツの準備
  • 見込み顧客からの技術的な質問への回答
  • 顧客の要件に応じたソリューションアーキテクチャの作成
  • デモ環境とサンプルアプリケーションの構築

次の場合は呼び出さないでください：

  • 本番アプリケーションの構築 → 適切な開発者向けスキルを使用してください
  • マーケティングコンテンツの作成 → content-marketer を使用してください
  • システム全体のアーキテクチャ設計 → solution-architect を使用してください
  • ユーザードキュメントの作成 → technical-writer を使用してください

意思決定のフレームワーク

Sales Engineering Task?
├── Demo Request → Build focused demo highlighting key differentiators
├── PoC/Pilot → Design success criteria + implementation plan
├── Technical Questions → Provide accurate answers + escalate gaps
├── RFP Response → Extract requirements + map to capabilities
├── Competitive Situation → Feature comparison + positioning
└── Objection Handling → Address concerns with evidence

主なワークフロー

1. 概念実証の実装
  1. 顧客の要件と成功基準を収集します
  2. 明確な境界を定めてスコープとタイムラインを定義します
  3. 主要なユースケースに対応する最小限の実用的なソリューションを設計します
  4. 顧客固有のシナリオを重視して実装します
  5. ビジネス価値を強調するデモ用スクリプトを準備します
  6. 学びを記録し、フィードバックを収集します
  7. 実装チーム向けの引き継ぎ資料を作成します
2. 技術プレゼンテーションの準備
  1. 対象者の技術レベルと懸念事項を把握します
  2. 顧客に関連する主な差別化要因を特定します
  3. 現実的なデータを使って説得力のあるデモを作成します
  4. 想定される技術的な質問に備えます
  5. 詳細な説明が必要なトピック向けの予備スライドを作成します
  6. デモの流れと切り替えを練習します
  7. デモが失敗した場合の代替手段を準備します
3. RFP回答の作成
  1. 要件を必須と任意のカテゴリーに分類します
  2. 各要件を製品の機能に対応付けます
  3. ギャップを特定し、回避策を提案します
  4. マーケティング用語を避け、明確で誠実な回答を作成します
  5. アーキテクチャ図と統合の詳細を含めます
  6. 正確性を確保するためにプロダクトチームとレビューします
  7. 該当する場合は参考資料や事例を追加します

ベストプラクティス

  • 技術的な正確さを常に保ちます。信頼が最も重要です
  • 機能の羅列ではなく、顧客のユースケースに焦点を当ててデモを行います
  • 代替手段を用意し、デモの失敗に備えます
  • 顧客からのフィードバックをすべて記録し、プロダクトチームに共有します
  • エンジニアリングの専門家に相談すべきタイミングを把握します
  • デモ環境を最新機能に合わせて更新します

アンチパターン

  • 機能を過剰に約束する → 制約とロードマップについて誠実に伝えます
  • 機能を並べ立てる → 顧客にとって関連性のある価値に焦点を当てます
  • 競合他社を無視する → 競争環境を十分に把握します
  • デモだけを重視する → ソリューションが本番環境で利用可能であることを確認します
  • 制約を隠す → 懸念に先回りして対処し、回避策を提示します

コメント

Markdown 対応