event-sponsor-outreach

イベントスポンサーへの営業

スポンサーに提供する価値を定めてからスポンサーとの契約を締結するまでのすべてを、主に1日または複数日にわたるカンファレンスを対象に、あなたが進めます。3つの関連スキルから入力を受け取り、契約締結、または記録された見送りという結果を出します。

• 主張 - samber/dev-event-organizer-skills@event-sponsor-value-proposition。
• 資料 - samber/dev-event-organizer-skills@event-sponsor-prospectus。
• 料金表 - samber/dev-event-organizer-skills@event-sponsor-pricing。
• 成果 - 締結済みの契約を samber/dev-event-organizer-skills@event-sponsor-agreement に引き継ぐか、見送りを記録します。

スポンサーは、自力ではイベントの価値を把握できないことがよくあります。そのため、見込み客との最初の本格的な会話では、売り込みではなくニーズの把握が重要です。パートナーが何を必要としているのかを見つけ、そのニーズにイベントが本当に応えられるかを確かめます。このスポンサーとイベントの適合性こそが営業の本質です。それを確かめる前にパッケージを提示しても、推測にすぎません。

この一連の活動を左右するタイミングの事実が1つあります。スポンサーへの案内資料の送付は、イベントの約8か月前に行うのが適切です。スポンサー、とりわけ大企業は、前年の会計年度中に予算を確保するためです（DevOpsDays 主催ガイド）。案内は計画において最初の対外的な活動であり、CFP や参加者向けマーケティングよりも先に行います。プログラムの完成を待っていると、すでに使われた予算をめぐって競争することになります。

以下の各順位（ターゲットリストの情報源、最初の連絡手段、フォローアップの間隔）は、決まりではなく標準的な目安です。状況や担当者によって変わります。インタビュー後、主催者についてすでに把握していることを踏まえて、3つの選択肢をすべて見直し、順位を付け直してください。以下のいずれかに当てはまる場合、標準的な順位は覆ります。

• 過去の開催回でスポンサーを務めたものの、現在は離れている、または解除されたスポンサーの一覧がある。
• 主催者がターゲット企業で働いている。
• 初開催で、スポンサー一覧がまったくない。
• ボランティアではなく、有給のイベントチームがいる。

インタビュー

一度に1つずつ質問し、可能であれば選択式にします。質問6〜8があるのは、以下のメニューが効果が出るまでの時間と労力で大きく異なるためです。デフォルトの順位はユーザーに代わって選べません。

