account-handover

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Account Handover Notes

账户交接笔记

Draft a structured handover document when transitioning a PostHog account from one TAM or CSM to another. The document gives the incoming owner everything they need to pick up the account without the customer noticing a gap.

Input: Account name (and optionally: reason for transition, any context the outgoing TAM wants to include)

当PostHog账户在TAM或CSM之间交接时，起草一份结构化交接文档。该文档为接手账户的负责人提供所需的全部信息，确保客户不会感受到服务断层。

输入：账户名称（可选：交接原因、离任TAM希望补充的任何背景信息）

Core Workflow

核心流程

Ingest context — Read what the TAM provides (account name, transition reason, anything they want to flag)
Pull Vitally account data — Account health, contacts, notes, conversations
Pull PostHog usage data — Product usage, event volume, feature adoption
Pull billing context — Spend breakdown, plan tier, billing trend
Synthesize handover document — Compile into the structured format (see Output Format)
TAM review — Present the draft for the outgoing TAM to fill in gaps the data can't capture

获取背景信息 — 读取TAM提供的内容（账户名称、交接原因、任何需要标记的事项）
拉取Vitally账户数据 — 账户健康度、联系人、备注、对话记录
拉取PostHog使用数据 — 产品使用情况、事件量、功能采用率
拉取账单信息 — 支出明细、套餐等级、账单趋势
合成交接文档 — 整理为结构化格式（见输出格式）
TAM审核 — 提交草稿给离任TAM，补充数据无法覆盖的信息缺口

Step 1: Pull Vitally Account Data

步骤1：拉取Vitally账户数据

Search for the account and pull everything relevant. Run these in parallel where possible.

搜索目标账户并拉取所有相关数据，尽可能并行执行以下操作。

1a: Find the Account

1a：查找账户

Use

vitally:find_account_by_name

with the account name. If multiple results come back, ask the TAM which one. Then use

vitally:get_account_full

with

detailLevel: "full"

on the matching account ID.

使用

vitally:find_account_by_name

工具根据账户名称查找。若返回多个结果，询问TAM确认目标账户。随后使用

vitally:get_account_full

工具，传入匹配的账户ID并设置

detailLevel: "full"

获取完整信息。

1b: Extract Account Metadata

1b：提取账户元数据

From the account record, pull:

Account name, external ID (organization_id), creation date
Health score
MRR and forecasted MRR
Plan tier (free, paid, startup program, enterprise)
Assigned TAM/CSM (the current owner being transitioned from)
Contract type (monthly vs. annual) and renewal date if applicable
Key traits: industry, employee count, funding stage

从账户记录中提取：

账户名称、外部ID（organization_id）、创建日期
健康评分
MRR（月度经常性收入）及预测MRR
套餐等级（免费版、付费版、创业计划、企业版）
当前分配的TAM/CSM（即将离任的负责人）
合同类型（月度/年度）及续约日期（如有）
关键特征：行业、员工数量、融资阶段

1c: Get Key Contacts

1c：获取关键联系人

Use

vitally:get_account_users

on the account ID. For each user, note:

Name, email, role/title
Last seen date (but remember Vitally's
```
lastSeenTimestamp
```
can be stale — PostHog event data is the truth for activity)
Whether they're the org Owner
Any segments they belong to (indicates which products they use)

Identify these roles from the contact list:

Champion — the most active user, the one who drives PostHog adoption internally
Decision-maker — the person who controls budget or signs contracts (often different from the champion)
Technical lead — the engineer who implemented PostHog and handles the integration
Day-to-day contact — who the outgoing TAM typically communicates with

If the data doesn't make these roles obvious, mark them as "[TAM to confirm]" in the output. Don't guess.

使用

vitally:get_account_users

工具获取账户下的用户信息。为每位用户记录：

姓名、邮箱、职位/头衔
最后活跃日期（注意：Vitally的
```
lastSeenTimestamp
```
可能不准确，PostHog事件数据才是判断活跃状态的依据）
是否为组织所有者
所属细分群体（表明其使用的产品）

从联系人列表中识别以下角色：

核心用户 — 最活跃的用户，推动内部PostHog的采用
决策者 — 掌控预算或签署合同的人（通常与核心用户不同）
技术负责人 — 负责PostHog部署及集成的工程师
日常对接人 — 离任TAM通常沟通的对象

