mcpField
E
event-sponsor-fulfillment

event-sponsor-fulfillment

github.com/samberマーケティング・グロース45.5k 回インストール2 日前に更新
リポジトリ

event-sponsor-fulfillment について

event-sponsor-fulfillmentは、契約締結から特典の提供、開催後の報告までを管理するイベント主催者向けスキルです。特典の約束と提供証拠を追跡し、全額入金後に提供を進め、更新検討用のレポートを作成します。

主な機能

  1. 01プラン別の特典提供マトリクス作成
  2. 02全額入金後に特典を提供
  3. 03期限に合わせたスポンサー素材の収集
  4. 04特典ごとの提供証拠を記録
  5. 05段階的な開催後レポート送付
  6. 06更新判断を関連スキルへ引き継ぎ

活用シーン

  1. 01プラン別のスポンサー提供項目の追跡
  2. 02印刷期限に向けたスポンサー素材の調整
  3. 03開催後の証拠に基づくレポート作成

インストール

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

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-sponsor-fulfillment

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
day-of-logistics.md
fulfillment-matrix-and-onboarding.md
metric-sourcing.md
post-event-report.md

詳細

イベントスポンサーへの提供内容の履行

成約したスポンサー契約と、更新に向けた商談で使うイベント後レポートの提出。その間に約束した内容をすべて提供します。

上流工程を担当する関連スキルが確定した内容を受け取り、証拠を添えて提供済みの特典を記録し、samber/dev-event-organizer-skills@event-sponsor-renewal が更新の話し合いの軸とするイベント後レポートを作成します。

  • 約束した内容は、samber/dev-event-organizer-skills@event-sponsor-value-proposition から取得します。
  • パッケージと価格は、samber/dev-event-organizer-skills@event-sponsor-pricing から取得します。
  • 署名済みの提供内容一覧は、samber/dev-event-organizer-skills@event-sponsor-agreement から取得します。

この業務を左右する重要な事実は2つあります。

  • スポンサー料金が全額支払われるまで、特典を提供してはいけません(DevOpsDays のスポンサー向けページ)。
  • 主催者が更新に向けて最も大きな効果を得られる行動は、データに基づくイベント後レポートを速やかに送ることです(72時間以内に概要を、10営業日以内に第2段階のレポートを送ります)。「ロゴを売れば1年のスポンサーが得られ、データを売ればパートナーが得られます」。

以下の各項目の優先順位(オンボーディング手段、リード獲得の方針、レポートの詳細度)は、いずれも標準的な初期設定であり、決まりではありません。状況や実行者によって変わります。ヒアリング後、この主催者についてわかったことをもとに、3つの選択肢すべての順位を見直してください。次のいずれかが、標準の順位を覆すことがあります。

  • スポンサー対応の専任担当者がいる。
  • 複数回の開催を通じて関係を深めるスポンサーのポートフォリオがある。
  • スポンサーが合計3社の初開催である。
  • 印刷物の入稿期限がすでに過ぎている会場である。

ヒアリング

