posthog-inbound-leads

PostHog インバウンドリードの対応方針

Salesforce からのインバウンドリードを評価し、返信メールの下書きを作成するか、対応方針を提案します。このスキルは、インバウンドの営業問い合わせに対応する PostHog TAE 向けです。

基本的なワークフロー

1. リードのコンテキストを取り込む — TAE から提供された情報（Salesforce のフィールド、メール本文、メモ）を確認します
2. 既存アカウントのコンテキストを Vitally で確認する — リードのメールアドレスとメールドメインで検索します（以下のステップ 0 を参照）
3. 会社について調査する — ウェブ検索で、会社の概要、資金調達状況、規模、成長の見通しを把握します（以下のステップ 1 を参照）
4. ユースケースを特定する — 会社の調査結果を踏まえて、リードを PostHog の 6 つのユースケースのうち 1 つ以上に当てはめます（以下のステップ 2 を参照）
5. リードを評価する — 会社の調査結果と成長の見通しを踏まえて、対応方針のフレームワークを適用します（以下のステップ 3 を参照）
6. 対応方針を提案する — 推奨するアクションと特定したユースケースを明確に示します
7. 返信を下書きする — ユースケースに沿った適切なメールを作成します（以下のステップ 4 を参照）
8. すべての URL を検証する — 下書きのメールに含まれるすべてのリンクを取得し、アクセスできることと意図したコンテンツを指していることを確認します（以下のステップ 5 を参照）

ステップ 0：既存アカウントのコンテキストを Vitally で確認する

リードの評価やメールの下書きを始める前に、Vitally でこのリード（またはその会社）がすでに PostHog を利用しているか確認します。これによって、対応方針やメールの組み立て方が大きく変わります。支援を求めている既存顧客と、新規のインバウンドリードとでは対応が異なります。

確認する項目

リードのメールアドレスを使って、Vitally で次の 2 つの検索を実行します。

1. メールアドレスで完全一致検索する — vitally:search_users で email にリードのメールアドレスを設定します。この人物がすでに PostHog アカウントを持っているかどうかがわかります。
2. メールドメインで検索する — vitally:search_users で emailSubdomain にリードのメールアドレスのドメイン部分（例：[email protected] の acme.com）を設定します。同じ会社の誰かがすでに PostHog を利用しているかどうかがわかります。

いずれかの検索結果がある場合は、ユーザーレコードの accountId を使って vitally:get_account_full で関連アカウントを取得します。概要をすばやく確認するには、detailLevel: "summary" を使います。

検索結果の活用方法

リード本人のメールアドレスが既存ユーザーの場合：

• すでに PostHog を利用しています。メールではそのことに触れ（「すでに PostHog をご利用いただいていることを確認しました」）、オンボーディング向けのリソースではなく、具体的な問い合わせ内容に焦点を当てます。
• アカウントの MRR とヘルススコアを確認します。セルフサービスのユーザーが利用拡大のために連絡しているのか、既存アカウントに拡大の機会があるのかを判断する参考になります。

同じ会社の別の人物がすでにユーザーの場合：

• その会社はすでに PostHog を利用しています。メールでそのことに触れ（「御社のチームがすでに PostHog をご利用いただいていることを確認しました」）、今回の依頼が既存の利用状況とどう関係するのかを尋ねます。
• アカウントにほかに誰がいるか確認します。リードは別途評価を始めるのではなく、社内の推進者と連携する必要があるかもしれません。
• すでに担当 TAE が割り当てられている場合は、担当顧客を侵害しないよう、その旨を明示します。

Vitally に検索結果がない場合：

• 新規リードです。以下の標準的な評価ワークフローに進みます。

TAE に共有する情報

Vitally の調査結果を報告するときは、次の情報を含めます。

• 該当する人物または会社が見つかったかどうか
• アカウント名と現在の MRR（該当する場合）
• ヘルススコア（該当する場合）
• 割り当て済みの TAE（いる場合。ルーティング上重要です）
• アカウントのユーザー数
• 対応への影響に関する 1 行の提案（例：「月額 3,000 ドルの既存アカウントで、担当 TAE は未割り当てです。新規リードではなく、利用拡大の機会です」）

ステップ 1：会社について調査する

このステップはすべてのリードで必須です。 リードのフォーム送信内容だけでは、評価や見送りを判断する情報として不十分です。月間アクティブユーザー数（MAU）が 1 万人のリードでも、60 億ドル規模のスタートアップと従業員 5 人の代理店では、対応方針がまったく異なります。

調査する内容

会社について把握するため、ウェブ検索を1〜3回行います。まず会社名とドメインから始めます。

• [Company Name] [domain] を web_search で検索 — 基本情報を確認します。事業内容や会社の概要を調べます。
• [Company Name] funding employees を web_search で検索 — 企業情報を確認します。資金調達段階、従業員数、成長の兆候を調べます。
• 注目度が高い会社、または資金調達が順調な会社と思われる場合は、最近のニュースを検索します。[Company Name] 2026 または [Company Name] news

