PostHog Handbook Library / Growth

3,666 words. Estimated reading time: 17 min.

# Account allocation and handover

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. TAM vs CSM
2. Requesting a TAM overlay
3. Quarterly book planning
4. Accounts to remove from your book
5. What is NOT a valid reason to hand off
6. Doing the allocation
7. Quarterly allocation process
8. Mid quarter changes

We have different roles within the team who manage customers at various stages in their lifecycle. Customers will typically sign up and start paying for PostHog themselves, or land as customers via a Technical Account Executive. Once customers hit $20k a year in spend with us they should have a dedicated Technical Account Manager or Customer Success Manager.

### TAM vs CSM

Technical Account Managers (Sales Team) and Customer Success Managers (Customer Success Team) are the primary owner of customers spending $20k a year and above; and we aim to have full coverage of those customers across the two teams and roles. Our default is for a CSM/CSE to be the point of contact on every $20k+ account, with a TAM requested as an overlay where there's room to grow. When deciding whether to request that overlay we factor in their usage of our primary products.

Primary products are the set of billable main products which we believe that all engineers should be using, not including add-ons or platform features. Our current set of primary products are:

- Session replay
- Feature flags
- Error tracking

We track whether a customer is paying for each product in Vitally using the `Paying for <Product Name>` trait.

- Customers already paying for all of the primary products are considered expanded to the max and should go to a Customer Success Manager. They should be pretty sticky as a customer so the main focus here is retention.
- Otherwise, there is room to grow and a Technical Account Manager should be focused on getting them using the three primary products.

> This allocation may vary depending on team capacity - there may be some accounts who only have 1 or 2 paid products allocated to a CSM rather than a TAM where there is more capacity in the CSM team for example.

#### Requesting a TAM overlay

Because a CSM/CSE is the default point of contact on every $20k+ account, the decision is no longer "TAM or CSM" but whether to add a TAM overlay on top. Request one where there's clear expansion potential and it's worth having a second person on the account: commercial depth from the TAM, technical depth from the CSM/CSE. Accounts that are fully expanded and in steady state stay CSM/CSE-only. Where there's expansion potential but no TAM capacity yet, an account may sit CSM/CSE-only for a period until an overlay can be added.

---

### Quarterly book planning

At the start of each quarter, TAMs should prepare their book of business with the following constraints in mind:

Target book size: 10-15 accounts with a combined ~$1.5m ARR. This gives TAMs enough focus to actually move the needle on expansion and credit pre-purchases.

Maximum book size: 15 accounts. New leads or handoffs from CS/Onboarding/TAEs will push a TAM above this throughout the quarter, but if you're starting a quarter at 18 accounts, you need to find a way to get to 15 or fewer.

#### Accounts to remove from your book

Before the quarter starts, review each account and remove those that meet any of the following criteria:

- Churned or dropped below $20k ARR – unless you have a documented, specific plan to get them above $20k this quarter
- On YC Plan – accounts $20k-$50k on the YC plan will go to the YC role on the CS team. Accounts above $50k should be a candidate for TAM referral if there is growth opportunity.
- Fully expanded and committed – if the account has all 3 core products adopted (Session Replay, Feature Flags, Error Tracking), has a discount agreement in place, and has no viable levers for net new revenue, they should go to a CSM
- No viable expansion levers – if there's genuinely no path to growth, it shouldn't be consuming TAM bandwidth. You need to document what you've tried here so that we know all avenues for growth have been exhausted.

#### What is NOT a valid reason to hand off

Low engagement or an account being "difficult to work with" is not a reason to pass them off. That's literally your job. Specifically:

- Account doesn't respond to your outreach
- Champion left and you haven't re-established relationships
- Low user activity or poor health score
- You don't like working with them / they don't like you

If an account is struggling on these dimensions, that's a signal you need to invest more effort – not hand them off. You should only hand off accounts that are in a good state.

---

### Doing the allocation

It's Simon's job, with input from Ben and Team Leads, to review the list of $20K accounts without an owner, as well as accounts which need to be handed over from TAE and TAMs. We use the criteria above to figure out which team should own a customer, and then use Vitally data to understand which region they are primarily based in. Looking at the user list in Vitally will show you where the most users are so make a judgement call on where the TAM or CSM should be based to best support and engage with the customer. Once this has been decided the New Owner trait is populated with one of the following:

- US TAM
- US CSM
- EU TAM
- EU CSM

And then it is down to the Team Leads to figure out which team member is taking on the customer.

#### Quarterly allocation process

At the start of each quarter, Simon (with input from Ben and Team Leads) reviews:

1. $20K accounts without an owner – accounts that need to be assigned
2. Accounts flagged for handover from TAEs, TAMs, and CSMs
3. TAM books exceeding 15 accounts – identifying accounts that should move to CSM or another TAM
4. CSM accounts with expansion potential – identifying accounts that should move to a TAM

Once Simon determines whether an account belongs with a TAM or CSM (and which region), the `New Owner` trait is populated, and Team Leads assign the specific team member.

#### Mid-quarter changes

Account removals should only happen at the end of the quarter so that quota can be calculated correctly. However, accounts can be added to your book at any time if you're confident there's growth potential.

If you're assigned an account with a previous owner, work with them on a proper handover. If the customer isn't in a healthy state (usage and engagement-wise), push back and ask the previous owner to get them to a good state first.

> New accounts with no previous owner come with a 3 month grace period – if they churn in that initial period, they won't count against your quota. Don't ask for the `AM Managed` segment to be added until you're confident there's growth potential.

---

### Top 40 account management

Our highest-spend customers (~Top 40 by ARR) get special consideration for ownership decisions. Simon and Ben regularly review these accounts to:

- Minimize ownership changes – frequent handoffs create whiplash for customers and damage relationships
- Ensure continuity – the bar for changing ownership on a Top 40 account is higher than for the rest of the book
- Make judgment calls – sometimes a TAM should keep a "fully expanded" account if the relationship is strong and there's long-term strategic value

For Top 40 accounts, ownership changes (TAM→CSM or CSM→TAM) are decided directly by Simon and Ben, not through the standard Team Lead allocation process.

---

### Handing over customers

To help the new owner of a customer hit the ground running, we should make sure that the customer is in a good state and that a warm introduction happens. Typical handoffs between roles are:

| Transition | Typical timing | Condition | |------------|----------------|-----------| | TAE → TAM | When onboarded, typically 3 months after initial credit purchase OR 12 months after initial credit pre-purchase if the account is retained by the TAE | Customer onboarded to 1-2 primary products | | TAE → CSM | When onboarded, typically 3 months after initial credit purchase OR 12 months after initial credit pre-purchase if the account is retained by the TAE | Customer onboarded to 3+ primary products | | TAM → CSM | After expansion completes | All 3 core products adopted, discount agreement in place, no remaining expansion levers | | CSM → TAM | When expansion opportunity identified | Customer not fully expanded and has clear growth potential |

> For accounts who will be landing at $100k+ a year or have high expansion potential after the initial deal, we should involve a TAM early in the process to ensure a smooth transition. See the section further down this page on how this works.

For handover to take place there should be an Account Plan (saved as a note on the account in Vitally) and the customer should have been onboarded properly to the products they are currently paying for.

> All open invoices should also have been paid before handing over. It makes sense to use existing relationships to chase payments, rather than the new owner's first action needing to be chasing payments/suspending access for non-payment.

> For TAE accounts being handed over, set the New Owner to `Ready to move` in Vitally and then flag this with Simon directly. There's no need to wait for the end of the quarter to do this. He will review the plan and current state of the customer and then work with TAM or CSM leads to assign a new owner.

#### Account Plan

Every account being handed over should have an up-to-date Account Plan saved as a note in Vitally. The existing owner should ensure that this is current and schedule a handover call to walk through it with the new owner. Feel free to push back and ask for it as the new owner if this doesn't happen! Ask your team lead or Simon for help with this if you're not getting the information you need from the previous owner.

#### Product Onboarding

Before handing over a customer, the existing owner needs to ensure that the customer is onboarded properly to the products they are paying for. We should first ensure that they are only paying for what they need to as detailed in the health checks section of the handbook and then ensure the following steps have been completed, depending on the products they are paying for:

> This is an initial pass at what good onboarding looks like for each product. We will refine this and add it to Vitally as a checklist to work through with the customer.

##### General principles

- They are aware of how to get support both via Slack and in-app and where in-app is more appropriate.
- They have the correct owners and admins set up in their PostHog organization.
- We have the correct finance contact details in Stripe.

##### Product analytics

- They have set up tracking, implementing posthog.identify() and posthog.group() correctly where appropriate.
- They are aware of the difference between anonymous and identified events.
- Event capture is tuned and automatic events have been turned off where not wanted.
- We have completed training for the core user base, so that they are aware of concepts such as Actions, Cohorts etc.
- They have set some insights and dashboards aligned with their use case for PostHog.

##### Session replay

