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 使用 vitally:get_account_full，并将 detailLevel: "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 工具时，将 organization_id（Vitally 中的 externalId）作为 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 → 产品分析
• $recording_viewed、recording analyzed → 会话回放
• $feature_flag_called（查询中已排除，但如有需要可单独检查）→ 功能标志
• $ai_generation、$ai_span、$ai_trace → LLM 分析
• error tracking issue viewed → 错误跟踪
• survey sent、survey shown → 调查
• $export 事件 → 数据管道

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，查看包含指导说明的完整模板。

信息来源规则

交接文档的每个部分都应明确标注信息来源：

• [数据] — 直接从 Vitally、PostHog 或账单中提取。即将接手的 TAM 可以信赖这些信息。
• [TAM 确认] — 留作占位，供即将离任的 TAM 补充记忆中的背景信息。请将这些内容保留为明确的提示，不要留空。
• [推断] — 根据数据推导，但并未明确陈述。请标明推理依据，以便即将接手的 TAM 验证。

输出格式

按以下部分呈现交接文档。使用 references/handover-template.md 中的模板作为结构。

1. 账户概览

• 公司名称、产品内容、所属行业
• 员工人数、融资阶段（如已知）
• PostHog 套餐和 MRR
• 健康评分
• 账户存续时间（自首次事件或 Vitally 创建日期起）
• 合同类型和续约日期（如适用）
• 交接原因（来自 TAM 输入）

2. 关键联系人

表格格式：

姓名	职务	电子邮箱	最近活跃时间	关系
...	...	...	...	业务倡导者 / 决策者 / 技术负责人 / [TAM 确认]

请注明即将离任的 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]。关系背景、沟通偏好和口头承诺都存在 TAM 的记忆中，而不在 Vitally 里。
4. 不要捏造关系背景。 如果备注没有提到谁是内部支持者，就不要猜测。将其留作 TAM 需要确认的事项。
5. 优先关注近期信息。 接任 TAM 最关心的是过去 90 天的情况。历史背景也很重要，但应放在次要位置。
6. 突出显示待处理事项。 交接期间遗漏事项是最快导致信任流失的方式。每项尚未解决的事项都必须醒目易见。
7. 并行运行 PostHog 查询以节省时间。
8. Vitally 的 lastSeenTimestamp 不可靠，不能用于判断活动情况。判断“最后活跃”日期时，务必与 PostHog 事件数据交叉核对。
9. 如果 PostHog 返回 503（繁忙），请稍等片刻，然后重试一次，再决定是否放弃该查询。

呈现草稿后

生成交接文档后，请告知离任 TAM：

“这是基于数据生成的草稿。请审核每个部分——尤其是关系背景和待处理事项——并补充所有标记为 [TAM to confirm] 的内容。添加备注后，即可将文档分享给接任 TAM/CSM。”

如果离任 TAM 提供了额外背景信息，请将其纳入文档，并重新生成相关部分。