抽出する内容

調査結果から、次の情報を特定して記録します。

シグナル	重要である理由	例
何を開発しているか	ユースケースとの対応関係や、ICPに該当するかどうかを判断できます	「製造業向けAIツール」→ AI／LLMのオブザーバビリティが関連
資金調達段階と金額	予算や成長の見通しを推測できます	シリーズB、5,000万ドル → ツールに使える予算がある可能性が高い
従業員数	支出の可能性やチームの複雑さを推測できます	従業員200人 → 複数のチームやプロジェクトの可能性
エンジニアリングチームの規模または比率	PostHogの購入者はエンジニアです。エンジニアが多いほど適合度が高まります	「チームの80％がエンジニア」→ ICP適合度を示す強いシグナル
成長の軌跡	現在のMAUが上限なのか、下限なのかを判断できます	設立から6か月で積極的に採用中 → MAUは急増する見込み
最近のニュース	買収、ローンチ、事業転換など、状況を変える動きを把握できます	AIスタートアップを買収したばかり → 製品領域を拡大中
ビジネスモデル	SaaS、マーケットプレイス、開発ツール、代理店などを把握できます	B2B SaaS → PostHogの典型的なICP

成長の軌跡を分類する

調査に基づき、会社を次の4つの成長の軌跡のいずれかに分類します。

• 加速中：最近、大規模な資金調達を実施した（特に過去12か月以内）、積極的に採用している、十分な資金を持つアーリーステージ企業である、または急速に拡大している明確な兆候がある場合です。現在のMAUが上限である可能性はほぼありません。例：十分な資金を調達したシリーズA以降のスタートアップ、大型資金調達を実施したばかりの会社、「募集中の職種が数百件」ある会社。
• 安定：確立された会社で、成長は緩やかかつ予測可能です。現在のMAUは、短期的な支出を推測する妥当な指標です。例：収益が安定したミッドマーケットSaaS、成熟したPLG企業。
• 初期／不明：新しい会社で、公開情報が限られているため、成長の軌跡を評価しにくい状態です。現在のMAUを入手可能な最善の指標として扱いますが、不確実性があることを記録してください。例：プレシードのスタートアップ、公開情報がないステルスモードの会社。
• 横ばい／縮小中：成長の兆候がない、レイオフがあった、または事業縮小の兆候がある状態です。現在のMAUは、将来の支出を過大に見積もる可能性があります。例：最近レイオフを実施した会社、チームが縮小している会社。

成長の軌跡の分類は、適格性の判断に直接影響します。 $20Kの基準にどう反映するかについては、ステップ3を参照してください。

複数製品のシグナルを検出する

調査中は、見込み顧客の会社が複数の製品を持っている（または開発中である）ことを示すシグナルに注意します。各製品は通常、独自のイベント量を持つ個別のPostHogプロジェクトになるため、支出を押し上げる要因です。

見込み顧客のメッセージに含まれるシグナル：

• 「自社製品の一部」／「複数の製品」／「ポートフォリオ全体」
• 「複数のチーム」／「いくつものチーム」／「異なる事業部門」
• 「プラットフォームとアプリ」／「ウェブアプリとモバイルアプリ」
• 「自社のスタックに統合」（幅広い用途を示唆）

会社の調査から得られるシグナル：

• 会社に複数の製品ラインまたはブランドがある
• 会社が最近ほかの会社を買収した（買収先が独自の製品を持つ可能性がある）
• 求人情報で複数の製品チームに言及している
• 会社のウェブサイトに、明確に異なる複数の製品が掲載されている

複数製品のシグナルがある場合は、推定製品数（または範囲）を記録し、MAUの倍率に反映します。MAUがそれぞれ1万の製品を5つ持つ会社は、MAUが1万の案件ではなく、5万の案件です。

AI/ML 企業のシグナルを検出する

企業調査で、その企業が AI ネイティブ（AI/ML 製品の開発を中核事業としている）であることが判明した場合は、リードのメッセージに AI、LLM、モデルのコスト、プロンプトについての言及がなくても、AI/LLM オブザーバビリティを有力な副次的ユースケースとしてフラグ付けします。

AI ネイティブのシグナル：

• 企業の説明で、開発の中核として AI、ML、LLM、または「人工知能」に言及している
• AI に関連する業界（AI インフラストラクチャ、AI アプリケーション、AI 研究）に属している
• チームの大部分を ML/AI エンジニアが占めている
• 最近、AI 関連の買収や製品のローンチがあった

検出した場合は、ユースケースの評価に AI/LLM オブザーバビリティを含め、リードから質問されていなくても、関連する機能としてメールで触れます。次のように説明します。「AI 製品を開発されているため、モデルのコストやパフォーマンスを追跡できる LLM 分析もお役に立つかもしれません。」

TAE に提示する情報