質問は一度に1つずつ行い、可能な限り選択式にします。質問6〜8を設けているのは、以下の選択肢で効果が出るまでの期間と必要な労力が大きく異なるためです。標準の順位だけで選ぶことはできません。

  1. イベントはどちらの形態ですか。ボランティア主催者が運営し、リスト掲載禁止ルールを公開しているコミュニティ運営型ですか。それとも、有給スタッフが運営し、同意の範囲内でのリード情報取得を検討できる企業・財団運営型ですか。これによって、リード獲得の選択肢としてそもそも存在するものが決まります。
  2. 署名済み契約書で、スポンサーごと、ティアごとに実際に約束した内容は何ですか。マトリックスは、見込み客向け資料から再構成するのではなく、署名済みの提供内容一覧をもとに作成します。個別交渉で加わった差分が記載されるのは契約書だけです。契約書が見つからない場合は、まず samber/dev-event-organizer-skills@event-sponsor-agreement に引き継ぎます。
  3. 各スポンサーの支払い状況はどうなっていますか。請求済み、支払い済み、一部支払い済みのいずれですか。何かを提供する前に、支払いゲート(ワークフローのステップ3)でこの情報が必要です。
  4. イベント前の厳守すべき期限は何ですか。ネックストラップ、ノベルティ、看板などの印刷物の入稿期限、プログラムの確定日、ニュースレターの配信予定日はいつですか。履行スケジュールの起点となるのはイベント当日ではなく、これらのうち最も早い期限です。
  5. 各スポンサーは、成功の指標と予算について、事前の打ち合わせで何を挙げましたか。レポートは一般的な指標ではなく、スポンサーが示した指標に基づいて評価します。
  6. レポートとその分析をいつまでに準備する必要がありますか。スポンサーの予算はいつ確定しますか(samber/dev-event-organizer-skills@event-sponsor-renewal では、その前に確認を求めます)。(期限が近い場合は、完全版レポートではなく短縮版を作成します。概要だけにすることはありません。どちらの場合も72時間以内という期限が適用されます。第2段階のレポート提出期限より前に予算が確定する場合は、そのスポンサーへの現地での提案内容について、イベント前に samber/dev-event-organizer-skills@event-sponsor-renewal を実行してください。)
  7. 各スポンサーは単発ですか。それとも複数回の開催を通じて関係を深めるスポンサーですか。(関係を深める方針がある場合、そのスポンサーにはキックオフの打ち合わせと完全版の指標レポートを優先します。)
  8. 労力の上限はどの程度ですか。週に数時間のボランティア対応ですか。それともスポンサー対応の専任担当者がいますか。(この回答だけで、オンボーディングとレポートの選択肢のほぼすべてが決まります。)

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

提供内容を左右する軸は、イベントの主催者が誰かです。同じ区分については、samber/dev-event-organizer-skills@event-sponsor-value-proposition と samber/dev-event-organizer-skills@event-sponsor-outreach でも説明されています。

  • コミュニティ運営 - 主催者が公開しているルールによって、提供できる内容が制限されます。参加者の連絡先リスト、購入可能な講演枠は提供できず、人口統計データは集計済みのものに限られます(DevOpsDays の運営ガイドに、文書で 2 回記載されています)。リード獲得は、同意を得たフォームでのみ行えます(下記のメニューを参照)。ボランティアが提供内容を運用するため、チェックリストメールとイベント後のまとめメールが標準となります。
  • 企業/財団運営 - 同意に基づくバッジスキャンやリード情報の取得は、責任を持って提供できます。また、有料のイベントチームであれば、より手間のかかる段階にも対応できます。公開されている主催者向けガイダンスはコミュニティ運営を前提としているため、企業運営における変更は、確立された慣行ではなく、個別の判断として扱ってください。

