mcpField
M
monthly-to-annual

monthly-to-annual

github.com/posthogマーケティング・グロース7695 回インストール今日更新
リポジトリ

monthly-to-annual について

monthly-to-annual は、月払いまたは PAYG の顧客を年間前払いクレジットプランへ移行する際、簡潔なブリーフィングと Slack の下書きを作成する PostHog の営業支援スキルです。適格性と割引条件を先に確認し、請求情報や顧客の状況を踏まえて、押しつけのない次のアクションをまとめます。

主な機能

  1. 01プラン状態と割引適格性を確認
  2. 02購入額、期間、支払い、契約時期の条件を適用
  3. 03請求履歴と製品構成を確認
  4. 04連絡履歴から顧客の懸念を把握
  5. 05最近の公開情報を顧客背景として参照
  6. 06簡潔なブリーフィングと Slack 文面を作成

活用シーン

  1. 01月払いから前払いプランへの移行を提案
  2. 02見積もり前に割引適格性を確認
  3. 03アカウントの請求情報と最近の顧客動向を確認
  4. 04明確な次のアクションを含む顧客向けフォローを作成

MCP 対応

ワークフローでは、Slack、Gmail、Granola の会議記録、Exa を検索する MCP ツールと、組織・請求データを取得する SQL クエリを指定しています。これらをブリーフィングと顧客向け文面のアカウント情報に利用します。

インストール

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

$npx skills add https://github.com/posthog/skills --skill monthly-to-annual

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

詳細

monthly-to-annual

PostHog の従業員が、月払い/PAYG の顧客を年間前払いのクレジットプランに切り替えるメリットを説明するのを支援します。簡潔にしてください。 要点を絞った説明を1つ、Slack の下書きを1つ。前置きは不要です。

重要な背景:PostHog は、契約期間の長さにかかわらず、月払いの顧客に割引を提供していません。割引が適用されるのは、前払いのクレジットプランに切り替えた場合のみです。すべて、この点を軸に説明してください。

PostHog の販売方針(下書きの前に読んでください)

顧客向けの文面を書く前に、以下の方針を理解してください。出典:posthog.com/handbook/growth/sales/。

  • 顧客は私たちから購入します。私たちが売り込むのではありません。 営業らしい余計な話はしません。率直に、オープンに、正直に伝えます。
  • 売り込みより好奇心を大切にします。 課題を見つけましょう。顧客が購入するのは機能ではなく、問題の解決策です。「無理に興味を持たせるのは、うっとうしく、営業臭いものです。」
  • 押しつけず、役に立つことを重視します。 第一の目的は、有料顧客の成功を支援することであり、無理に販売を成立させることではありません。
  • ユースケースを提案し、製品に対して請求します。 明細項目(「クレジットを購入する」)ではなく、顧客が得られる成果(例:「次の成長段階に向けて、単価を事前に確定する」)を中心に説明します。
  • 次のステップを具体的に示します。 「顧客から連絡が来るのを待つ」は、有効な次のステップではありません。すべての出力は、具体的な次のステップまたは質問で締めくくります。
  • 商談を失うことを恐れません。 プレッシャーをかけたり、人為的な期限を設けたり、偽の希少性を演出したりしません。相互コミットメントによる5%の割引は、四半期末割引ではありません。双方が合意した実際の契約締結日を設定することで適用されます。
  • 迅速さと対応力を大切にします。 顧客が急いでいる場合はそのペースに合わせます。そうでなければ、急ぐ必要性を作り出しません。

下書きは、商談をまとめようとするベンダーではなく、顧客に役立つ情報を伝えるチームメイトのような文面にしてください。営業担当者から、より強いクロージング表現を求められた場合は、一度は反対意見を伝え、その後も求められたら従ってください。

入力

必須:顧客名。 任意:組織 ID(ない場合は検索)、過去の見積もり URL、契約期間、支払い条件、非営利団体か/スタートアッププランを利用しているか、双方が合意した契約締結日がすでにあるか。