企業調査の結果を、次の項目を含む簡潔なプロフィールとして提示します。

• その企業が何をしているか（1 文）
• 資金調達と企業価値（情報が得られる場合）
• 従業員数とエンジニアリング部門の構成（情報が得られる場合）
• 成長軌道の分類
• 複数製品に関するシグナル（あれば）
• AI ネイティブのフラグ（該当する場合）
• 注目すべき情報（最近のニュース、買収、経営陣など）

これは Vitally の調査結果の直後、ユースケースの評価の前に記載します。

ステップ 2：ユースケースを特定する

すべてのリードは、PostHog の 6 つのユースケースのうち 1 つ以上に該当します。ユースケースを特定することで、回答の組み立て方、注目する製品、リンクするリソースが決まります。該当するユースケースを判断するには、担当者／ペルソナ、企業（ステップ 1 の調査結果を考慮）、メッセージを評価します。

6 つのユースケース

ユースケース	達成すべきこと	主な購入者ペルソナ	リードに見られる主なシグナル
プロダクトインテリジェンス	「ユーザーが何をしているのか、なぜそうするのか、次に何を開発すべきかを理解できるようにする。」	PM、デザイナー、プロダクトエンジニア、創業者	アナリティクス、ファネル、リテンション、ユーザー行動、「ユーザーが離脱する理由」、機能の利用状況、NPS、アンケート、UX 調査のためのセッションリプレイへの言及
リリースエンジニアリング	「問題を起こさずに、より迅速にリリースできるようにする。」	エンジニアリングマネージャー、プラットフォームチーム、開発者	フィーチャーフラグ、段階的なロールアウト、リリースの A/B テスト、キルスイッチ、プログレッシブデリバリー、LaunchDarkly の置き換えへの言及
オブザーバビリティ	「問題の発生を把握し、原因を理解して、迅速に修正できるようにする。」	SRE、プラットフォームエンジニア、DevOps	エラートラッキング、バグの再現、Sentry/Datadog の置き換え、ロギング、インシデント対応、スタックトレースへの言及
グロース＆マーケティング	「獲得、コンバージョン、収益を促進する要因を理解できるようにする。」	グロースエンジニア、マーケティング責任者、CRO、GTM エンジニア	アトリビューション、ROAS、キャンペーンのパフォーマンス、GA4/Segment の置き換え、コンバージョン最適化、オンボーディングの自動化、マーケティングスタックの統合への言及
AI/LLM オブザーバビリティ	「AI 機能のパフォーマンス、コスト、ユーザーとのインタラクションを理解できるようにする。」	AI/ML エンジニア、AI PM、AI 分野の創業者	LLM、AI 機能、モデルのコスト、プロンプトのテスト、AI の品質、Langfuse/Helicone の置き換え、トークン使用量への言及。企業調査から推定する場合もあります — 企業が AI ネイティブであれば、リードが言及していなくてもこのユースケースが該当します。
データインフラストラクチャ	「プロダクトデータとビジネスデータを統合し、必要な場所へ届けられるようにする。」	データエンジニア、アナリティクスエンジニア、プロダクトオペレーション担当者	データウェアハウス、Snowflake/BigQuery、データパイプライン、バッチエクスポート、PostHog のデータと Stripe/CRM のデータの統合、Segment/Fivetran の置き換えへの言及

ペルソナからユースケースを特定する

その人の役職は、最も有力な判断材料の1つです。

• PM、プロダクト責任者、UX リサーチャー、デザイナー → プロダクトインテリジェンス
• エンジニアリングマネージャー、エンジニアリング担当 VP、プラットフォームエンジニア、開発者 → リリースエンジニアリング（エラーやインシデントに言及している場合はオブザーバビリティ）
• SRE、DevOps、インフラエンジニア → オブザーバビリティ
• グロースエンジニア、マーケティング責任者、CRO、GTM エンジニア、デマンドジェン担当者 → グロース＆マーケティング
• AI/ML エンジニア、AI PM、AI スタートアップ創業者 → AI/LLM オブザーバビリティ
• データエンジニア、アナリティクスエンジニア、データ責任者、RevOps 担当者 → データインフラストラクチャ
• 創業者／CTO（創業初期） → 通常は、製品に応じてプロダクトインテリジェンスまたは AI/LLM オブザーバビリティです。複数のユースケースにまたがる場合もあります。

企業からユースケースを特定する

企業の種類（ステップ1の調査から）が、候補を絞り込むのに役立ちます。

• AI ネイティブのスタートアップ → AI/LLM オブザーバビリティがほぼ常に関連し、多くの場合、プロダクトインテリジェンスも併せて必要です
• PLG 型 SaaS → プロダクトインテリジェンスとグロース＆マーケティングの組み合わせが最も一般的です
• 複数のチームがあるエンタープライズ企業 → 1つのユースケースから始めることが多いものの、拡張先は複数にわたります
• E コマース／マーケットプレイス → グロース＆マーケティング（コンバージョン、アトリビューション）＋プロダクトインテリジェンス（ユーザー行動）
• 開発者向けツール／インフラストラクチャ → リリースエンジニアリング＋オブザーバビリティ