ワークフロー

  1. インタビューを実施し、条件を固定し(Q1)、署名済みの契約をすべて回収し(Q2)、スポンサーごとの支払い状況を確認します(Q3)。
  2. 署名済みの契約に基づき、ティア別の特典履行マトリクスを作成します。特典ごとに1行、ティアごとに1列(カスタム差分が生じたらスポンサーごとに1列)を設け、各セルで「約束済み → 予定済み → 提供済み → 証拠記録済み」の状況を追跡します。実際の行項目と、マトリクスで守るべき公開上限ルールは、references/fulfillment-matrix-and-onboarding.md に記載されています。特典を平坦なリストにまとめるのは失敗の形です。ティアごとの視点が失われ、すべてのSilverの行が完了と表示されている中で、未提供のGold特典を見落としてしまいます。
  3. 支払いが確認できてから提供を開始します。料金が全額支払われる前に、特典を提供してはいけません。ロゴの掲載、チケットの発行、ブースの割り当ても行いません。会場の入口で突然何かを差し止めるのではなく、リエゾンを通じて請求書の支払いを促します。スポンサーには、何を保留しているのか、その理由も伝えます。
  4. 支払い済みの各スポンサーをオンボーディングします。以下のメニューから提供手段を選び、期限表に沿って素材を回収します(ロゴ形式、紹介文、求人情報、ワークショップの内容、代表者名 — MLH organizer guide)。スポンサーごとにリエゾンを1名決めます(DevOpsDaysの実践に倣い、該当する場合は同じリエゾン samber/dev-event-organizer-skills@event-sponsor-outreach を割り当てます)。
  5. イベント前の特典は、最も早い厳守期限のものから提供します。印刷物(ランヤード、ノベルティ、看板)をデジタル特典より先に、その後にニュースレターとSNSでの紹介、プログラムやスライドへのロゴ掲載、チケットコードの順に提供します。提供時に、リンク、スクリーンショット、写真などの証拠をマトリクスのセルに記録し、後から遡って記録しないでください。スポンサーが利用していない特典には印を付け、イベント終了前に移動または差し替えます。未利用の特典は、更新を検討する際の危険信号です。
  6. 当日の体験を運営します。スポンサーから質問される前に、回答済みのロジスティクスFAQを全スポンサーに送ります(設営・撤収時間、配送、スタッフ配置のガイダンス、電源/WiFi/A/V — references/day-of-logistics.md)。ティアに応じてブースと上位特典の配置を行い、特典として販売した抽選会と当選者への引き渡しを、予定どおり実施します。特典が、クレジット、API、ツールなど、参加者がスポンサー独自のテクノロジーを実際に使うものである場合は、現地の代表者がいることを、あれば望ましいという程度ではなく、オンボーディングの必須条件にします。時間に追われる中で参加者がつまずいたとき、ドキュメントだけでは現場の担当者の代わりになりません。また、トラブル対応者がいないツールは、動かなくなった時点で使われなくなります。現地の代表者がいない場合は、そのツールを熱心に利用している独立したユーザーを、現地の連絡担当者として配置します。連絡担当者を置けないからといって、何も対応しないままにはしません。ドアが開く前に確定した計測計画を実行し、すべてのスポンサーで同じ行項目、時間帯、計測担当の役割を使います(references/metric-sourcing.md)。スポンサー同士は情報を共有するため、1つのブースだけ計測し、隣の3つのブースは計測しない状況は、えこひいきに見えます。
  7. スポンサー自身が示した成功指標(Q5)に照らして評価したうえで、レポートメニューで選んだ深さに応じた事後レポートを2段階で送ります。イベントの振り返りは72時間以内に、ステージ2のレポート(簡易版または全指標レポート)は10営業日以内に送ります。いずれかのレポートを送る前に、スポンサーがまだ知らない未達事項があれば開示します。各数値の下に、データの出所、集計ルール、取得日、証明できないことを記した方法の説明を付けます(references/metric-sourcing.md)。テンプレートは references/post-event-report.md にあります。
  8. レポートと所見を samber/dev-event-organizer-skills@event-sponsor-renewal に引き継ぎます。レポートと、更新・再交渉・契約終了に関する所見が、このスキルの最終成果物です。更新の打診、そのタイミングとスポンサーの予算サイクルとの調整、更新の提案、価格変更、再契約は、引き継ぎ先が担当します。ここではフォローアップの連絡計画を作成しないでください。 ハーネスに永続メモリがある場合は、スポンサーごとに、セルの状態と根拠へのリンクを含むマトリックス、支払い日、収集済みのアセット、提示された成功指標、レポートの送信日と詳細度、そして更新の見込みを記録してください。次回の開催時の履行と更新の働きかけは、その記録から始まります。

オンボーディング手段

契約締結後のアセット収集と期待値のすり合わせを、どのように進めるかです。Des Moines FAQでは、重要な回答はすべて主催者への直接の問い合わせに誘導しており、セルフサービスのドキュメントよりも、予定を組んだ連絡を推奨するパターンになっています。順位(標準設定であり、絶対ではありません。Q7とQ8で順位を変更します):

  • 労力:kickoff call > intake form > checklist email
  • 価値(アセットの期限内提出、期待値の早期把握):kickoff call > intake form > checklist email
  • 効率:checklist email > intake form > kickoff call