営業担当者が割引の適用要素を指定しない場合は、確認してください。デフォルトはありません。次のセクションの段階別ルールを適用してください。

割引段階(PostHog ハンドブックより、本文に記載)

posthog.com/handbook/growth/sales/contract-rules から 2026-06-12 に同期。ハンドブックが更新されている場合は、Exa で再取得してこのセクションを更新してください。

適用要素1 — 購入量(割引適用に必須の基本条件)
年間クレジット購入額基本割引
<$25kセルフサービスのみ(10%)または非営利団体(15%)
$25-59k20%
$60-99k25%
$100-249k30%
$250-499k35%
$500-999k40%
$1M+個別対応(エスカレーション)

月払いの顧客は、契約期間にかかわらず割引率が 0% です。割引を受けるには、クレジット購入に切り替える必要があります。適用要素2〜4の割引が適用される前に、購入量の条件を満たす必要があります。

適用要素2 — 契約期間(加算式、初回の注文書のみ)
  • 1年:+0%
  • 2年:+3%
  • 3年:+5%(それより長い契約期間には加算されません)
  • 4年以上:個別対応

契約期間の前半に追加購入するクレジットには適用されません。追加購入分には元の割引が引き継がれますが、契約期間に応じた割引は再加算されません。

適用要素3 — 支払い時期(加算式)
  • Net 30(標準):+0%
  • 複数年分を前払い:追加の各年につき+2.5%(2年分を前払い=+2.5%、3年分を前払い=+5%)
  • 支払い期限の延長:Net 30 を超える15日ごとに**−2.5%**(Net 60 → −5%)

割引契約では、前払いが必須です。四半期払い/分割払いは利用できません。予算が見込み総額に満たない場合は、該当する(おそらくより低い)割引段階に応じてクレジットを少なめに購入し、後から追加できます。

レバー 4 — 導入時期に関する相互コミットメント(加算方式、1回限り)
  • 月払いから年払いへの切り替えまたは新規契約:+5%。具体的に双方で合意した日までに契約を締結する意思を、顧客の実際の署名者から書面で確認できることが条件です。契約切り替えサイクルごとに1回限りです。
  • 更新:+5%。有効期限の60日以上前に署名され、かつ顧客が現在、有効なプリペイドクレジットプランを利用している場合に適用されます。クレジットを使い切って従量課金(PAYG)に移行した場合、+5%は適用されません。これは早期更新ではなく、クレジットプランへの再加入として扱います。
  • スケジュールが遅れた場合は、追加割引を取り下げるのが原則です。
割引の併用に関する注意
  • ほかの割引を適用するには、ボリュームティアの適用が必須です。
  • 4つのレバーはすべて加算方式で併用できます(割引率を合算します)。
  • これらの水準を超える割引には、Ben(TAE/TAM)または Simon(CSM)の承認が必要です。
特別プログラム(標準の割引構成に代わるもの)
  • 非営利団体: $25k未満は一律+15%、$25-100kはボリュームティアに+5%、$100k超は標準ティアのみです。各国の税法に基づく証明が必要です。
  • セルフサービスクレジット: $25k未満は10%割引で、12か月間、毎月1/12ずつ適用します(前払いではありません)。$25k以上は標準のボリュームティアが適用されます。有料請求書が3件以上、平均金額が$280以上、未払い請求書がないこと、upプラン/レガシー/既存のクレジットプランを利用していないことが条件です。
  • スタートアッププラン終了時: 約12か月分を前払いすると、2か月分の無料クレジットが付与されます。購入クレジットがそれより少ない場合は、購入額の1/6を無料クレジットとして付与します。契約開始日前に適用され、1回限りです。
  • Stripeで30%割引を受けているレガシー顧客: 古いイベント料金を利用しているため、新たな割引について話し合う前に標準料金へ移行する必要があります。
  • 契約の買い取り(競合他社との契約期間中の乗り換え): 前払いの年間契約を$20k+/yrで締結した場合、PostHogを最大6か月間無料で利用できます。期間は競合他社との契約の残存期間に比例します。証明が必要です。
  • 新規ビジネス向けの更新クレジット: 競合他社との契約更新を検討している見込み客には、初年度のクレジットを付与して合計割引率が40%となるよう提示できます。競合他社からの見積もり全体が必要です。
  • 利益率がマイナスになる案件: (a) 戦略的な顧客を獲得する、(b) 競合他社から顧客を奪う、(c) 競合他社への解約を防ぐ場合に限ります。年間約1件です。マネージャーにエスカレーションし、その後Simon/Benに相談してください。

