account-handover

アカウント引き継ぎメモ

PostHog アカウントの担当を、ある TAM または CSM から別の担当者へ移行する際に、構成の整った引き継ぎドキュメントを作成します。このドキュメントには、新しい担当者が顧客に引き継ぎの空白を感じさせることなくアカウントを引き継ぐために必要な情報をすべて記載します。

入力：アカウント名（任意：移行の理由、前任の TAM が含めたい背景情報）

基本ワークフロー

1. 背景情報を取り込む — TAM から提供された情報（アカウント名、移行理由、注意事項など）を確認します
2. Vitally のアカウントデータを取得する — アカウントの健全性、連絡先、メモ、会話を取得します
3. PostHog の利用データを取得する — プロダクトの利用状況、イベント量、機能の採用状況を取得します
4. 請求関連の情報を取得する — 支出の内訳、プランの階層、請求の推移を取得します
5. 引き継ぎドキュメントをまとめる — 構成済みの形式にまとめます（「出力形式」を参照）
6. TAM が確認する — データから把握できない情報を前任の TAM が補えるよう、下書きを提示します

ステップ 1：Vitally のアカウントデータを取得する

アカウントを検索し、関連する情報をすべて取得します。可能な場合は、これらを並行して実行してください。

1a：アカウントを見つける

アカウント名を使って vitally:find_account_by_name を実行します。複数の結果が返された場合は、どのアカウントか TAM に確認します。その後、一致するアカウント ID に対して detailLevel: "full" を指定し、vitally:get_account_full を実行します。

1b：アカウントのメタデータを抽出する

アカウントレコードから、以下を取得します。

• アカウント名、外部 ID（organization_id）、作成日
• 健全性スコア
• MRR と予測 MRR
• プランの階層（無料、有料、スタートアッププログラム、エンタープライズ）
• 割り当てられている TAM／CSM（引き継ぎ元となる現在の担当者）
• 契約の種類（月次または年次）と、該当する場合は更新日
• 主な特性：業界、従業員数、資金調達段階

1c：主要な連絡先を取得する

アカウント ID に対して vitally:get_account_users を実行します。各ユーザーについて、以下を記録します。

• 名前、メールアドレス、役割／役職
• 最終アクセス日（ただし、Vitally の lastSeenTimestamp は古い場合があります。アクティビティについては PostHog のイベントデータを正とします）
• 組織の Owner かどうか
• 所属するセグメント（利用しているプロダクトを示します）

連絡先一覧から、以下の役割を特定します。

• 推進者 — 最もアクティブなユーザーで、社内で PostHog の導入を推進する人
• 意思決定者 — 予算を管理する、または契約に署名する人（推進者とは別の人であることもよくあります）
• 技術リード — PostHog を実装し、インテグレーションを担当するエンジニア
• 日常の連絡窓口 — 前任の TAM が通常やり取りする相手

データからこれらの役割を明確に判断できない場合は、出力に「[TAM に確認]」と記載します。推測しないでください。

1d：アカウントの履歴を確認する

アカウント ID に対して vitally:get_account_notes と vitally:get_account_conversations を実行します。

メモと会話から、主な出来事のタイムラインを作成します。

• オンボーディングの実施時期
• エスカレーションやサポートの問題
• 顧客から寄せられた機能リクエスト
• QBR やビジネスレビュー
• 拡張に関する会話（新しいプロダクト、シート数の増加、プランのアップグレード）
• PostHog が行った約束（割引、カスタム機能、スケジュール）
• 最近の請求関連のサポートチケット

直近 90 日間に特に注意してください。 新しい担当の TAM に必要なのは、全履歴だけでなく、現在進行中の状況です。出力では、最近の情報と過去の情報を分けてください。

1e：未解決の問題を確認する

最近の会話やメモを調べ、未解決のものを探します。

• 対応待ちのサポートチケット
• エスカレーションされた、または対応を約束した機能リクエスト
• 対応中の請求に関する異議申し立てやクレジットの申請
• 今後予定されている更新や契約交渉
• 「後ほど回答します」としたままの項目

未解決の項目はすべて明確に記載します。新しい担当の TAM が把握していないと、引き継ぎに問題が生じる項目です。

ステップ 2：PostHog の利用データを取得する

query-run MCP ツールを使って、以下のクエリを並行して実行します。各クエリは必ずアカウントのプロジェクトにスコープを設定してください。query-run ツールの呼び出しで、Vitally の externalId である organization_id を project_id パラメーターとして渡すと、events テーブルからそのアカウントのデータのみが返されます。