メッセージからユースケースを特定する

具体的な要望は、ペルソナや企業の情報から得た判断を裏付けたり、覆したりします。

• 「ユーザー行動を把握したい」 → プロダクトインテリジェンス
• 「フィーチャーフラグが必要」または「LaunchDarkly から置き換えたい」 → リリースエンジニアリング
• 「エラー追跡が必要」または「Sentry から置き換えたい」 → オブザーバビリティ
• 「アトリビューションを把握したい」または「GA4 から置き換えたい」 → グロース＆マーケティング
• 「AI 機能を開発している」または「LLM のコスト」 → AI/LLM オブザーバビリティ
• 「Snowflake にデータを取り込みたい」 → データインフラストラクチャ
• 「機能を見せてほしい」「デモを見たい」といった漠然とした要望 → メッセージだけではユースケースを判断できません。企業調査を使って、最も可能性の高いユースケースを推測し、確認のために焦点を絞った質問をします

企業調査を行ってもユースケースが曖昧な場合は、候補を絞り込むための質問をメールに含めてください。PostHog の製品ではなく、相手の課題に焦点を当てた質問にします。「解決しようとしている主な課題は何ですか？」は、「どの PostHog 製品に興味がありますか？」よりも適切です。

複数のユースケース

複数のユースケースに当てはまるリードは多くいます。その場合は、次のように対応します。

• 主なユースケースを最初に取り上げます — 相手が明言した課題に最も合致するものです
• 副次的なユースケースは自然な拡張として紹介します — 「PostHog は X にも対応しており、チームが Y に取り組むようになると必要になることがよくあります」
• プラットフォーム全体を売り込もうとしないでください — 相手が相談に来た課題の解決に集中します

ステップ3：リードを見極める

成長軌道による基準の適用除外

年間支出額が2万ドルという基準がデフォルトの適格ラインですが、成長軌道によってはこの基準を適用しない場合があります。

以下の条件をすべて満たす場合、現在のMAUだけでは2万ドルに達しなくても、電話での相談の対象とします。

1. 成長軌道が「加速中」 — 最近の大規模な資金調達、積極的な採用、大きな資金を持つアーリーステージ企業
2. 企業として高い価値を示すシグナルがある — 以下のうち少なくとも2つに該当：1,000万ドル以上の資金調達、従業員50人以上、エンジニアリング中心のチーム、複数の製品、AIネイティブ
3. 12か月以内に2万ドルに達する妥当な道筋がある — 成長軌道と複数製品による倍率を踏まえると、規模の拡大に伴って基準に達する可能性がある

基準の適用除外が該当する場合は、判定にその旨を明記してください：「現在のMAUは1万で2万ドルの基準を下回っていますが、成長軌道は加速中です（［資金調達額Xドル、従業員数Y人など］）。複数製品への展開も見込めます。成長軌道に基づき、電話での相談の対象とします。」

基準の適用除外が該当しない場合：

• 成長軌道が「安定」、「初期段階／不明」、または「横ばい」の場合は、現在のシグナルに基づく2万ドルの基準を適用します
• 資金調達済みであっても、リードのユースケースが限定的で、拡大する可能性が低い場合（例：十分な資金を持つ企業が、社内ツール1つでのフィーチャーフラグについて問い合わせている）
• リードが大企業に所属していても、PostHogを利用するチームがごく小規模で、拡大の道筋がない場合

複数製品による支出額の倍率

複数製品を示すシグナルが検出された場合（リードのメッセージまたは企業調査から）、MAUの推定値を調整します。

• 申告されたMAU × 製品数の推定値 = 調整後のMAU推定値
• 適格性の判断には、申告されたMAUそのものではなく、調整後の推定値を使用します
• 判定には倍率を明記します：「申告されたMAUは1万ですが、『当社の製品の一部』という表現と企業調査から、3～5製品と推定 → 調整後のMAUは3万～5万」

この倍率は推定値であり、保証ではありません。「基準を確実に下回る」から「基準を上回る可能性があり、確認のために電話で相談する価値がある」へと判定を変えるものです。

特別なケース：競合製品からの乗り換え

見込み客が、現在競合製品を利用しており、乗り換えを検討していると伝えてきた場合（例：「Heapを使っているが、乗り換えたい」「Amplitudeを置き換えたい」「Sentryの代替製品を評価中」「LaunchDarklyから移行したい」）、これは有望度の高いインバウンドリードです。すでにそのカテゴリのツールに予算を割り当てており、ニーズが明確で、緊急性も高い可能性があります。

ただし、（成長軌道による例外が適用される場合を除き）20,000ドルの下限は引き続き適用されます。 競合製品からの乗り換えを検討している見込み客も、通話の対象となるには年間20,000ドル以上の支出が見込める必要があります。有料ツールから乗り換えるという理由だけで、通話を提案しないでください。