適格性の確認 — 出力する前に必ず実施

計算する前に、以下を確認してください。不明な点や曖昧な点があれば、担当者に的を絞った質問を1つしてください。ハンドブックで認められていない割引の組み合わせを提示しないでください。先に提示して後から撤回すると、顧客の信頼を損ないます。

  1. 現在のプラン状況。 顧客は月次/PAYG、アクティブなクレジットプラン、またはクレジットプラン終了後にPAYGへ移行した状態のどれですか?
    • 月次/PAYG → これはコンバージョンです。相互コミットメントのレバー(レバー4)の+5%を適用できます
    • アクティブなクレジットプラン → これは更新です。期限の60日以上前に署名する場合、更新の+5%レバーを適用できます
    • PAYGへ移行済み → これは再加入です。デフォルトでは、コンバージョンの+5%も更新の+5%も適用されません。適用できるのは、ボリューム+コミットメント期間+支払い時期のみです
  2. 年間のクレジット購入見込み。 ボリュームの階層条件を満たしますか?年間支出の見込みが$30kの場合、担当者が25%を提案していても、顧客が適用対象となるのは20%のみです。$25k未満の場合、標準割引は適用されず、セルフサービス/非営利の対象となります。
  3. 特別プログラムの適用資格:
    • 非営利団体ですか? → 別の割引構成を適用します(上記参照)
    • スタートアッププランですか? → 別の割引構成を適用します(上記参照)
    • 旧来のStripe割引30%が適用されている顧客ですか? → フラグを立て、まず移行することを推奨してください
  4. 更新の状況(該当する場合):
    • 契約終了日は判明していますか? 60日以上先ですか?
    • 署名時点で、現在クレジットプランを利用していますか?
    • 当初の契約期間の前半以内ですか?(追加クレジットの購入に当初の割引が適用されるのは、この期間内のみです)
  5. コミットメント期間と支払い時期:
    • 1/2/3/4年以上ですか?(レバー2に影響します)
    • 前払いですか、それとも年払いですか?(レバー3とクレジットの割り当て方法に影響します)
    • Net 30ですか、それとも支払い条件の延長がありますか?(追加で15日延長するごとに−2.5%のペナルティ)
  6. 相互コミットメントのレバーの要件:
    • 具体的に合意した署名日はありますか?
    • 顧客の実際の署名権限者(推進者だけではなく)から、書面で確認を得ていますか?
    • いいえの場合、+5%は確定済みの数値ではなく、書面でのコミットメントを条件に適用可能として提示してください
  7. 支払い方法:
    • 銀行振込(前払いの標準方法)ですか? それともクレジットカードですか? クレジットカードの場合はMine(バックアップ担当のSimon)の承認が必要です。フラグを立ててください。
  8. 利益率とエスカレーションの基準:
    • $250k以上の取引 → 利益率を計算し、承認が必要であることを明記してください
    • $1M以上 → カスタム価格設定とし、エスカレーションしてください
    • 階層から算出される金額を下回るもの → 利益率がマイナスです。マネージャーにエスカレーションしてください
  9. 稼働率SLA/法務上の修正への対応方針(任意。ただし、関連する場合は明示してください):
    • 割引後ARRが$100k以上 → SLAを交渉条件として提示できます
    • $20k未満 → 法務上の修正は不可
    • $20-160k → 金額に応じて、軽微/中程度の修正のみ可能