優越性チェック:3組の比較で、厳密な優越関係はゼロです。構成上のみ問題がありませんが、構成上問題がないことは決して合格を意味しません。 価値と労力の順位は同じなので、どの組み合わせも1つの要因で行き詰まります。アセットをより早く集める手段ほど、実施にかかる費用が厳密に高くなります。どの組み合わせにも影響を与えたり、優劣を覆したりする第3の軸は示されていません。このチェックでは何も検出できません。効率の順位は、以下の論拠に基づいています。

  • チェックリストメール - 標準の手段です。マトリックスの各スポンサーの列をもとに、提出が必要なアセット、その形式、厳守すべき締め切りをすべて記載したウェルカムメールを、スポンサーごとに1通作成します。マトリックスがあれば、追加の労力はほぼかかりません。単に特典を列挙するのではなく、具体的なプログラム上の時間に結び付けて記載します。どの講演枠か、どの名称付きの時間枠か、スポンサーの担当者が招待されるレセプションはどれかを示せば、「ぜひご参加ください」とだけ伝えて時間を推測させずに、スポンサー側のチームが日程に予定を入れられます。基本的なアセット一式も併せて用意します。写真、プレゼンテーションテンプレート、連絡先を尋ねるメールを1通に絞り込み、誰も使い切れないような大規模なツールキットにはしません。
  • インテークフォーム - 同じアセットを、入力検証(ファイル形式、紹介文の文字数制限)を設けた構造化フォームで収集します。スポンサーが3社ほどに増え、形式の誤ったロゴを1社ずつ催促する手間が、フォームを一度作るコストを上回る段階で、導入する価値があります。
  • キックオフコール - 優先度が低い選択肢です。価値が最も高い一方で労力も最大なので、効率の面では決して選ばれません。優先する条件は、最上位ティアのスポンサー、初回のスポンサー、関係が深まることで効果が積み重なる場合(Q7)、またはライブでの調整が必要な特典(ピッチ講演、ワークショップ、スポンサー付きトラック)がある場合です。

リード獲得の方針

このイベントでスポンサーに提供されるリードデータです。コミュニティ主導のイベントでは、選択肢の大半は主催者自身が公開しているルールで決まります。コンプライアンスコストの軸をここに含めるのは、同意とデータの開示において、各段階に実質的な違いがあるためです。順位(デフォルトであり、絶対的なルールではありません。どの段階が存在するかは Q1 で決まります):

  • 労力:同意に基づく抽選 > 集計済みの属性データ
  • 価値(スポンサーが活用できるリードデータ):同意に基づく抽選 > 集計済みの属性データ
  • 効率:集計済みの属性データ > 同意に基づく抽選
  • コンプライアンスコスト(発生する審査と、そのうち取り消せる範囲の狭さ):同意に基づく抽選 > 集計済みの属性データ

優越性チェック:2 段階、1 組、厳密な優越関係はゼロ。構成上はクリーンですが、それだけで合格とはなりません。 価値、労力、コンプライアンスコストはすべて同じ順序なので、唯一の組み合わせはコストの面で不合格です。抽選は、より活用しやすいリードデータを提供しますが、両方のコスト軸で明確に劣ります。2 段階しかないメニューでは、ほかにチェックするものはありません。また、コンプライアンスコストは労力の順序を繰り返しているだけで、順位を変えるものではありません。効率の判断については以下で論じますが、検証はされていません。

コンプライアンスの順位付けについて説明します。集計済みの属性データでは、個人データを処理しないため、審査も発生しません。抽選では、特定のスポンサーに提供する目的で、参加者から個人データを提供してもらうため、次の対応が必要です。

  • 収集する情報と、その提供先を平易に説明すること。
  • そのスポンサー 1 社のみに引き渡すこと。
  • 引き渡し後、主催者が保管するコピーを削除すること。