1. イベントはどちらの立場にありますか。コミュニティ運営（独立したボランティア主導の運営者が企画し、スポンサーは費用回収のために参加）ですか、それとも企業／財団運営（ベンダーが所有し、マーケティング予算を持ち、スポンサーは見込み顧客の獲得経路として参加）ですか。この回答によって、利用できる温かいチャネルと、電話で誠実に約束できる内容が決まります。
2. すでにある資料は何ですか。セグメントごとの価値提案、プロスペクタス、料金表はありますか。プログラムには実際にどのようなスポンサー向けの活動が含まれていますか（採用コーナー、実践的なフィードバックセッション、参加希望者向けのデモスペース、それとも講演のみですか）。最初の接触と情報収集の電話は、プロスペクタスを送る前に行います（MLH の主催者向けガイド）。そのため、資料なしで始めます。提案の段階ではパッケージと価格が必要なので、その段階に進む前に、必要な資料がなければ上記の関連項目に誘導してください。アウトリーチでは、プログラムにすでに含まれている活動だけを提案します。講演のみのプログラムは、ビジネス向けの要素があるプログラムよりスポンサーへの説得力が弱く、その要素の追加は営業電話ではなく、samber/dev-event-organizer-skills@event-positioning と samber/dev-event-organizer-skills@business-event-formats の担当です。
3. 昨年のスポンサーを数に入れた場合、収益目標のうち新規開拓で賄う必要があるのはどの程度ですか。昨年のスポンサーは samber/dev-event-organizer-skills@event-sponsor-renewal の対象です（「既存スポンサー」を参照）。
4. イベントの開催日はどれくらい先ですか。また、主要なターゲットは翌年の予算をいつ決めますか。開催まで8か月を切っている場合、会計年度の予算編成期間はすでに終わりに近づいています。その点を明示し、予算サイクルがまだ進行中のターゲットを優先してください。
5. スポンサー収益の目標額と、パッケージの平均価格はいくらですか。これらをもとに、逆算してターゲットリストを作成します（references/pipeline-and-renewal.md を参照）。その計算で使う成約率と返信率は、自分で設定する仮定値であり、ベンチマークではありません。
6. スポンサー収益を確定する必要がある期限はいつですか。（期限が近い場合は、どこでも最も早く成約につながる温かい段階を優先し、時間のかかるインバウンドは補助的な手段に限定します。）
7. 各スポンサーとの関係は単発の販売ですか、それとも複数回の開催を通じて積み上げる関係ですか。（継続的な関係が求められる場合は、専任の連絡担当者を置く慣行と、翌年のリストを作る隣接イベントの調査を優先します。）
8. 労力の上限はどの程度ですか。週に数時間取り組めるボランティアの主催者ですか、それとも専任のスポンサーシップ担当者ですか。（この回答だけで、取り組みの頻度メニューが決まります。）
9. このイベントは、シリーズの他都市開催や同一フランチャイズのイベントに属していますか。

コミュニティ運営と企業運営

営業の進め方を変える軸は、誰がイベントを所有しているかです。これは samber/dev-event-organizer-skills@event-first-edition、samber/dev-event-organizer-skills@event-format-selection、samber/dev-event-organizer-skills@event-sponsor-value-proposition が論じているのと同じ区分です。

• コミュニティ運営 - 最も有力な温かいチャネルは、構造上の強みから生まれます。コミュニティイベントのネットワークにいる主催者の多くは、自身がスポンサー企業で働いています（「Slack でほかの主催者に声をかけましょう。スポンサー企業で働いている人がたくさんいます！」、DevOpsDays ガイド）。ボランティアが進行を担うため、頻度を抑えたスケジュールと厳格なフォローアップ上限が適しています。参加者リストや購入可能な講演枠、その他イベントの構造上提供できないものを電話で約束してはいけません。これは samber/dev-event-organizer-skills@event-sponsor-value-proposition が担う誠実さの条件です。スポンサーが購入するのは、条件に合ったオーディエンスへのアクセスです。参加者が自ら選ぶイベントへの参加と対話であり、連絡先データではありません。
• 企業／財団運営 - 見込み顧客の獲得につながるという約束も誠実に提示でき、通常は有給のイベント担当またはフィールドマーケティングチームが進行を担います。そのため、労力の大きい段階（完全なコールドシーケンスや、より踏み込んだパーソナライズ）が適しています。公開されている主催者向けガイダンスはコミュニティ運営を想定して書かれています。企業運営に関する調整は、確立された慣行ではなく、妥当性を判断したうえで扱ってください。

ワークフロー