若数据无法明确这些角色，在输出中标记为“[需TAM确认]”，切勿猜测。

1d: Get Account History

1d：获取账户历史记录

Use

vitally:get_account_notes

and

vitally:get_account_conversations

on the account ID.

From the notes and conversations, build a timeline of key events:

When onboarding happened
Any escalations or support issues
Feature requests the customer raised
QBRs or business reviews
Expansion conversations (new products, more seats, plan upgrades)
Any commitments made by PostHog (discounts, custom features, timelines)
Recent billing-related support tickets

Pay special attention to the last 90 days. The incoming TAM needs to know what's active right now, not just the full history. Separate recent context from historical context in the output.

使用

vitally:get_account_notes

和

vitally:get_account_conversations

工具获取账户的备注和对话记录。

从备注和对话中构建关键事件时间线：

入职培训时间
任何升级或支持问题
客户提出的功能需求
QBR（季度业务回顾）或业务评审
拓展对话（新产品、更多席位、套餐升级）
PostHog做出的任何承诺（折扣、定制功能、时间节点）
近期与账单相关的支持工单

重点关注过去90天的内容。接手的TAM需要了解当前的活跃事项，而非完整历史。在输出中区分近期背景和历史背景。

1e: Check for Open Issues

1e：检查未结事项

Look through recent conversations and notes for anything unresolved:

Pending support tickets
Feature requests that were escalated or promised
Billing disputes or credit requests in progress
Upcoming renewals or contract negotiations
Any "I'll get back to you on this" items

Flag every open item clearly. These are the things that will make the transition feel broken if the incoming TAM doesn't know about them.

查看近期对话和备注，找出所有未解决的事项：

待处理的支持工单
已升级或承诺的功能需求
进行中的账单争议或信用申请
即将到来的续约或合同谈判
任何“稍后回复”的事项

清晰标记所有未结事项。如果接手的TAM不了解这些内容，交接过程很容易出现断层。

Step 2: Pull PostHog Usage Data

步骤2：拉取PostHog使用数据

Run these queries in parallel via the

query-run

MCP tool. Every query must be scoped to the account's project — pass the

organization_id

(externalId from Vitally) as the

project_id

parameter in the

query-run

tool call so the events table only returns data for that account.

通过

query-run

MCP工具并行执行以下查询。所有查询必须限定在目标账户的项目范围内——将Vitally中的

externalId

作为

project_id

参数传入

query-run

工具，确保事件表仅返回该账户的数据。

2a: Event Volume Trend (last 90 days, weekly)

2a：事件量趋势（过去90天，按周统计）

sql

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

This shows whether usage is growing, flat, or declining — critical context for the incoming TAM.

sql

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: Product Adoption — Which Features Are in Use

2b：产品采用情况——已使用的功能

sql

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

Map the top events to PostHog products:

```
$pageview
```
,
```
insight viewed
```
,
```
dashboard viewed
```
→ Product Analytics
```
$recording_viewed
```
,
```
recording analyzed
```
→ Session Replay
```
$feature_flag_called
```
(excluded from query but check separately if needed) → Feature Flags
```
$ai_generation
```
,
```
$ai_span
```
,
```
$ai_trace
```
→ LLM Analytics
```
error tracking issue viewed
```
→ Error Tracking
```
survey sent
```
,
```
survey shown
```
→ Surveys
```
$export
```
events → Data Pipelines

sql

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: Most Active Users (last 30 days)

2c：最活跃用户（过去30天）

sql

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

Cross-reference with the Vitally contacts from Step 1c. The most active users are who the incoming TAM should build rapport with first.

sql

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首先需要建立 rapport 的对象。

Step 3: Pull Billing Context

步骤3：拉取账单信息

Query the billing report to understand spend patterns.

sql

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

From the billing reports, extract:

Current spend breakdown by product (using Vitally forecasted MRR fields as a cross-reference):

```
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
```

Spend trend: Compare the last 3 billing reports to classify as growing, flat, or declining.

SDK breakdown (from billing report fields):