引き渡しを誤ると、後から取り消すことはできません。

  • 集計済みの属性データ - デフォルトの選択肢であり、コミュニティイベントにおけるリードデータの誠実な代替手段です(「属性を集計した形で共有し、どのような層が来場するかをスポンサーに伝える」― DevOpsDays ガイド):職種の構成、役職の構成、企業規模の構成などです。氏名は含めません。1 つの資料をすべてのスポンサーとレポートで再利用します。
  • 同意に基づく抽選 - 優先度の低い選択肢です。オプトインの仕組みは DevOpsDays Des Moines のスポンサー向けページに記載されています。参加者が賞品を獲得するチャンスを得るため、特定のスポンサーに自分の連絡先情報を提供します。主催者は抽選の時間を設定し、当選者の写真を撮影します。このメニューで価値と労力がともに最も高く、コンプライアンスコストが発生する唯一の段階でもあるため、効率の観点から選ばれることはありません。参加者リストとは別の、提供済み特典として記録し、参加者リストの代わりには決してしないでください。実施条件:スポンサーがパイプライン構築または採用を明確な目的として掲げ、この特典を購入していること。実施方法についてはreferences/day-of-logistics.mdを参照してください。
  • 削除対象であり、順位を下げるものではありません:コミュニティ主催イベントでの参加者リスト一括提供と、バッジスキャンの約束。 主催者自身のガイドでは、この両方が文書で 2 度にわたり禁止されています。プレッシャーの下で手を伸ばす最下位の選択肢ではありません。これを要求するスポンサーには、上記の 2 段階のいずれかを提示するか、契約しないでください。企業または財団が主催するイベントでは、同意の範囲内でのスキャンが正当な選択肢として再び加わります。これは購入者が決定し、主催者側で妥当性を判断します。

レポートの詳しさ

イベント後にすべてのスポンサーが受け取る内容です。ステージ 1 は固定です。すべてのスポンサーに対し、72 時間以内にお礼メールを送ります。内容は、未開示の未達事項があればまずそれを伝え、お礼、イベントの振り返り、写真、集計済みの参加者数と属性(算出方法の記載付き)、およびマトリクスに基づく各スポンサーへの特典提供状況の概要です(MLH ガイド:お礼とイベントの振り返りを終了後すぐに送信)。以下のメニューからステージ 2 を選びます。期限は 10 営業日以内です。テンプレートはどちらも references/post-event-report.md にあります。順位(デフォルトであり、絶対ではありません。Q6、Q7、Q8 によって再順位付けされます):

  • 労力:full metrics report > short form > recap only
  • 価値(更新意向への影響):full metrics report > short form > recap only - データに裏付けられたレポートは、更新に最も効果の高い施策として挙げられています
  • 効率:short form > full metrics report > recap only

優越性チェック:3 組を比較し、厳密な優越関係はゼロです。これは構成上そうなるだけであり、それで合格にはなりません。 価値と労力の順位が同じなので、すべての組で同じ結果になります。更新意向への効果が高い資料ほど、作成コストも確実に高くなります。このチェックでは何も検証できません。

効率の順位には根拠があります。ショートフォームはマトリクスと集計計画から作成できるため、振り返りからの追加コストはほとんどありません。それでいて、更新の話し合いに必要なものはすべて含まれます。一方、フルレポートには、スポンサーごとの説明、自由記述の引用、価値の列が追加され、実際に執筆コストがかかります。振り返りのみでは、更新意向への効果はほぼ期待できません。

  • ショートフォーム - すべてのスポンサーに対するデフォルトのステージ 2 です。samber/dev-event-organizer-skills@event-sponsor-renewal が求めるのは、説明文を付けずにレポートの 8 つのセクションをすべてまとめたものです。つまり、参加者に関する 3 つの数値、スポンサーが購入した項目の結果行のみ、アンケート終了後の参加者フィードバック、マトリクスの行に関連付けた写真 3~5 枚で、各スポンサーにつき 1 部、算出方法の記載付きです。開催日が近い場合(Q6)は、フルレポートをこれに短縮します。振り返りのみにすることはありません。
  • フルメトリクスレポート - 選ばれにくい選択肢です。references/post-event-report.md にあるスポンサーごとの資料で、契約内容に対する提供状況、参加者、リード、ブースへの訪問者数、セッションと録画の視聴数、ブランドのリーチ、スポンサーに関する参加者のフィードバック、問題点と対応策、写真を、説明文、自由記述の引用、価値の列とともに記載し、スポンサーが表明した成功指標に照らして評価します。価値は高いものの、労力も大きいため、効率の観点では選ばれません。上位ティアで個別資料を作る価格的な妥当性があること、事前の探索的な打ち合わせで成功指標が明示されていること、または効果の積み上げを目指す要件があること(Q7)が、優先して選ぶ条件です。
  • 振り返りのみ - 更新予定のないスポンサーに限り認められます。お礼だけで終わらせてはいけません。振り返りに追加データの集計が必要で、もう 1 日かかる場合の暫定対応として、翌日に送るものに限って使用できます。