1. インタビューを実施します。目標額を定め（Q1）、前回のスポンサー収入を差し引き（Q3）、収益目標から逆算して候補リストの規模を決めます（Q5）。
2. 以下のターゲットリストのメニューを使って候補リストを作成します。適格性審査で大きく絞り込まれるため、必要なスポンサー数の2〜3倍の候補を集めます。これはリード獲得における経験則であり、スポンサー獲得のベンチマークではありません。特定のセグメントに集中せず、スタートアップ、中堅企業、大企業に分散させます（MLH ガイド）。
3. 各候補を Hot／Warm／Cold／Skip で評価し、各主張に出典 URL と日付を付けます。公開されているビジネス上の連絡手段のみを使います（詳細は references/pipeline-and-renewal.md を参照）。
4. より冷たい接触を行う前に、各ターゲットについてウォームパスを確認します。運営チームやコミュニティのネットワークに、ターゲットに勤務している人や、ターゲットの誰かを知っている人はいないでしょうか。MLH と DevOpsDays の運営者向けガイドはいずれも、個人的なつながりやコミュニティのネットワークを最優先しています。
5. 最初の連絡には、以下のチャネルメニューを使います。コールドメールでは、スポンサー向けのエチケットを守ります。最初のメールにはリンク、添付ファイル、画像を入れないでください。企業のフィッシング対策フィルターによって自動的に破棄されます（MLH ガイド。詳細な手法は references/outreach-process-and-email-craft.md を参照）。
6. プロスペクタスを送る前の探索的な通話は、ニーズを把握するための会話として行います。イベントとチームについて手短に紹介したら、スポンサーに話してもらいましょう。このパートナーがイベントに何を求めているか（雇用主ブランドの向上や採用、参加者への販売、製品へのフィードバック、ブランド認知、コミュニティへの貢献など）を尋ね、その回答を新しい分類体系ではなく、samber/dev-event-organizer-skills@event-sponsor-value-proposition の価値カテゴリ（同スキルの発見質問、Q3）に当てはめます。過去のスポンサー活動でどのような成功指標を使い、いくら支出したかを尋ねます。イベントが誠実に提供できないニーズには、無理にパッケージを当てはめず、丁重にお断りします。会話を進めながら、権限、ニーズ、緊急性、予算を確認します（通話スクリプトと ANUM による適格性確認の補足については references/outreach-process-and-email-craft.md を参照）。電話を切る前に、フォローアップの通話を予定します（MLH ガイド）。
7. 通話の直後に提案書を送ります。標準のプロスペクタスを使い、最も関連性の高いパッケージを強調するか、既存の階層が合わない場合はカスタム提案書を作成します。通話で把握したニーズに合う理由を説明し、プログラムに実際に含まれる活動のみを記載し（Q2）、期限を設定します（MLH ガイド）。
8. 上限を守りながら、以下のフォローアップ頻度メニューに従います。配信停止の申し出があれば、次回の予定連絡を待たず、シーケンスの途中であっても直ちに対応します。
9. すべての見込み顧客をパイプラインで管理します（CRM、メールフォローアップツール、スプレッドシートのいずれでも構いません。MLH ガイド）。各スポンサーとの関係には専任の窓口担当者を割り当てます（DevOpsDays ガイド）。反論はすべてスポンサーのセグメント別に記録し、その記録を samber/dev-event-organizer-skills@event-sponsor-value-proposition にフィードバックします。クロージングの段階そのものも、購入される特典だけでなく取引額に応じて判断します。少額の協賛には署名だけで十分です。最上位の協賛には、確定前に運営チーム内で価値観との整合性を確認します。承諾を得たら：
   • 直ちに請求書を発行します。
   • 金額と支払い方法を書面で確認します。
   • 受取口座が利用できることを確認します。
   • samber/dev-event-organizer-skills@event-sponsor-agreement に引き継ぎます（契約締結の詳細は references/pipeline-and-renewal.md を参照）。
10. 前回のスポンサーは samber/dev-event-organizer-skills@event-sponsor-renewal に任せます。そこから引き継いだスポンサーのみを担当します（「継続スポンサー」を参照）。

ハーネスに永続メモリがある場合は、以下を記録します。

• 各主張の出典を含む、評価済みターゲットリスト。
• スポンサーごとのパイプライン段階と窓口担当者。
• セグメント別の反論記録。

次回のアウトリーチは、白紙のリストではなく、この記録を起点にします。

ターゲットリストの情報源

候補がどこから得られるか。順位（デフォルトであり、絶対ではありません。Q3 と初回開催時の順位は異なります）：