競合製品からの乗り換えを検討している見込み客への最初の返信では、通話を提案したりセルフサービスに案内したりする前に、BANTのシグナルを確認してください。 以下を明らかにする、的を絞った質問をしてください。

• 予算： 乗り換えを検討している理由は何ですか？ コスト、機能不足、データの所有権、それともほかの理由ですか？（コストが理由なら、すでに予算があることを示しています。）
• 決裁権： 意思決定には誰が関わっていますか？ エンジニアリング主導の評価ですか、それともトップダウンの指示ですか？
• ニーズ： [競合他社]では解決できず、PostHogで解決したいことは何ですか？ [製品]だけを置き換えたいですか、それともリプレイ、フラグ、実験などの追加機能も含めて統合したいと考えていますか？
• 導入時期： どのくらいの期間で意思決定したいと考えていますか？（最初のメールでは尋ねず、自然に明らかになるのを待つか、フォローアップで尋ねてください。）

最初のメールで4つすべてのBANTシグナルを確認する必要はありません。 重要な未確認事項を明らかにする質問を1〜2個してください。通常は、予算（なぜ乗り換えるのか）とニーズ（現在のツールに加えて何を求めているのか）です。決裁権と導入時期は、返信の中で明らかになるのを待ちましょう。

見込み客からBANTに関する情報が返信された後：

• 回答から20,000ドル以上の可能性と具体的なユースケースが確認できた場合 → 通話の対象として適格と判断し、カレンダーを案内します
• 小規模チーム、支出額の低さ、単純な置き換えが明らかになった場合 → 具体的な移行リソースを案内してセルフサービスに誘導します
• BANTの情報を得る前に見込み客から通話を求められた場合 → カレンダーを案内しても構いませんが、PostHogの評価に必要な情報（料金、ドキュメント、無料登録）はすべて公開されているため、並行して評価を始められることも伝えてください

特別なケース：有望な企業からの曖昧な問い合わせ

見込み客のメッセージが曖昧で（例：「検討を始めたい」「詳しく知りたい」「PostHogに興味がある」）、企業調査から有望なアカウントだと分かった場合、安易にセルフサービスへ誘導しないでください。

有望な企業からの曖昧な問い合わせは、「通話をするほど本気ではない」ではなく、「ニーズの確認が必要」として扱ってください。対応方針は「質問でニーズを確認し、通話の対象として適格か判断する」です。

有望な企業を示す指標（以下のうち2つ以上に該当する場合）：

• 調達資金の総額が1,000万ドル以上
• 従業員数が100人以上
• 全従業員に占めるエンジニアリングチームの割合が40%を超える
• 複数製品を示す兆候がある
• AIネイティブ企業
• 成長軌道が「加速中」に分類される
• 知名度の高いブランド、または著名な創業者／経営陣がいる

このような見込み客へのメールでは、以下を行ってください。

• ユースケースを決めつけずに、関心を持っていることを伝える
• 何を解決しようとしているのかを把握するため、質問を1〜2個する
• 調査結果を踏まえ、企業のタイプに最も関連性の高いPostHogの機能を1〜2個紹介する
• PostHogが既存の技術スタックにどう適合するかを説明する通話を提案する

判定：営業対応の対象

以下のすべてに該当する必要があります。

• 年間支出の見込みが 20K ドル以上（現在の MAU、多製品向け乗数を適用した調整後の MAU、または成長軌道による例外判断に基づく）
• エンジニアが参加している、または通話に参加する予定である
• 具体的かつ明確なユースケース（上記6つのうち少なくとも1つに対応するもの）がある、または高価値企業からの曖昧な問い合わせである（上記の特別なケースを参照）
• 企業規模と製品ニーズから、営業支援型の対応が妥当である

対象と判断した場合は、以下を含む返信を作成します。

• 相手の具体的なユースケース（または、高価値企業からの曖昧な問い合わせの場合は、企業の状況と想定されるユースケース）に言及する
• 該当するユースケースのプレイブックから、的を絞った確認質問を1～2つする
• 通話の日程調整を提案する

判定：セルフサービスへ案内

以下のいずれかに該当する場合です。

• 企業規模、調査結果、成長軌道を踏まえると、例外判断を適用しても支出の見込みが 20K ドルを明らかに下回る
• 少ない利用規模が明示されており（例：「MAU 1,000」「小規模チーム」「始めたばかり」）、企業調査からもそれが上限であることが確認できる（小規模企業で、成長が横ばい）
• 具体的なユースケースのない曖昧な問い合わせで、企業調査から高価値アカウントと判断できない
• エンジニアの関与について言及がなく、今後の参加も見込まれない
• 具体的な内容のない「詳細を知りたい」「デモを見たい」といった一般的な問い合わせで、企業調査を行っても状況が変わらない

以下を含む役立つメールを作成します。