失敗パターン

  • 支払い確認前に特典を提供してしまう。 ロゴが印刷された未払いのスポンサーには、もはや支払う理由がありません。また、公表済みのルールでは、特典の提供前に全額の支払いを求めています。対策:支払い確認をワークフローのステップ3に設定し、オンボーディングの前に行います。直前になって突然求めるのではなく、事前に伝えておきます。
  • 印刷の締め切りに間に合わない。 印刷済みのストラップにロゴが載らなければ、印刷後に修正することはできません。特典ではなく、代替措置の交渉になってしまいます。対策:最も早い確定締め切りの成果物から提供します。履行期間の起点はイベント当日ではなく、印刷会社の締め切りです。
  • 報告時に、約束した特典が未提供だと判明する。 イベント後にマトリクスを再構成すると、更新の依頼が謝罪に変わってしまいます。対策:各項目はリアルタイムで、証拠付きの提供済みに更新します。特典の提供が漏れていた場合は、スポンサーに気づかれる前に、代替措置とともに報告書で自ら明示します。
  • 数値の誇張。 「ブランドインプレッション」を参加者数×掲載箇所数で算出したり、通貨換算した「メディア価値」を示したりすると、隣にある実際の数値への信頼まで損ないます。コミュニケーション効果測定の基準(AMEC Barcelona Principles)では、通貨換算したメディア価値は「使用すべきではない」とされています。対策:プラットフォームごとにリーチをカウントし、決して合算しません。各数値の下に算出方法を記載します。
  • リストの一括提供による情報漏えい。 しつこく求めるスポンサーにボランティアが参加者リストを渡せば、情報漏えいが一度起きるだけで、今後のすべての開催に適用される公表済みのコミュニティルールを破ることになります。対策:削除した段階は復活させません。抽選と集計済みの属性情報だけが提供可能なデータであることを、すべてのボランティアに周知します。
  • 報告書の送付が翌年の企画まで遅れる。 まずすぐに振り返りを送り、その後に関係を再び深めるのが本来の順序です。何か月も遅れて送る報告書では、何の足がかりにもなりません。対策:振り返りの内容が簡潔なものでも、72時間以内に送ります。関係の再活性化は samber/dev-event-organizer-skills@event-sponsor-renewal が担当します。
  • 提案資料から納品物を再構成する。 提案資料は営業用の文書です。交渉で生じた変更点は、署名済みの契約書に記載されています。対策:マトリクスの約束事項の列には、スポンサーごとに契約書の文言を記載します。
  • ロゴとの相性だけで協賛セッションを確定する。 ブランドとの相性やトピックの提案を確認することは、登壇者が実際にステージで何を話すかを確認することとは別です。時間が限られた参加者に、まず何時間もかけてツールのトレーニングを受けるよう勧める協賛枠は、イベント自体の形式に真っ向から反します。コンテンツを誰も確認しなかったため、誰も問題に気づきませんでした。対策:スポンサー名やトピックだけでなく、協賛枠の実際のコンテンツを確認してから確定します。

測定