• 労力：参加者の技術スタックに基づくベンダーのマッピング > 隣接イベントのスポンサー調査 > 機関のチャネル > 運営者ネットワーク上の勤務先 == 過去のスポンサー一覧
• 価値（リードの成約可能性）：過去のスポンサー一覧 > 運営者ネットワーク上の勤務先 > 隣接イベントのスポンサー調査 > 参加者の技術スタックに基づくベンダーのマッピング > 機関のチャネル
• 効率：過去のスポンサー一覧 > 運営者ネットワーク上の勤務先 > 隣接イベントのスポンサー調査 > 機関のチャネル > 参加者の技術スタックに基づくベンダーのマッピング

労力の同順位には理由があります。過去のスポンサー一覧と運営者ネットワーク上の勤務先リストは、どちらもチームがすでに保有している記録です。過去の開催回のスポンサー一覧と、運営者自身の勤務先や連絡先がそれに当たります。どちらも、すでにわかっていることを書き出すだけで午後の作業が終わり、調査の手順はありません。

• 過去のスポンサー一覧 - デフォルトで最初に使う情報源です。このイベントの過去の開催回で、契約が終了した、または契約を解除されたスポンサー（直近の開催回のスポンサーは更新スキルの対象です）と、同じシリーズの他のイベント、特に地域のイベントのスポンサーが対象です（MLH ガイド）。これらのリードは、まさにこの商品をすでに一度購入しています。
• 運営者ネットワーク上の勤務先 - コミュニティの運営者を中心とする、構造的に温かいチャネルです（DevOpsDays ガイド）。LinkedIn で確認できる個人的なつながりも含みます（MLH ガイド）。
• 隣接イベントのスポンサー調査 - 同じ技術分野の近隣イベントにスポンサーとして参加している企業です。公開されているスポンサー一覧は、予算、動機、適合性を示す公的な根拠になります。このチャネルは、確立された運営者の慣行を繰り返すのではなく、エコシステムの隣接性に基づく適合性の考え方を広げるものなので、判断を要するものとして扱ってください。
• 機関のチャネル - 大学のキャリアサービス（技術系就職フェアにスポンサーを募るところ）や、コミュニティの資金調達に関する告知です（MLH ガイド）。主に採用を目的とする購入者です。
• 参加者の技術スタックに基づくベンダーのマッピング - 後回しにされがちな選択肢です。想定される参加者がどのベンダーのツールを使っているか、または評価しているかを調べ、そのベンダーの DevRel チームとマーケティングチームをターゲットにします。調査の労力が最も大きく、適合性は高いため、効率の観点では最初に選ばれることはありません。優先する条件：温かいリストを使い切っても収益目標を達成できていない場合、またはリストに買い手のセグメント全体（通常は製品フィードバックを目的とする購入者）が含まれていない場合です。

初回開催時の順位：過去のスポンサー一覧はありません。Q9 に基づく：イベントがフランチャイズに属する場合は、同じシリーズや地域の開催回の一覧で代用し、運営者ネットワークのリストをデフォルトにします。

最初の接点チャネル

ターゲットごとの最初の接点です。順位はデフォルトであり、絶対ではありません。Q6 と Q8 によって順位は変わります。

• 労力（予約できた面談あたり）：コールドメールのシーケンス > インバウンド配信 > 紹介依頼 > ウォームイントロ
• 価値（試行あたりの予約面談数）：ウォームイントロ > 紹介依頼 > コールドメールのシーケンス > インバウンド配信
• 効率：ウォームイントロ > 紹介依頼 > インバウンド配信 > コールドメールのシーケンス
• コンプライアンスコスト（発生するレビューと、取り消せる範囲の狭さ）：コールドメールのシーケンス > 紹介依頼 > ウォームイントロ == インバウンド配信