担当者が1〜4に回答できない場合は、作業を中断して確認してください。 前提が間違ったままでは、正確なブリーフィングを作成しても全員の時間を無駄にします。

ワークフロー

ステップ1 — 組織を特定する
SELECT id, name, created_at FROM postgres.posthog_organization WHERE name ILIKE '%<name>%' LIMIT 5

複数の候補が見つかった場合は、どれかを確認してください。

ステップ2 — 請求推移を取得する
SELECT bi.period_start, bi.period_end, bi.mrr, bi.mrr_per_product
FROM postgres.prod.billing_invoice bi
JOIN postgres.prod.billing_customer bc ON bi.customer_id = bc.id
WHERE bc.organization_id = '<org_id>'
ORDER BY bi.period_start DESC
LIMIT 24

以下を順に計算します。

  • 現在のMRR(直近の確定済み請求書)
  • 年間ランレート(現在のMRR × 12)
  • 過去12か月の合計支出
  • 前年比成長率(最新の請求書と1年前の同月を比較)
  • 直近の傾向(過去5件の請求書に基づく年率換算成長率)
  • 最新の請求書における製品構成(合計の1%を超える明細項目)
ステップ 3 — 混乱を招く要因を調べる(省略しないでください)

目的:依頼の内容が場違い、または時期尚早になる要因を見つけます。見つけた兆候はすべて表に出してください。重要度を先回りして判断しないでください。 例:対応中のサポートエスカレーション、製品への不満、進行中の移行や解約の兆候、守れなかった約束、不満を抱いているステークホルダー、近日中の社内レビュー、すでに伝えられた価格への懸念、退職した推進役。

以下を並行して実行します。

3a. Slack — 顧客チャンネルとDM。 顧客のPostHog Slackチャンネルで、過去60日間を検索します。

in:#posthog-<customer-slug> after:<60d-ago>

担当者と顧客の連絡先との最近のDMも検索します。

3b. Gmail — 最近のスレッド。 担当者の受信トレイで、過去90日間を対象に顧客名(既知の場合は主要な連絡先も)を検索します。ツール:mcp__claude_ai_Gmail__search_threads を使い、"<Customer Name>" newer_than:90d のようなクエリと、明示的に判明している連絡先メールアドレスで検索します。スニペットを読み、最も関連性の高い1〜3件のスレッドに限って get_thread を実行します。

3c. Granola — ミーティングの文字起こし。 顧客名を使って mcp__claude_ai_Granola__query_granola_meetings を実行し、最近の文字起こしを探します。明示された調達スケジュール、予算サイクル、具体的な障害、拡大または縮小の兆候を確認します。重要な場合は、1〜2文をそのまま引用します。

ステップ3の出力: ブリーフィングに「混乱を招く要因」という短いセクション(箇条書きは最大2〜5項目)を追加します。特筆すべき内容がなければ、「過去60〜90日間、Slack/メール/ミーティングに最近の摩擦の兆候はありません」と記載します。重大な兆候(たとえば、先週のミーティングで解約リスクが判明したなど)が見つかった場合は、ドラフトを作成する前にいったん止まり、進めてよいか担当者に確認します。

ステップ 4 — 顧客の勢いを起点にする(Exa MCP)

mcp__claude_ai_Exa__web_search_exa を使います。

「[Customer name] product launches growth metrics 2026 blog announcements」

検索結果が少ない場合は、顧客の公式ブログ/ニュースページに対して mcp__claude_ai_Exa__web_fetch_exa を続けて実行します。過去6か月間の具体的なきっかけを2〜4件記録します。たとえば、新製品の発表、ユーザー数や売上に関する発表、パートナーシップなどです。これらは今あらためて連絡する理由として使うもので、購入する理由ではありません。

担当者が --no-anchors と指定した場合は省略します。

ステップ 5 — 担当者の文体を把握する(Slackのみ)

このドラフトを送るのは担当者です。一般的なPostHogの文体ではなく、担当者本人らしい文章にします。