• ユースケースに合わせたリソースを使って質問に回答する
• 特定されたユースケースに最も関連する製品ドキュメントへのリンクを提示する
• セルフサービスの窓口（アプリ内サポート、コミュニティ）を案内する
• 通話を提案しない

判定：スタートアッププランへ案内

• 企業が創業初期段階で、スタートアッププランの対象となる可能性がある
• スタートアッププランの申請へ案内する
• 直近の営業機会としては対象外と判断する

判定：対象外

• 明らかに ICP ではない（対象業種ではない、プロダクトエンジニアリングに関するユースケースがない）
• スパムまたは無関係な問い合わせ
• 返信不要、または簡潔で丁寧な辞退を返す

除外理由とメモ

「電話での適格性確認」以外の判定を推奨する場合は、必ず除外理由（以下のリストから選択）と除外メモ（250文字以内で、具体的かつ Salesforce の除外メモ欄にそのままコピー＆ペーストできる内容）を記載してください。

選択可能な除外理由：

• BAA / DPA Request
• Below Sales Assist Threshold - Pass
• Below Sales Assist Threshold - Prospect
• Billing Support Request
• Business Closed
• Duplicate Lead
• Event request
• Existing customer inquiry
• Feedback
• Invalid Contact Info
• No Budget
• No Current Need
• No Product Fit
• No Response - Pass
• No Response - Prospect
• No Technical Resource
• Non-Commercial
• Not a Good Fit
• Other
• Partnership request
• Resource Constraints
• Self-Hosted Requirement
• Spam
• Stale - autoclosed
• Startup Plan / YC
• Support Request
• Using Competitor / Unsolicited RFP

適切な理由の選び方：

• Below Sales Assist Threshold - Pass：成長軌道による例外条件に該当せず、現実的な成長見込みもないため、潜在価値が 2 万ドル未満の場合に選択します。セルフサービスに案内する小規模企業に使用します。
• Below Sales Assist Threshold - Prospect：現時点では 2 万ドル未満ですが、企業が基準に達するまで成長する兆候（例：最近の資金調達、チームの拡大）がある場合に選択します。後日、再検討する価値があります。成長軌道が有望であるものの、まだ例外条件を満たしていない場合に使用します。
• BAA / DPA Request：リードが BAA または DPA を必要としている場合に選択します。注：標準の BAA（修正なし）は Boost アドオン（月額 250 ドル＋使用量ベースの料金）から、カスタムまたは修正済みの BAA は Enterprise（年払いで月額 2,000 ドル）から利用できます。リードの主なニーズが HIPAA/BAA で、該当する料金情報を案内した場合に、この理由を使用します。
• No Technical Resource：連絡先が非技術職で、エンジニアの関与が言及されておらず、今後も関与する見込みがない場合に選択します。
• Startup Plan / YC：スタートアッププランの申請に案内するアーリーステージ企業に使用します。
• Support Request：PostHog の購入を検討しているのではなく、サポートに関する質問をしている場合に選択します。
• Existing customer inquiry：すでに PostHog を利用していて、製品または請求に関する質問をしている場合に選択します。新しい営業機会ではありません。
• No Product Fit：必要としている機能が PostHog の得意分野ではない場合（例：セルフホストの要件、業界の不一致）に選択します。

除外メモは具体的で、そのままコピー＆ペーストできる内容にしてください。 除外を正当化する主要なデータポイントと、企業調査で得た関連情報を記載します。

良い除外メモ：

• 「従業員 30 人の e コマース代理店、売上 100 万～1,000 万ドル。マーケティング職で、エンジニアはいない。無料プランで MAU 25 万人。機能フラグに関する質問に回答し、セルフサービスに案内。」
• 「ベイエリアの非営利団体、MAU 2 万人、ICP -5。シニアプロダクトディレクターで、有望なユースケースはあるものの、2 万ドルの基準を大きく下回る。BAA は Boost（月額 250 ドル）で利用可能。HIPAA とファネルに関するガイダンスを添えてセルフサービスに案内。」
• 「従業員 15 人のシード期スタートアップ。開発者が機能フラグについて問い合わせ。無料プランでニーズを満たせる。ドキュメントとアプリ内サポートを案内。」
• 「従業員 5 人の売上前スタートアップ。資金調達は確認できず。MAU 2,000 人。「もっと詳しく知りたい」という曖昧な問い合わせ。セルフサービスに案内し、スタートアッププランの申請を提案。」

悪い除外メモ：

• 「適合しない」（曖昧すぎる）
• 「小規模企業」（どの兆候が重要なのか不明）
• 「セルフサービスに案内」（理由が不明）
• 「MAU が少ない」（企業自体が小規模なのか、製品がまだ初期段階なだけなのかを確認しましたか？）

ステップ 4：返信メールを作成する

下書きを作成する前に、references/writing-style.mdを読んでください。主なルール：