コンプライアンスコストが同じという点には異論があります。ウォームイントロは、すでに関係を築いている人を介して進みます。一方、インバウンド配信は誰にも直接連絡しない公開コンテンツです。どちらも見込み客が自ら提供する情報を超えて個人データを処理しないため、レビューは発生しません。コールドメールと紹介依頼は、名前を特定したビジネス関係者への未承諾の直接的な働きかけであり、同意や電子マーケティング法（GDPR、CAN-SPAM など）の対象となります。

どちらの場合も、以下を守ります。

• すべての連絡について、情報源の URL と日付を記録します。
• 公開されているビジネス向けの連絡チャネルのみを使用します。
• オプトアウトにはシーケンスの途中であっても直ちに応じます。無視したオプトアウトは取り消せません。

紹介依頼のコンプライアンスコストは、コールドメールのシーケンスより低くなります。シーケンスではなく、売り込みを含まない単発のメッセージだからです。

• ウォームイントロ - デフォルトの方法です。主催者またはコミュニティメンバーが、ターゲット組織内に知り合いがいれば紹介します。紹介経路があれば、労力はほぼゼロです。より距離のある方法を使う前に、ターゲットごとにこの方法を使い切ります。
• 紹介依頼 - 直接の紹介経路がない場合に使います。ターゲット組織の有力者、つまり意思決定者と考えられる人より上の立場の人にメールし、「X のスポンサーについて話すには、どなたに連絡すればよいでしょうか？」とだけ尋ねます。そのメールでは売り込みをしません（B2B セールスにおける Cold Calling 2.0 の紹介パターンです）。転送された紹介は、最初の接点がコールドであってもウォームイントロとして機能します。MLH ガイドの「迷ったら CEO にメールする」を、当て推量から体系的な依頼へと変える方法です。コールドピッチよりも返信率が数倍高いという優位性は、B2B SaaS セールスのベンチマークであり、スポンサー獲得に関するものではありません。
• インバウンド配信 - イベントの公式サイトにスポンサー募集のブログ記事を掲載し、ソーシャルメディアに投稿します（どちらも DevOpsDays の名前を冠したチャネルです）。市場全体に一度に働きかけられ、継続的な労力はほぼゼロですが、成果は少なく、予測できません。常に実施しますが、これだけを計画の柱にはしません。
• コールドメールのシーケンス - 優先度の低い選択肢です。名前を特定した意思決定者に、個別に最適化した複数回の連絡を行います。労力が最も大きいため、効率性で選ばれることはありません。しかし、コミュニティのネットワークでは届かないターゲットに連絡できる唯一のチャネルです。採用する条件は、収益目標の達成に必要なスポンサー数がウォームな紹介経路から得られる数を上回る場合、または主催者のネットワークがまだない都市で初開催する場合です。
• 降格ではなく除外：購入またはスクレイピングした連絡先リスト。 公開されているビジネス向けの連絡チャネルのみを使います。これは営業の見込み客開拓にも適用される同じコンプライアンスルールです。購入リストは、このメニューの最下位に置く最後の手段ではありません。対象外です。

スポンサーの動機（製品フィードバックなら DevRel、採用なら人事、ブランドならマーケティング／PR）に応じた役職の選定については、references/outreach-process-and-email-craft.md を参照してください。

フォローアップの頻度

最初の連絡または提案の後、何回、どのくらいの間隔で連絡するか。順位（デフォルトであり、絶対的なルールではありません。この選択肢はほぼ Q8 だけで決まります）：

• 労力：角度を変えるシーケンス > スポンサー標準の頻度
• 価値（返信のない状態から取り戻せる返信）：角度を変えるシーケンス > スポンサー標準の頻度 - この順位付けの根拠となる、複数回の連絡による返信率の向上は、B2B SaaS 営業のベンチマークであり、スポンサーシップの数値ではありません。
• 効率：スポンサー標準の頻度 > 角度を変えるシーケンス

優越性チェック：2 つの段階、1 組の比較、厳密な優越関係はゼロ、構成上のみ問題なし。ただし、構成上問題がないことは決して合格を意味しません。