```
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

The SDK split tells the incoming TAM what the customer's tech stack looks like without having to ask.

查询账单报告以了解支出模式。

sql

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了解客户的技术栈。

Step 4: Synthesize the Handover Document

步骤4：合成交接文档

Compile everything into the format below. Read

references/handover-template.md

for the full template with guidance notes.

将所有内容整理为以下格式。完整模板及指导说明请参考

references/handover-template.md

。

Sourcing Rules

来源规则

Every section in the handover document should be clearly sourced:

[Data] — pulled directly from Vitally, PostHog, or billing. The incoming TAM can trust this.
[TAM to confirm] — placeholder where the outgoing TAM needs to add context from memory. Leave these as clear prompts, not blank spaces.
[Inferred] — derived from the data but not explicitly stated. Flag the reasoning so the incoming TAM can validate.

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

[数据] — 直接来自Vitally、PostHog或账单数据，接手的TAM可信任该内容。
[需TAM确认] — 占位符，需要离任TAM补充记忆中的背景信息。将其设置为明确的提示，而非空白。
[推断] — 从数据中推导但未明确说明的内容。标注推理依据，以便接手的TAM验证。

Output Format

输出格式

Present the handover document with these sections. Use the template from

references/handover-template.md

as the structure.

按照以下章节呈现交接文档，以

references/handover-template.md

中的模板为结构。

1. Account Snapshot

1. 账户快照

Company name, what they build, industry
Employee count, funding stage (if known)
PostHog plan and MRR
Health score
Account age (time since first event or Vitally creation date)
Contract type and renewal date (if applicable)
Transition reason (from TAM input)

公司名称、业务范围、行业
员工数量、融资阶段（如有）
PostHog套餐及MRR
健康评分
账户存续时长（从首次事件或Vitally创建日期算起）
合同类型及续约日期（如有）
交接原因（来自TAM输入）

2. Key Contacts

2. 关键联系人

Table format:

Name	Role	Email	Last Active	Relationship
...	...	...	...	Champion / Decision-maker / Technical lead / [TAM to confirm]

Include a note on who the outgoing TAM typically communicated with and through what channel (email, Slack, calls).

表格格式：

姓名	角色	邮箱	最后活跃日期	关系
...	...	...	...	核心用户 / 决策者 / 技术负责人 / [需TAM确认]

备注离任TAM通常的沟通对象及沟通渠道（邮件、Slack、电话）。

3. Product Usage Summary

3. 产品使用摘要

Which PostHog products are actively used (with monthly spend per product)
Event volume trend (growing / flat / declining) with weekly numbers
SDK breakdown (what's their tech stack)
Top features and insights they use

活跃使用的PostHog产品（含每月产品支出）
事件量趋势（增长/持平/下降）及每周数据
SDK明细（客户技术栈）
常用的热门功能及洞察

4. Billing and Spend

4. 账单与支出

Current MRR and trend direction
Spend breakdown by product (table)
Contract details: monthly vs. annual, renewal date, any discounts or credits
Billing limits (if set)
Any pending billing issues or credit requests

当前MRR及趋势方向
按产品划分的支出明细（表格）
合同详情：月度/年度、续约日期、任何折扣或信用额度
账单限额（如有设置）
任何待处理的账单问题或信用申请

5. Account History (Timeline)

5. 账户历史（时间线）

Chronological list of key events, split into:

Recent (last 90 days):

[date] Event description (source: Vitally note/conversation)

Historical:

[date] Event description

按时间顺序列出关键事件，分为两部分：

近期（过去90天）：

[日期] 事件描述（来源：Vitally备注/对话）

历史：

[日期] 事件描述

6. Open Items

6. 未结事项

Unresolved support tickets
Pending feature requests
In-progress conversations
Commitments made by PostHog (discounts, timelines, custom work)
Upcoming deadlines (renewals, credit expiry, QBRs)

未解决的支持工单
待处理的功能需求
进行中的对话
PostHog做出的承诺（折扣、时间节点、定制工作）
即将到来的截止日期（续约、信用到期、QBR）

7. Relationship Context

7. 关系背景

This section relies heavily on TAM input. Present what the data shows, then leave clear prompts:

Communication preferences: [TAM to confirm — email, Slack, calls? How often?]
Meeting cadence: [TAM to confirm — weekly, monthly, ad-hoc?]
Internal dynamics: [TAM to confirm — who drives decisions? Any internal politics to be aware of?]
Personality notes: [TAM to confirm — any communication style preferences, pet peeves, things that build rapport?]
Sensitive topics: [TAM to confirm — past incidents, pricing disputes, anything to handle carefully?]

该部分主要依赖TAM输入。先呈现数据显示的内容，再留下明确提示：

沟通偏好：[需TAM确认 — 邮件、Slack、电话？频率如何？]
会议节奏：[需TAM确认 — 每周、每月、按需？]
内部动态：[需TAM确认 — 谁主导决策？是否有需要注意的内部情况？]
个性说明：[需TAM确认 — 沟通风格偏好、忌讳事项、建立信任的方式？]
敏感话题：[需TAM确认 — 过往事件、定价争议、需要谨慎处理的事项？]

8. Recommended Next Steps for Incoming TAM

8. 接手TAM的建议下一步行动

Based on the data, suggest:

Intro approach — how to introduce yourself (email, Slack message, or ask the outgoing TAM for a warm intro)
First meeting agenda — what to cover in the first conversation (acknowledge the transition, review open items, confirm their priorities)
Quick wins — anything the incoming TAM can do immediately to build trust (resolve an open ticket, follow up on a feature request, share a relevant resource)
Watch items — things to monitor (declining usage, upcoming renewal, credit expiry, unresolved escalation)

基于数据，建议：

自我介绍方式 — 如何介绍自己（邮件、Slack消息，或请求离任TAM进行引荐）
首次会议议程 — 首次沟通需涵盖的内容（确认交接、回顾未结事项、确认客户优先级）
快速建立信任的举措 — 接手TAM可立即执行的动作（解决未结工单、跟进功能需求、分享相关资源）
需关注事项 — 需要监控的内容（使用量下降、即将续约、信用到期、未解决的升级问题）

Critical Rules

关键规则

Always pull from Vitally and PostHog. Never generate a handover from memory or assumptions alone. The document should be grounded in real data.
Flag data gaps. If the account has no Vitally notes, say so explicitly — that's a gap the outgoing TAM needs to fill before the transition.
Mark what needs TAM input. Use
```
[TAM to confirm]
```
for anything the data can't answer. Relationship context, communication preferences, and verbal commitments live in the TAM's head, not in Vitally.
Don't fabricate relationship context. If the notes don't mention who the champion is, don't guess. Leave it as a prompt for the TAM.
Prioritize recency. The incoming TAM cares most about the last 90 days. Historical context matters but should be secondary.
Surface open items prominently. Dropped balls during a transition are the fastest way to lose trust. Every unresolved item should be impossible to miss.
Run PostHog queries in parallel to save time.
Vitally
lastSeenTimestamp
is unreliable for activity. Always cross-reference with PostHog event data for "last active" dates.
If PostHog returns 503 (busy), wait a moment and retry once before giving up on that query.

始终从Vitally和PostHog拉取数据。切勿仅凭记忆或假设生成交接文档，文档必须基于真实数据。
标记数据缺口。如果账户没有Vitally备注，需明确说明——这是离任TAM在交接前需要补充的缺口。
标记需要TAM输入的内容。对于数据无法回答的问题，使用
```
[需TAM确认]
```
标记。关系背景、沟通偏好和口头承诺仅存在于TAM的记忆中，而非Vitally系统。
切勿编造关系背景。如果备注中未提及核心用户是谁，切勿猜测，留作TAM的提示项。
优先呈现近期内容。接手的TAM最关心过去90天的情况，历史背景虽重要但应处于次要位置。
突出显示未结事项。交接过程中遗漏事项是最快失去客户信任的方式，每个未解决事项都应醒目呈现。
并行执行PostHog查询以节省时间。
Vitally的
lastSeenTimestamp
不可靠，判断活跃状态时务必与PostHog事件数据交叉核对。
若PostHog返回503错误（服务繁忙），稍作等待后重试一次，再放弃该查询。

After Presenting the Draft

提交草稿后

Once the handover document is generated, tell the outgoing TAM:

"This is the data-sourced draft. Please review each section — especially Relationship Context and Open Items — and fill in anything marked [TAM to confirm]. Once you've added your notes, this is ready to share with the incoming TAM/CSM."

If the outgoing TAM provides additional context, incorporate it into the document and regenerate the relevant sections.

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

"这是基于数据生成的草稿。请审核每个部分——尤其是关系背景和未结事项——并补充所有标记为[需TAM确认]的内容。完成补充后，即可分享给接手的TAM/CSM。"

如果离任TAM提供额外背景信息，将其整合到文档中并重新生成相关章节。