- They have set up tracking using posthog-js.
- They are aware of the different recording controls and how to use them.
- They have implemented privacy controls where necessary.
- We have completed training for the core user base so that they know how to find specific recordings, as well as navigate from other products to session replays (e.g. from a funnel)

##### Feature flags

- They understand how to integrate feature flags into their workflow.
- Feature flag calls are implemented correctly so as not to artificially inflate the bill.
- They understand the current targeting mechanisms which are available.
- We've conducted training on how to set up Feature Flags and Experiments.

##### Data warehouse

- They have connected up the sources they need to.
- They are aware of the difference between incremental and full sync and the impact on billing.
- We've conducted training on using SQL in PostHog, creating views and joining on person data.

##### Error Tracking

- They have set up tracking using posthog-js.

---

### Account handover checklist

Every account handover should include a 15-30 minute call between the outgoing and incoming owner. This checklist helps you prep for that call and make sure nothing falls through the cracks.

#### When to use this

- When a TAE-led customer is being handed over to a TAM after the initial contract is signed
- When a TAM is taking over an account from another TAM or TAE mid-lifecycle
- As a prep guide for the 15-30 minute handover call between outgoing and incoming owner

#### Before the handover call

The incoming TAM should prepare by reviewing the following in Vitally and SFDC before the call, so the handover conversation can focus on context that isn't in the data.

##### Self-serve research (do this first)

- [ ] Vitally account overview – MRR, ARR, health score, segments, paid products, usage traits
- [ ] Billing & contract details – annual plan dates, credit balances, discounts, renewal date, billing limits
- [ ] Product adoption – which products are they paying for? What's underutilized?
- [ ] Usage metrics – active users, project count, Feature Flag requests, Session Replay volume, insight/dashboard engagement
- [ ] Support history – recent Zendesk tickets, tags, severity, resolution status
- [ ] Conversations & notes – read all Vitally notes, meeting summaries, and conversation history
- [ ] Customer Slack channel – scan the shared channel for who's actually active on the customer side, what issues have come up, and any open threads worth asking the previous owner about. This is often where the most useful context lives.
- [ ] Internal Slack discussions – search our own Slack (outside the shared channel) for mentions of the customer. Engineering debates, pricing conversations, support escalations, and context from the previous owner often surface things that were never written down in Vitally.
- [ ] SFDC opportunity – deal value, stage, next steps, close date
- [ ] Admin emails & user list – identify who's active, who has admin access, what domains are in play
- [ ] The customer's product – sign up or browse their website. Understand what they do and how they make money

Prepare questions based on gaps in the data. The handover call should focus on things you can't learn from Vitally.

#### Handover call agenda

This isn't an exhaustive list and not every item needs to be covered every time. Use your judgment based on what's relevant to the account.

##### 1. Relationships & people

This is the most valuable part of the handover – relationship context doesn't live in any tool.

- [ ] Who is the champion? Name, role, communication style, what motivates them
- [ ] Who is the economic decision-maker? Who signs off on renewals and expansion?
- [ ] Who are the power users? Engineers, PMs, analysts – who lives in PostHog daily?
- [ ] Org structure? Parent/subsidiary dynamics, relevant teams, reporting lines
- [ ] Any recent people changes? Champions who left, new hires, reorgs
- [ ] General vibe? Easy to work with? High-maintenance? Responsive or hard to reach?
- [ ] Preferred communication style? Slack-first? Email? Regular calls or async?
- [ ] Has the customer been told about the handover? If not, agree on how to introduce the new TAM

##### 2. Commercial context

- [ ] Open proposals or negotiations – anything in-flight that needs immediate follow-up?
- [ ] Renewal strategy – what's the plan? Any risks?
- [ ] Discount/credit context – why were discounts given? What was promised?
- [ ] Budget & procurement – annual budget cycle, procurement process, finance contacts
- [ ] Expansion potential – realistic growth ceiling? New teams, new brands, new products?

##### 3. Technical & product state

- [ ] Implementation maturity – basic tracking or advanced setup?
- [ ] Known technical issues – open bugs, workarounds, or frustrations?
- [ ] Integration landscape – what else are they using? Any competitors still in play?
- [ ] Product gaps – feature requests or limitations that are blockers? Note any features with committed delivery timelines from our product teams
- [ ] Onboarding completeness – per the onboarding checklist, which products are properly onboarded?

##### 4. Risks & opportunities

- [ ] Top risks – what keeps you up at night? Champion risk, competitor risk, budget risk?
- [ ] Top opportunities – lowest-hanging fruit for expansion or deeper adoption?
- [ ] Unfinished business – anything you wanted to do but didn't get to?
- [ ] Anything I should avoid? Sensitive topics, past friction, internal politics?