価値と労力の順位が同じなので、唯一の比較はコスト面で不合格です。角度を変えるシーケンスはより多くの返信を取り戻しますが、作成と運用により多くの労力がかかります。2 段階の選択肢にはほかに確認するものがなく、3 つ目の軸も示されていません。効率性の判断は、チェックに合格した結果ではなく、以下の論拠に基づいています。

• スポンサー標準の頻度 - デフォルト：

  • 連絡の間隔は 1～2 週間空けます。
  • フォローアップは最大 3 回までです。
  • イベント開催日が近づいたら、間隔を 3～4 日に短縮します（MLH ガイド）。

  これは、営業から借用したものではなく、スポンサーシップ向けに公開された唯一の頻度です。ボランティアの主催者が対応できる範囲と、終了日が決まっている資金調達期間に合わせています。一般的なフォローアップではなく、実際の終了期限が必要な場合は、最終リマインダーを、カレンダーにすでに登録されている、制作に関わる明確で別個の期日に結び付けてください。たとえば、グッズの印刷締切やプログラムの確定日などです。スポンサーが実在すると確認できる期限は、根拠のない終了日を提示するよりも説得力があります。

• 角度を変えるシーケンス - ほとんど使われない選択肢：間隔を徐々に広げながら 4 回フォローアップし、そのたびに本当に新しい切り口（統計、事例、知見）を加えます。最後は、返信がないことに触れ、最後の価値ある情報を 1 つ提示する終了メールです。価値は高いものの、労力も大きいため、効率の面で選ばれることはありません。

  B2B SaaS 営業から借用したものです。これに関連付けられているすべての数値（返信率の向上、終了メールへの返信率）が測定されていますが、スポンサーシップの数値ではありません。

  採用の条件は次の 3 つすべてです。

  • 専任のスポンサーシップ担当者がいる（Q8）。
  • 新規の連絡先リストが大規模である。
  • デフォルトの上限まで実施しても、なお収益目標に届かない。

• **降格ではなく削除：「返信があるまで『念のためご連絡しました』と繰り返すフォローアップ」。**新しい切り口が加わりません。B2B SaaS 営業のデータによると、上限を超えると成果が急減し、スパム報告が増加します（営業のベンチマークであり、スポンサーシップのものではありません）。メンバー同士が話をするコミュニティでは、イベントの評判を損ねます。その評判は、次回開催に向けた連絡では取り戻せません。

反論への対応

連絡中ではなく、その前に準備します。スポンサーからよく聞かれる質問への回答を、あらかじめ用意しておきましょう。

• 予想される参加者数。
• 参加者全体の構成。
• 各レベルの特典。
• 運営上の詳細。

こうした質問への回答をスポンサー側が追いかけて確認しなければならないと、イベントの運営が行き届いていないと受け取られます（DevOpsDays ガイド。「直感的な印象」による運営能力への懸念については MLH ガイド）。

「価値を感じません」という反応は、価格への異議ではなく、ニーズを探る手掛かりです。見込み顧客がまだニーズを明確にしていないため、価格を正当化したり引き下げたりする前に、何を必要としているか尋ねましょう。

references/objection-handling.md に、5 項目の回答形式と 2 種類の提供形式（通話中に使うクイックリファレンステーブルと、事前準備用の詳細ドキュメント）を用いて、反論対応のライブラリを作成します。この形式は、一般的な B2B 営業支援から借用したものです。スポンサーに特有の 4 つの懸念事項（参加者にとっての価値、共同スポンサーの構成、パッケージの価値、主催者の運営能力）と、主催者自身の回答に基づく内容を記入します。このフレームワークにある「技術的」な反論の分類に相当するスポンサー向けの項目はありません。無理に当てはめず、削除します。

再参加スポンサー

