account-handover

What this skill does

# 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)

## Core Workflow

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

## Step 1: Pull Vitally Account Data

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

### 1a: Find the Account

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.

### 1b: Extract Account Metadata

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

### 1c: Get Key Contacts

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.

### 1d: Get Account History

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.

### 1e: Check for Open Issues

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.

## Step 2: Pull PostHog Usage Data

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.

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

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

### 2b: Product Adoption — Which Features Are in Use

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

### 2c: Most Active Users (last 30 days)

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

## Step 3: Pull Billing Context

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.

## Step 4: Synthesize the Handover Document

Compile everything into the format below. Read `references/handover-template.md` for the full template with guidance notes.

### 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.

## Output Format

Present the handover document with these sections. Use the template from `references/handover-template.md` as the structure.

### 1. Account Snapshot
- 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)

### 2. Key Contacts

Table format:

| Name | Role | Email | Last Active | Relationship |