• 要点を簡潔に伝えます。 長い前置きや冗長な表現、企業用語は避けます。
• 売り込みではなく、役に立つ内容にします。 具体的な案内で相手の問題を解決します。
• 明確な見解を示します。 「場合によります」と曖昧にせず、進むべき道を勧めます。
• PostHog の製品ではなく、相手のユースケースを軸にします。 製品名ではなく、相手の問題解決について話します。
• 企業調査を活用して、相手に合わせた内容にします。 相手が何を開発しているか分かっている場合は、それに触れます。「製造業向けの AI ツールを開発されているとのことですので」は、「分析ツールをご検討中とのことですので」よりも適切です。
• リンクはアンカーテキストに埋め込みます。 URL をそのまま貼り付けたり、「こちらをクリック」と書いたりしないでください。
• 書式は最小限にします。 リソースや手順を列挙するときだけ箇条書きを使います。会話調を保ちます。
• メール内の質問は最大 1 つにします。 相手を圧倒しないようにします。

メールの構成

1. 簡潔で親しみやすい挨拶
2. 相手の状況やユースケースに言及する（企業調査を踏まえる）
3. 相手のユースケースに合わせた回答、案内、リソースを提供する
4. 明確な次のステップ（セルフサービスでの操作、スケジュール調整リンク、または「ご質問があればご返信ください」）
5. 簡潔な結びの言葉

ステップ 5：すべての URL を検証する

このステップは必須です。 メールの下書きを提示する前に、メールに含まれる URL をすべてweb_fetchで取得して、以下を確認します。

1. URL にアクセスできること — 200 ステータスが返され、404 や一般的なページへのリダイレクトではないこと
2. 内容が目的に合っていること — リンク先のページが、リンクの目的に合った内容を実際に扱っていること（例：「Feature Flags を始める」と表示されたリンクは、一般的なドキュメントのトップページではなく、Feature Flags の開始ページに移動する必要があります）

URL の検証に失敗した場合：

• web_searchで posthog.com を検索し、正しいページを探します（例：「posthog docs feature flags getting started」）
• 壊れたリンクを正しいリンクに置き換えます
• そのリソースに有効なページが存在しない場合は、壊れたリンクを送らずに削除します

重要な理由： PostHog のドキュメント構成は変更されます。以下のリソース一覧にある URL は出発点ですが、移動されている可能性があります。営業メールに壊れたリンクがあると、信頼を損ないます。送信前に必ず検証してください。

ユースケース別のリンク先リソース

プロダクトインテリジェンス

• プロダクト分析のドキュメント
• ファネル
• セッションリプレイ
• アンケート
• 実験

リリースエンジニアリング

• Feature Flags のスタートガイド
• 実験
• セッションリプレイ（ロールアウトのデバッグ用）

オブザーバビリティ

• エラートラッキング
• セッションリプレイ（エラーのコンテキスト確認用）

グロースとマーケティング

• ウェブ分析
• マーケティング分析
• データパイプライン
• ワークフロー

AI／LLM オブザーバビリティ

• AI エンジニアリング／LLM オブザーバビリティ
• 実験（プロンプト／モデルのテスト用）

データインフラストラクチャ

• データウェアハウス
• バッチエクスポート
• リアルタイムの送信先

一般（すべてのユースケース）

• インストールガイド
• 料金ページ
• コミュニティの質問
• HIPAA コンプライアンスガイド
• BAA ジェネレーター
• アプリ内サポートボタン（製品に関する質問では必ず案内してください）
• 無料プラン：月間 100 万イベント、すべてのコア機能を含む

BAA／HIPAA の料金に関する参考情報

見込み顧客が HIPAA、BAA、または医療データに言及した場合は、次の料金情報を使用してください。

標準 BAA（修正なし）：

• Boost アドオンで利用可能。月額 250 ドル＋使用量に応じた料金
• Scale および Enterprise のアドオンでも利用可能
• PostHog が副署するための BAA は、posthog.com/baa で生成できます

カスタム／修正済み BAA：

• Enterprise プランが必要。月額 2,000 ドル（年払い）＋使用量に応じた料金
• 標準 BAA の条項を変更したい顧客に限り必要です

重要な説明方針： 標準的な選択肢として Boost を最初に案内してください。月額 250 ドルは、非営利団体や小規模企業を含むほとんどの組織にとって利用しやすい価格です。Boost を十分に利用できる見込み顧客まで遠ざけてしまうため、最初から「エンタープライズ料金」を案内しないでください。

PHI と非 PHI が混在するデータを扱う見込み顧客向けの実務上の注意： ファネルやデータフローの一部のみが PHI に関係する場合、PHI に関係する部分の BAA を整える間に、無料プランですぐに非 PHI のアクティビティの追跡を開始できます。

非営利団体向け割引の参考情報

PostHog は、クレジット購入に対して非営利団体向けの割引を提供しています。