前回開催のスポンサーへの更新営業は、開催終了から独自のスケジュールで samber/dev-event-organizer-skills@event-sponsor-renewal が担当します。このスキルが再びアプローチするのは、その動きによって対象となったスポンサー、丸々1回の開催を休んだスポンサー、支援担当者が退職して新たな勤務先に移った場合に限られます。そして、探索的な打ち合わせから再びアプローチします（詳細はreferences/pipeline-and-renewal.mdを参照）。

再参加スポンサーに新規スポンサーと同じようにコールド営業をしてはいけません。昨年協賛金を支払った企業に、イベントの内容を説明するメールを送るのは、自分のスポンサーを把握していないと思われます。

失敗例

• プログラムの公開後に営業を始める。 予算の確保期間は、およそ開催の8か月前に終了しています。開催4か月前に出来上がった立派な提案書を送っても、すでに割り当て済みの予算を取り合うことになります。対策：CFPやマーケティングより前に、最初の外部向け活動として営業を始めます。
• 最初のコールドメールにリンク、添付ファイル、画像を入れる。 企業のフィッシング対策フィルターによって、読まれずに自動削除されます。提案書もリンクも、フォローアップまで送りません。
• 探索的な打ち合わせの前にパッケージを売り込む。 まず打ち合わせで、スポンサー自身のニーズ、成功指標、予算を把握します。相手から聞かれていないことに答える提案書を、いきなり送っても意味がありません。提案書は打ち合わせの後に送り、そこで聞いた内容を強調します。
• プログラムに含まれていない活動を売り込む。 打ち合わせで採用コーナーやデモスペースを約束したのに当日用意されていなければ、署名済みの契約が更新見送りにつながります。現行のプログラムに沿って提案し、未実施の活動については samber/dev-event-organizer-skills@business-event-formats に連携します。
• 上限を超えてフォローアップを続ける。 上限を超える接触は、取り戻せる好意よりも多くの好意を損ないます（離脱曲線はB2B SaaSの営業ベンチマークであり、スポンサー営業のものではありません。コミュニティでの評判を損なうコストこそ、スポンサー営業に特有の理由です）。
• 配信停止の要望を次の予定連絡まで放置する。 相手から要望があった時点で、連絡の途中であっても対象から外します。
• 再参加スポンサーを新規スポンサーとして扱う。 「再参加スポンサー」を参照してください。これはパイプラインで最も見込みの高い相手を無駄にし、同じメールで相手の心証も損ないます。
• SaaSの数値をスポンサー営業の事実として受け取る。 「返信率9〜15％」や「成約率20〜30％」を前提にすると、別業界のベンチマークを、測定されたことのない分野に持ち込むことになります。データが蓄積するにつれて、自社の開催回ごとの実測値を使います。
• 関係を担当する人がいない。 見込み顧客がどこにも記録されていない、あるいは全員が担当している状態では、気付かないうちに関係が途絶えます。スポンサーごとに担当窓口を1人決め、共有のパイプラインを1つ用意します。

測定

イベント協賛には、独自の返信率、成約率、営業サイクル期間の公表値がありません。そのため、SaaSの数値を代わりに当てはめてはいけません。追跡できるのは、開催回ごとに自分たちで設定し、測定するファネルです。

• パイプラインのカバレッジ（自分たちで設定）：進行中の見込み顧客数と、収益目標に必要な件数から逆算したリストを比較します。リストの段階で不足があれば、数か月前から成約数の不足が予測できます。
• ステージ間の転換率（自分たちで設定）：最初の連絡 → 打ち合わせ、打ち合わせ → 提案、提案 → 成約をチャネルごとに追跡し、再アプローチする休眠スポンサーには、コールド営業の新規スポンサーとは別のタグを付けます。第2回開催までには、自分たち独自のベンチマークができあがります。スポンサー営業に特化した数値として得られるのは、それだけです。
• 異議の再発：記録上で同じ異議が繰り返されるなら、それは営業上の問題ではなく、そのセグメントに対する価値提案の表明に欠陥があるということです。samber/dev-event-organizer-skills@event-sponsor-value-proposition に連携します。
• 更新率は営業活動ではなく、関係全体（提供内容、レポートの質）を反映します。samber/dev-event-organizer-skills@event-sponsor-renewal が算出し、samber/dev-event-organizer-skills@event-market-fit が需要のシグナルとして読み取ります。