2a：イベント数の推移（過去 90 日間、週単位）

SELECT
  toStartOfWeek(timestamp) AS week,
  count() AS event_count
FROM events
WHERE timestamp >= now() - INTERVAL 90 DAY
  AND properties.$organization_id = '{externalId}'
GROUP BY week
ORDER BY week

これにより、利用が増加、横ばい、または減少しているかがわかります。これは、引き継ぎを受ける TAM にとって重要な背景情報です。

2b：プロダクトの採用状況 — 利用中の機能

SELECT event, count() AS cnt
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
  AND properties.$organization_id = '{externalId}'
  AND event NOT IN (
    '$feature_flag_called',
    '$autocapture',
    '$web_vitals',
    '$dead_click'
  )
GROUP BY event
ORDER BY cnt DESC
LIMIT 30

上位イベントを PostHog のプロダクトに対応付けます。

• $pageview、insight viewed、dashboard viewed → Product Analytics
• $recording_viewed、recording analyzed → Session Replay
• $feature_flag_called（クエリからは除外していますが、必要に応じて個別に確認してください）→ Feature Flags
• $ai_generation、$ai_span、$ai_trace → LLM Analytics
• error tracking issue viewed → Error Tracking
• survey sent、survey shown → Surveys
• $export イベント → Data Pipelines

2c：最もアクティブなユーザー（過去 30 日間）

SELECT
  person.properties.email AS email,
  count() AS event_count,
  max(timestamp) AS last_active
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
  AND properties.$organization_id = '{externalId}'
  AND person.properties.email IS NOT NULL
  AND person.properties.email != ''
GROUP BY email
ORDER BY event_count DESC
LIMIT 15

ステップ 1c の Vitally の連絡先情報と照合します。最もアクティブなユーザーは、引き継ぎを受ける TAM がまず関係を築くべき相手です。

ステップ 3：請求情報を取得する

請求レポートを確認して、支出の傾向を把握します。

SELECT date, report
FROM postgres.prod.billing_usagereport
WHERE organization_id = '{externalId}'
ORDER BY date DESC
LIMIT 3

請求レポートから、以下の情報を抽出します。

プロダクト別の現在の支出内訳（Vitally の予測 MRR フィールドを相互参照として使用）：

• product_analytics_forecasted_mrr
• session_replay_forecasted_mrr
• feature_flags_forecasted_mrr
• llm_analytics_forecasted_mrr
• error_tracking_forecasted_mrr
• data_warehouse_forecasted_mrr
• surveys_forecasted_mrr
• enhanced_persons_forecasted_mrr

支出の推移：直近 3 件の請求レポートを比較し、増加、横ばい、または減少に分類します。

SDK の内訳（請求レポートのフィールドから）：

• web_events_count_in_period
• node_events_count_in_period、python_events_count_in_period、go_events_count_in_period
• ios_events_count_in_period、android_events_count_in_period
• flutter_events_count_in_period、react_native_events_count_in_period

SDK の内訳から、引き継ぎを受ける TAM は顧客に尋ねることなく、顧客の技術スタックを把握できます。

ステップ 4：引き継ぎドキュメントをまとめる

以下の形式で情報をまとめます。ガイダンスを含む完全なテンプレートについては、references/handover-template.md を参照してください。

情報源のルール

引き継ぎドキュメントの各セクションでは、情報源を明確に示してください。

• [Data] — Vitally、PostHog、または請求情報から直接取得した情報です。引き継ぎを受ける TAM はこの情報を信頼できます。
• [TAM to confirm] — 前任の TAM が記憶に基づいて背景情報を追加する必要がある箇所のプレースホルダーです。空欄にせず、明確な確認事項として残してください。
• [Inferred] — データから導き出したものの、明示的には記載されていない情報です。引き継ぎを受ける TAM が検証できるよう、推論の根拠を示してください。

出力形式

以下のセクションを含む引き継ぎドキュメントを提示します。構成には references/handover-template.md のテンプレートを使用してください。

1. アカウントの概要

• 会社名、提供している製品・サービス、業界
• 従業員数、資金調達段階（判明している場合）
• PostHog のプランと MRR
• ヘルススコア
• アカウントの利用期間（最初のイベントまたは Vitally の作成日からの期間）
• 契約種別と更新日（該当する場合）
• 引き継ぎの理由（TAM からの入力）

2. 主な連絡先

表形式：

氏名	役職	メールアドレス	最終アクティブ日時	関係性
...	...	...	...	推進者 / 意思決定者 / 技術リード / [TAM to confirm]