• 25,000 ドル未満のクレジット購入： 15％割引
• 25,000～100,000 ドルのクレジット購入： 標準のボリューム割引に加えて、さらに 5％割引
• 100,000 ドルを超えるクレジット購入： 標準のボリューム割引を適用（非営利団体向けの追加割引なし）

対象となるには、顧客は自国の非営利団体の定義（原産国の税法）に該当することを証明する書類を提出する必要があります。

注： MAU が少なく、使用量が無料プランの範囲内に収まる場合、非営利団体向け割引はまだ関係ありません。主な費用はプラットフォームのアドオン（BAA 用の Boost など）になります。成長した際に利用できるよう、割引があることを案内してください。

出力形式

TAE への回答では、必ず次の内容を含めてください。

1. Vitally での確認結果 — 見込み顧客またはその会社が Vitally で見つかったかどうかと、その意味
2. 会社調査 — ウェブ調査に基づく簡潔なプロフィール：事業内容、資金調達、従業員数、成長の軌跡、複数製品を展開している兆候、AI ネイティブかどうか
3. ユースケースの評価 — この見込み顧客が該当する 6 つのユースケースのうちどれか、その理由（担当者の属性、会社調査、メッセージに基づく）
4. 対応方針の推奨 — 適格と判断／セルフサービス／スタートアッププラン／対象外
5. 対象外とする理由 — 選択肢から選択（通話の対象として適格と判断する場合を除き、すべての対応方針で必須）
6. 対象外とする際の注記 — 250 文字以内で、具体的でそのままコピーして貼り付けられる内容（通話の対象として適格と判断する場合を除き、すべての対応方針で必須）
7. メールの下書き — 特定したユースケースに沿い、会社調査を踏まえた返信文

参考ファイル

返信を作成する前に、次のファイルを読んでください。

• references/email-examples.md — よくあるインバウンドの状況に対するメール例
• references/sales-context.md — 営業プロセス、基準、適格性の判断基準
• references/writing-style.md — PostHog のトーン、書式、スタイルのルール

重要な注意事項

1. 必ず最初にVitallyを確認してください — ほかのことをする前に、リードのメールアドレスとメールドメインを検索してください。既存顧客かどうかで、対応は大きく変わります。
2. 必ず企業について調査してください — 申告されたMAUとリードのメッセージだけで、適格・不適格を判断しないでください。5分のウェブ検索で、「見送り」が大口顧客に変わることがあります。
3. 成長の勢いは20,000ドルの基準を覆すことがあります — 成長が加速しており、有望な兆候がある企業は、現在のMAUが少なくても適格と判断してください。基準を覆した理由を記録してください。
4. 複数製品の兆候は支出を押し上げます — 「自社製品の一部」という表現がある場合、申告されたMAUは上限ではなく下限です。見積もりを調整してください。
5. AIネイティブ企業には、副次的なユースケースとしてAI/LLM Obsを提案してください — 相手が言及していなくても同様です。ほとんどの場合、関連性があります。
6. 価値の高い企業からの曖昧な問い合わせには、セルフサービスではなくヒアリングで対応してください — 詳細な問い合わせフォームの回答がないからといって、60億ドル規模のスタートアップをドキュメントに案内して終わりにしないでください。
7. 基準を覆すケース以外では、20,000ドルの基準を厳守してください — 成長が安定または横ばいで、価値の高い兆候がない企業には、これを下回る場合に通話を提案しないでください。
8. 必ずユースケースを特定してください — これが、対応方針、説明の仕方、案内するリソースのすべての基礎となります。
9. 必ず対応方針を明示してください — メールを作成するだけでなく、TAEがSalesforceを更新できるよう、適格性の判断を明確に示してください。
10. 製品に関する質問には、必ずアプリ内サポートに言及してください — サポートを受ける最も迅速な方法です。
11. PostHogはプロダクトエンジニア向けに構築されています — エンジニアが関与していない場合は、適格性判断における危険信号です。
12. 製品ではなく課題を軸に説明してください — 「ユーザーが離脱する理由を理解する方法をご紹介します」とし、「当社のプロダクト分析機能をご紹介します」とはしないでください。
13. 企業調査を活用してメールをパーソナライズしてください — 相手が尋ねたことだけでなく、その企業が何を開発しているかに触れてください。事前に調べたことが伝わります。
14. 具体性の度合いを相手に合わせてください — 曖昧な問い合わせには、確認の質問を添えて関連リソースを案内してください。具体的な技術的質問には、相手のユースケースに沿って具体的に回答してください。
15. 草案を提示する前に、必ずURLを検証してください — すべてのリンクにアクセスし、正しく表示され、適切なコンテンツを指していることを確認してください。リンク切れのまま送信しないでください。
16. 必ずDQ理由とDQメモを記載してください — 「通話に向けて適格」以外の対応方針では、選択肢の一覧から失格理由を選び、コピーして貼り付けられるメモ（250文字以内）を記載してください。リードのメッセージと企業調査の両方から、具体的な兆候を挙げてください。