Slack MCPが接続されている場合: ドラフト作成前に、顧客向けチャンネルで担当者が書いた最近のメッセージを15〜25件取得します。slack_search_public_and_private を from:me in:#posthog- で使用するか、他の人に代わって実行する場合は from:<rep_user_id> で絞り込みます。社内チーム向けのメッセージよりも、似たようなフォローアップの文脈(年間契約への移行、請求、利用拡大)で他の顧客に送ったメッセージを優先します。次の点に注目します。

  • 挨拶(hey/hi/挨拶なし)
  • 結びの言葉(名前/なし/絵文字)
  • 大文字・小文字の使い方(すべて小文字/文頭を大文字)
  • 句読点の頻度(簡潔な断片的表現/完結した文)
  • 絵文字の使い方(なし/時々/多用)
  • 婉曲さと率直さのバランス
  • 定型句や繰り返し使われる文の構成

内容ではなく文体をまねします。担当者が小文字中心で簡潔に書き、bufoの絵文字を使うなら、ドラフトも同じようにします。整った文章と完全な署名を使うなら、それに合わせます。

Slack MCPが接続されていない場合: Slackを接続すれば、このスキルが担当者自身の文体をまねられることを伝えます。利用できない場合は、ニュートラルで小文字中心の、飾り気のないPostHogの文体を基本にします。

ステップ5では担当者の文体を扱います。ステップ3では、顧客の最近のトーンを別途調べ、混乱を招く要因がないか確認します。顧客の文体をまねるのではなく、担当者の文体をまねしてください。

ステップ 6 — 担当者と割引の組み合わせを確認する

どの割引条件が適用されるかを尋ねます。上記の適用資格チェックに沿って回答を絞り込みます。決めつけないでください。

一般的な組み合わせ:

  • 標準の 1 年契約、契約日に確約(切り替え): 利用額の段階割引 + 相互コミットメント割引 5%
  • 2 年契約、前払い: 利用額の段階割引 + コミットメント割引 3% + 前払い割引 5%
  • 3 年契約、前払い: 利用額の段階割引 + コミットメント割引 5% + 前払い割引 5%
  • 早期更新(60 日以上前、クレジット残高あり): 利用額の段階割引 + 早期更新割引 5%
  • PAYG 終了後の再契約: 利用額の段階割引のみ(+5% なし)

見積もりを提示する前に、予測年間支出に照らして利用額の段階割引が妥当か確認します。

ステップ 7 — 3 つのシナリオを算出する
シナリオ予測 PAYG 支出算出方法
下限(成長なし)現在の MRR × 12確実な下限。成長が止まった場合も含みます
ベース直近の傾きを年換算したレートを適用最も根拠のある中間ケース
強気直近 1 年間の前年比を適用実績に基づく上限

それぞれについて、PAYG 支出 → 割引適用後のクレジット購入額 → 絶対額での節約額を算出します。

ステップ 8 — ブリーフィングを出力する

以下の 6 セクションを、この順番どおりに出力します。前後にも、セクション間にも何も追加しないでください。 Slack の下書きが最後です。

  1. 適用資格チェック — 1 行。プランの状態と適用可能な割引の組み合わせ。
  2. 推移 — 直近の MRR を 4~6 行で示す表を 1 つ + 成長の概要を 1 行。
  3. 交絡要因 — 箇条書きは最大 2~5 項目。各項目は 1 行。特に見つからなかった場合は、1 文で記載します。
  4. 計算 — 表は 1 つだけ。 3 行(下限 / ベース / 強気)。列は PAYG / 割引適用後 / 節約額。表の下に、適用される割引の組み合わせを 1 行で記載します。担当者が +5% の上乗せを示したい場合は、1 行だけ追加します(「相互コミットメント割引 +5% の場合:下限の節約額 → ~$X、ベース → ~$Y、強気 → ~$Z」)。2 つ目の表は追加しないでください。
  5. 勢いを示す指標 — Exa から最大 2~3 項目の箇条書き。各項目は 1 行。
  6. Slack の下書き — 以下のルールに従い、プレーンテキストで記載します。