前任の TAM が通常誰と、どのチャネル（メール、Slack、通話）で連絡を取っていたかについても記載します。

3. プロダクトの利用状況

• アクティブに利用されている PostHog のプロダクト（月間のプロダクト別支出を含む）
• イベント数の推移（増加／横ばい／減少）と週ごとの数値
• SDK の内訳（顧客の技術スタック）
• 利用している主な機能とインサイト

4. 請求と支出

• 現在のMRRと推移の方向性
• 製品ごとの支出内訳（表）
• 契約の詳細：月次契約か年次契約か、更新日、割引やクレジットの有無
• 請求上限（設定されている場合）
• 未解決の請求問題やクレジットの申請

5. アカウント履歴（タイムライン）

主なイベントを時系列で列挙し、次のように分けます。

最近（過去90日間）：

• [日付] イベントの説明（出典：Vitallyのメモ／会話）

過去の履歴：

• [日付] イベントの説明

6. 未対応項目

• 未解決のサポートチケット
• 対応待ちの機能リクエスト
• 進行中の会話
• PostHogが行った確約（割引、スケジュール、カスタム対応）
• 今後の期限（契約更新、クレジットの有効期限、QBR）

7. 関係性に関する情報

このセクションはTAMからの情報に大きく依存します。データから分かることを示したうえで、明確な確認事項を残してください。

• コミュニケーションの希望：[TAMに確認 — メール、Slack、通話のどれか？頻度は？]
• ミーティングの頻度：[TAMに確認 — 毎週、毎月、必要に応じて？]
• 社内の力学：[TAMに確認 — 意思決定を主導するのは誰か？把握しておくべき社内事情はあるか？]
• 性格に関するメモ：[TAMに確認 — コミュニケーションスタイルの好み、苦手なこと、信頼関係の構築につながることはあるか？]
• 慎重に扱うべき話題：[TAMに確認 — 過去の問題、価格に関する意見の相違、慎重な対応が必要なことはあるか？]

8. 後任のTAMに推奨する次のステップ

データに基づいて、次のことを提案します。

1. 初回のアプローチ — 自己紹介の方法（メール、Slackメッセージ、または前任のTAMに紹介を依頼）
2. 初回ミーティングの議題 — 初回の会話で取り上げる内容（引き継ぎについて伝える、未対応項目を確認する、相手の優先事項を確認する）
3. 早期に成果を出せること — 信頼関係を築くために、後任のTAMがすぐにできること（未解決のチケットを解決する、機能リクエストの進捗を確認する、関連するリソースを共有する）
4. 注意して確認する項目 — 継続的に確認すること（利用状況の低下、契約更新の時期、クレジットの有効期限、未解決のエスカレーション）

重要なルール

1. 必ずVitallyとPostHogから情報を取得してください。 記憶や推測だけで引き継ぎ資料を作成しないでください。文書は実際のデータに基づいている必要があります。
2. データの不足を明示してください。 アカウントにVitallyのメモがない場合は、その旨を明記してください。これは、移行前に前任のTAMが補う必要のある情報です。
3. TAMからの確認が必要な項目を明示してください。 データでは回答できない項目には[TAM to confirm]を使用してください。関係性、コミュニケーションの希望、口頭での確約はVitallyではなく、TAMの頭の中にあります。
4. 関係性に関する情報を捏造しないでください。 メモに推進者が誰か記載されていない場合、推測しないでください。TAMへの確認事項として残してください。
5. 情報の新しさを優先してください。 後任のTAMが最も重視するのは過去90日間です。過去の情報も重要ですが、優先度は下げてください。
6. 未対応項目を目立つように示してください。 引き継ぎ時の対応漏れは、信頼を失う最も早い原因です。未解決の項目は、必ず見落とされないようにしてください。
7. 時間を節約するため、PostHogのクエリは並行して実行してください。
8. VitallyのlastSeenTimestampはアクティビティの判定に信頼できません。 「最終アクティブ日」は、必ずPostHogのイベントデータと照合してください。
9. PostHogが503（ビジー）を返した場合、少し待ってから1回だけ再試行し、そのクエリを諦めてください。

下書きの提示後

引き継ぎ文書を生成したら、前任のTAMに次のように伝えてください。

「これはデータに基づいて作成した下書きです。各セクション、特に関係性に関する情報と未対応項目を確認し、[TAM to confirm]と記載された箇所を補足してください。メモを追加したら、後任のTAM／CSMに共有できる状態です。」

前任のTAMから追加の情報が提供された場合は、それを文書に反映し、該当するセクションを再生成してください。