#### After the handover call

##### Immediate actions (within 1 week)

- [ ] Update Vitally – ensure New Owner trait is set, update account plan note with handover context
- [ ] Save an account plan – create or update the account plan as a Vitally note, incorporating handover insights
- [ ] Introduce yourself to the customer – warm intro (ideally the TAE introduces you) or cold intro via Slack/email
- [ ] Follow up on any open items – pick up in-flight proposals, unresolved tickets, or pending conversations

#### Tips for a good handover

- Focus the call on what's not in the data. You can read Vitally yourself – use the call for relationship context, political dynamics, and unwritten history.
- Ask "what would you do next if you were keeping this account?" This often surfaces the most actionable insight.
- Move fast on your intro. The longer the gap between handover and first contact, the more momentum you lose.
- Keep the previous owner in the loop for the first few weeks if there are open commercial conversations. In some cases they can also serve as a secondary support point for timezone coverage or as an escalation contact.

#### Unassign yourself in Vitally

Once the handover is complete, the outgoing owner should unassign themselves from the account in Vitally. This ensures the new owner is the sole point of contact and avoids confusion about who is responsible for the account.

---

### Receiving an account as a CSM

CSM accounts should generally be in a steady state — they're using the products they need, they're engaged, and there aren't major unresolved issues. When you're taking an account from a TAE or TAM, it's worth looking beyond the surface to make sure that's actually the case. These aren't a rigid checklist. They're things to dig into that can surface problems which are otherwise easy to miss.

#### Billing and commercial

- Open invoices — verify these have been resolved per the handover requirements above. You don't want your first interaction with a customer to be chasing payment.
- MRR trajectory — is spend steady, declining, increasing, or swinging around? Declining or volatile MRR is worth digging into before you take over.
- Credit purchases — if they've pre-purchased credits, does the amount actually line up with what they're spending month to month?
- Non-standard discounts — review the contract for anything unusual or undocumented. If discounts exist without clear documentation, get context from the previous owner.

#### Product adoption

- Core product coverage — see TAM vs CSM for the general criteria. We currently have capacity on the CSM side, so we're okay receiving accounts using only 1 core product if the previous owner has determined there isn't a realistic path to expand.
- Deployment health — if the customer doesn't have basic recommendations in place (e.g. session replay minimum duration, high identify call volume), that's a flag. Check the customer deployment health check guide and the Metabase dashboard to assess this. The product onboarding checklist is also a good reference for what "properly set up" looks like.
- Unexplained usage changes — big spikes or drops that aren't documented, or where there's no record of a conversation with the customer about them. These can indicate problems nobody's looked into yet.

#### Engagement

- One-sided relationship — is there a pattern of outreach from our side with no customer engagement? If it's been a one-sided conversation, understand why before you take over.
- User concentration — is usage concentrated among fewer than 3 users? That's inherently risky. Have there been attempts to engage beyond those users? If so, why haven't they been successful?

#### Account documentation

- Account plan — one should already exist per the handover requirements above. Check that it's actually there and current — don't assume.

#### Lower priority

Worth being aware of, but less likely to be blockers:

- Open support tickets — any unresolved tickets or known frustrations with specific products?
- Upcoming features — anything in the pipeline that's relevant to this customer and worth proactively sharing?

#### Pushing back

If you're seeing multiple flags — declining usage, no engagement, concentrated users, missing account plan — push back. An account with several of these signals isn't in steady state and probably needs more work from the previous owner before it's ready for CSM. Talk to Dana if you're unsure whether to accept an account.

---

### High potential customers

For TAE-led customers who will be landing at $100k+ a year or have high expansion potential into new product areas, we should introduce a TAM earlier on than normal.

The prime time for this is when the technical win is confirmed - the TAM should be introduced to the customer by the TAE in an evaluation or POC wrap-up call when we know that the customer has selected PostHog.

The introduction is purely for relationship building and continuity purposes so that the TAM can hit the ground running with the customer after the initial credit pre-purchase is signed. It's still on the TAE to work with the customer on the deal, and as such only the TAE will be recognized on the initial deal for commission purposes. After the initial deal is closed won the TAM will take over the account in their book of business.

The TAE and TAM should use their overlapping time to work with the customer on a documented onboarding plan per the above guidance.

Canonical URL: https://posthog.com/handbook/growth/sales/account-allocation

GitHub source: contents/handbook/growth/sales/account-allocation.md

Content hash: `d944af7cb3cebb84`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: Product.