呼び出し例

• 「来年10月に開催する400人規模のコミュニティカンファレンスに向けて、スポンサー協賛金として4万ユーロが必要です。ターゲットリストとアプローチ計画を作成してください。」
• 「スポンサーになってほしい開発ツール企業への最初のメールを作成してください。チームにはその会社に知り合いが誰もいません。」
• 「スポンサー候補に提案書を送ってから2週間が経ちましたが、返事がありません。次はどうすればよいですか？」
• 「2回前の開催時にスポンサーだった2社が、その後戻ってきていません。初対面のように振る舞わずに、もう一度提案できますか？」

期待される出力：

• スコア付きのターゲットリストと、各社に最初に連絡すべき理由を示す上位3〜5社の注目リスト。
• 会計年度の期間に合わせた、ターゲットごとのチャネルおよび連絡頻度計画。
• パイプラインの各段階に応じた、電話と提案書に関する次のアクション。
• samber/dev-event-organizer-skills@event-sponsor-value-proposition に連携した異議ログ。想定したすべての率には、自己設定であることを明記します。

参考資料

• references/outreach-process-and-email-craft.md - 5段階のプロセス、最初のメールに含める内容のチェックリストとエチケットのルール、スポンサーの動機に応じた役職のターゲティング、紹介依頼の仕組み、ANUMを取り入れた初回相談の台本、提案書のルール、各率の意味を含む2種類の連絡頻度計画。
• references/objection-handling.md - 5項目の異議対応フレームワークと2種類の形式での提示。4つのスポンサー懸念から作成したスポンサー固有の異議セットを含み、「価値を感じない」という意見はニーズの把握として扱います。推定した項目にはその旨を明記します。
• references/pipeline-and-renewal.md - Hot／Warm／Cold／Skipのスコアリング基準とリードシートの形式、自己設定率についての注意を含む逆算式のパイプライン計算、トラッキングと連絡担当者の実務、成約の仕組み、更新の流れから休眠スポンサーが再び加わる方法。

同じコレクションの関連項目：

• samber/dev-event-organizer-skills@event-sponsor-value-proposition - 提案内容と、ニーズからカテゴリへの対応付けを提供します。初回相談でこれを活用し、このスキルの異議ログを受け取ります。
• samber/dev-event-organizer-skills@event-positioning と samber/dev-event-organizer-skills@business-event-formats - ビジネス向けプログラムの層を担当します。これは作成されて初めて、アプローチで提案できるようになります。
• samber/dev-event-organizer-skills@event-sponsor-prospectus - 初回相談後に送付する資料です。
• samber/dev-event-organizer-skills@event-sponsor-pricing - 提案の段階でパッケージを選ぶための料金表です。
• samber/dev-event-organizer-skills@event-sponsor-agreement - このスキルが成約した後の契約を担当します。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment - 販売内容を提供し、イベント後のレポートを作成します。
• samber/dev-event-organizer-skills@event-sponsor-renewal - 前回のスポンサーを担当します。更新の打診、オファーと関係修復、そしてここに引き継ぐ内容を扱います。

リポジトリ横断（依存関係ではなく推奨事項）：samber/developer-relations-skills@developer-event-sponsorship は、購入者側から同じ取引を扱います。そのデューデリジェンスチェックリストは、電話と最初のメールで答えられるよう準備しておくべき内容そのものであり、ターゲットリストの適合性テストは、そのデューデリジェンスを逆向きに行うものです。