厳禁事項(実際に起きたことがあるため、必ず守ってください):

  • TL;DR、「要点」、「下書きについてのメモ」、「推奨事項」、「要判断」、「次のステップ」、または Slack の下書きの後に説明セクションを追加しないでください。担当者が追加情報を必要とすれば、尋ねてきます。
  • 別の割引の組み合わせについて、2 つ目の計算表を追加しないでください。表は 1 つだけです。
  • セクション間に説明の段落を挟まないでください。
  • 適用資格チェックの内容を他のセクションで繰り返さないでください。

6 つのセクション内にどうしても表現できないこと(例:「解約の兆候がある中で進めるべきか?」)がある場合は、交絡要因セクションの最後に 「進めるべきか、それとも X が解決するまで保留すべきか?」 のような質問を斜体で 1 文だけ追加し、そこで終わります。「要判断」のブロックは追加しないでください。

Slack の下書きのルール

  • プレーンテキストのみ。 引用ブロックで囲まないでください。箇条書きや番号付きリストのマーカーは使わないでください。段落間には空行を入れてください。
  • 担当者の話し方に合わせてください(ステップ 5 に従います)。
  • 短い段落は最大 3 つ。
    • 第 1 段落:相手の勢いや、前回のやり取りから変わったことをきっかけにする。依頼から始めないでください。
    • 第 2 段落:下限ケースでの金額ベースの節約額 + 割引の組み合わせについて混乱が生じそうな場合は、その説明を 1 行で加えます(例:利用額の段階割引とクレジットの違い)。
    • 第 3 段落:無視する以外の選択肢もある、具体的な質問をします(例:「今年は年間予算の確保が可能でしょうか。それとも、ベンダー支出の管理方法としては月ごとの支払いが合っていますか?」)。
  • 見積もりの URLは、担当者から提示された場合にのみ記載します。URL を捏造しないでください。
  • 人工的な緊急性を演出しないでください。「四半期末に期限切れ」や「期間限定」などの表現は使いません。相互コミットメント割引 +5% は、期限ではなく、条件を満たすことで得られる割引です。
  • 「質問があればお知らせください」や「いつでも喜んでお話しします」で締めないでください。 実際の質問に置き換えてください。
  • 名前で呼びかけます(主な連絡先)。担当者が Slack のメンションを提示した場合のみ、<@USER_ID|Name> 形式を使います。それ以外はファーストネームだけを使います。

してはいけないこと

  • Obsidian 形式のプロフィールファイル、日付入りの調査ファイル、またはボルト関連の成果物を作成しないでください。これらは個人のワークフローに関するものであり、スキルの出力対象ではありません。
  • 割引率を一律に設定しないでください。担当者が適用する条件を指定し、スキルが計算を行います。
  • 適格性チェックのステップ 1 で条件を確認せずに、相互コミットメントの+5%や早期更新の+5%を提示しないでください。
  • 草案にあいまいな表現や感謝の言葉、「念のため確認です」といった文言を付け足さないでください。
  • ボリューム割引(クレジット購入時のみ適用可能)と、相互コミットメント/コミットメント期間/支払い時期に関する追加割引を混同しないでください。これらは併用できるため、担当者が混同している場合は、別々に明記してください。
  • PAYG の顧客が「25%のボリューム割引を受けている」と主張しないでください。PAYG に適用されるのは段階制の単価のみです。
  • 切迫感をあおったり、四半期末を持ち出したりしないでください。PostHog はそのような売り方をしません。
  • ステップ 3(交絡変数の確認)を省略しないでください。計算上は優れた提案でも、進行中のエスカレーションに送れば、何も提案しないより悪い結果になることがあります。

担当者が追加情報を求めた場合

ファイルへの保存を求められた場合は、保存先のパスを尋ねてください。より長い説明を求められた場合は、インラインで詳述してください。デフォルトでは、上記の簡潔な概要を使用します。

コメント