別途記載がない限り、目標値は独自に設定し、業界の数値ではなく、自分たちのマトリクスに照らして評価します。

  • 特典提供完了率(独自設定):報告書の送付前に、マトリクスのすべての項目を、証拠付きの提供済み、または代替措置を明記した状態にします。これに満たない場合は、上記の報告時に発覚する失敗に該当します。
  • 報告書の送付所要時間(既定の二段階方式、評価対象):すべてのスポンサーに72時間以内に振り返りを送ります。第二段階の報告書(簡易版または完全版)は、10営業日以内に送ります。
  • 算出方法の記載率(独自設定):すべての報告書で、算出方法を記載せずに数値を示すことをゼロにします。
  • 素材の期限内回収率(独自設定):各確定締め切りまでに素材を受け取ります。ロゴの提出遅れは、このスキルが最初に察知する警告です。
  • 更新率は関係全体を評価します。samber/dev-event-organizer-skills@event-sponsor-renewal が算出するのは、ロゴ、総収益、純収益の維持率です。samber/dev-event-organizer-skills@event-market-fit は更新率を需要の指標として読み取ります。このスキルは、その更新率を左右する要素の一つです。

呼び出し例

  • 「10月のカンファレンスにスポンサーが3社決まりました。提供内容の履行状況を追跡できるようにしてください。」
  • 「Gold スポンサーのロゴは金曜日に印刷会社へ渡す必要があり、スポンサー2社はまだ支払いを済ませていません。何を発送し、何を保留しますか?」
  • 「イベントは土曜日に終了しました。スポンサー向けレポートを作成してください。」
  • 「最上位のスポンサーが参加者のメールアドレスを求めています。実際には何を提供できますか?」

想定される出力:

  • セルごとのステータスと根拠を含む、最新のティア別特典マトリックス。
  • 厳格な期限を記載した、スポンサーごとのオンボーディングチェックリスト。
  • 当日のスポンサー向け概要。運営に関するよくある質問に回答します。
  • メニュー形式のスポンサーごとのイベント後レポート。各レポートの最後には、継続/再交渉/打ち切りの判断を記載し、samber/dev-event-organizer-skills@event-sponsor-renewal に引き継ぎます。

構成した形式や独自に設定したしきい値には、それぞれその旨を明記してください。

参考資料

  • references/fulfillment-matrix-and-onboarding.md - 2種類の実際の行セットと公開上限のルールを用いたマトリックスの形式、セルの状態、支払いゲートの根拠、段階的なオンボーディングチェックリスト、期限表付きのアセット受け入れリスト。
  • references/day-of-logistics.md - 定期開催イベントで実際に使われた、回答済みのスポンサー向け運営FAQ、スタッフ配置のガイダンス、プライバシーに配慮した同意制ラッフルの仕組み。
  • references/post-event-report.md - 2段階の期限、イベント振り返りメール、8項目からなる第2段階のレポート(全指標レポート)、短縮版、対応する継続/再交渉/打ち切りの判断、記入ルール、悪い例。
  • references/metric-sourcing.md - 指標の算出方法の説明、各指標のイベント前の準備、集計ルール、根拠と限界、スポンサー向けアンケートの質問、使用禁止の数値。

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

  • samber/dev-event-organizer-skills@event-sponsor-renewal - レポートと判断を、更新の打診、更新提案、価格変更の説明、離脱リスクのあるスポンサーの引き留めに活用します。
  • samber/dev-event-organizer-skills@event-booth-experience - 各開催回のフロアレイアウト、ティアごとの物理的な仕様、全体の設営スケジュールを設計します。このスキルでは、当日の運営に関する回答を独自に繰り返すのではなく、そのフロア概要を参照します。
  • samber/dev-event-organizer-skills@cross-event-promotion - 主催者2者間でブースまたは独占権を交換する場合、どちらかが確約する前に、このスキルのスポンサー独占条件をクリアする必要があります。
  • samber/dev-event-organizer-skills@event-attendee-experience - スポンサー側のリード獲得方針(コミュニティ主催イベントで約束したバッジスキャンを取り消す対応を含む)を担当します。これは、このスキルの提供内容マトリックスと直接関係します。

コメント