From dabf016b2c186d22b1a50905de26eb5501d3a898 Mon Sep 17 00:00:00 2001 From: danazou <52993274+danazou@users.noreply.github.com> Date: Tue, 11 Aug 2026 18:03:54 +0100 Subject: [PATCH 1/3] Handbook: require renewal context in handover notes, add trial credits page Handover notes must now document who on the customer side owns the renewal (champion vs procurement, how long the last one took, quirks) and whether a valid payment method is on file. Adds a new cross-selling page on sizing credit offers for new product trials. Generated-By: PostHog Desktop Task-Id: eec054f2-b378-4724-9f27-91996a4384a5 --- .../growth/cross-selling/trial-credits.md | 27 +++++++++++++++++++ contents/handbook/growth/revops/credits.md | 2 +- .../growth/sales/account-allocation.md | 10 ++++--- src/navs/index.js | 4 +++ 4 files changed, 39 insertions(+), 4 deletions(-) create mode 100644 contents/handbook/growth/cross-selling/trial-credits.md diff --git a/contents/handbook/growth/cross-selling/trial-credits.md b/contents/handbook/growth/cross-selling/trial-credits.md new file mode 100644 index 000000000000..08af7aa174d0 --- /dev/null +++ b/contents/handbook/growth/cross-selling/trial-credits.md @@ -0,0 +1,27 @@ +--- +title: Trial credits for new products +sidebar: Handbook +showTitle: true +--- + +Credits are usually the fastest way to get a customer trying a new product: they remove "what will this cost me to evaluate?" without touching the contract. The mechanics of adding credits are covered in [giving credits to customers](/handbook/growth/revops/credits). This page covers the part that used to live in scattered Slack threads: what a reasonable offer actually looks like. + +## Sizing the offer + +**Scale it to the account.** A reasonable offer for a $200k account is not a reasonable offer for a $15k one. Anchor on what the product would realistically cost this customer per month at their volume, then cover enough of that for a real evaluation. A flat number applied to every account is too small to matter for the big ones and a giveaway for the small ones. + +**Set the trial up for realistic spend.** The credits should let the customer run the product the way they actually would, at their real volume, for the length of the trial. If they can only afford toy usage, the trial tells neither side anything: they don't learn whether it's valuable, and we don't learn whether they'd pay for it. Estimate what the trial period costs at their real volume and use that as the baseline. Timebox it (credits to cover X weeks or months of realistic usage), so the trial has a natural end and a decision point. + +**Run the comfort test.** If you'd hesitate to post the number and your reasoning in a public Slack channel, either the offer is too big or you don't have the reasoning yet. Work out which before you send it. + +## Before you offer + +**Involve the team that builds the product.** They know what realistic usage actually costs (some products meter differently, e.g. credit budgets or quotas rather than per-event pricing), they can sanity-check your estimate, and for newer products they often want to work directly with early customers. A quick message in their channel before the offer goes out is cheap and regularly changes the number. + +**Check whether an official offer already exists.** For new or pre-GA products, the owning team or marketing may already have a standard credit offer for alpha and beta testers. Ask before inventing your own number, so two customers don't get wildly different offers for the same product depending on who they talked to. + +## When the trial ends + +The point of the credits is a decision, not indefinitely free usage. When the timebox runs out, have the conversation: what did they learn, what would ongoing usage cost, and are they in? If they need more time, extending is fine, but it should be a deliberate second offer, not a trial that quietly never ends. + +Whatever you offer, record it: the credit itself goes in via [billing admin](/handbook/growth/revops/credits) with notes and a reference link, and the context (what was offered, why, and until when) belongs in Vitally so the next owner isn't guessing. diff --git a/contents/handbook/growth/revops/credits.md b/contents/handbook/growth/revops/credits.md index f7391f99189c..b706abd26c60 100644 --- a/contents/handbook/growth/revops/credits.md +++ b/contents/handbook/growth/revops/credits.md @@ -4,7 +4,7 @@ sidebar: Handbook showTitle: true --- -Sometimes we might want to offer a customer one time credits to cover an upcoming invoice, for example when accommodating a trial for a new product or offering compensation for a recent incident. Here’s how to do that. +Sometimes we might want to offer a customer one time credits to cover an upcoming invoice, for example when accommodating a trial for a new product or offering compensation for a recent incident. Here’s how to do that. If you're deciding how much to offer for a new product trial, see [trial credits for new products](/handbook/growth/cross-selling/trial-credits) first. - Go to Billing Admin → Credits - Click Add Credit at the top right. diff --git a/contents/handbook/growth/sales/account-allocation.md b/contents/handbook/growth/sales/account-allocation.md index 1b34684bef60..2b609acc7995 100644 --- a/contents/handbook/growth/sales/account-allocation.md +++ b/contents/handbook/growth/sales/account-allocation.md @@ -85,7 +85,7 @@ TAM removals generally happen at the end of the quarter. Accounts can be added t The CSM stays on, so nothing about the customer relationship changes from their side. But the TAM knows things the CSM doesn't, and that context has to land somewhere before they leave: -- **A handover note in Vitally** covering: what expansion plays were run and how they went, commercial context (discounts given and why, anything promised, credit terms), open threads, and who the real decision makers are. Use the [handover note skill](https://github.com/PostHog/skills/tree/main/skills/team/product-led-sales/account-handover). +- **A handover note in Vitally** covering: what expansion plays were run and how they went, commercial context (discounts given and why, anything promised, credit terms), open threads, and who the real decision makers are. The note must also document who on the customer side owns the renewal (champion or procurement? how long did the last one take, and what quirks should the next owner expect?) and whether there's a valid payment method on file (and if not, why not). Use the [handover note skill](https://github.com/PostHog/skills/tree/main/skills/team/product-led-sales/account-handover). - **A 15 minute call with the CSM** to cover what's not in the data. Politics, sensitivities, what you'd try next if a new opportunity shows up. - **The Slack channel stays open.** The CSM keeps it. Don't archive it. Channel archival only applies when an account exits managed coverage entirely. - **Removing the TAM in Vitally.** Once the note and call are done, the team lead removes the TAM and the `AM Managed` segment from the account, with Ben's approval. @@ -158,7 +158,7 @@ TAM add and removal aren't handoffs, since the CSM stays throughout. See [Adding 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. +> 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. Check there's a valid payment method on file too – if there isn't, the handover note needs to say why not, because a renewal with no way to pay is blocked no matter how good the relationship is. > 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. @@ -229,7 +229,7 @@ The incoming TAM should prepare by reviewing the following in Vitally and SFDC b #### 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 +- [ ] **Billing & contract details** – annual plan dates, credit balances, discounts, renewal date, billing limits, and whether there's a valid payment method on file (check Stripe) - [ ] **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 tickets in [PostHog Support](https://us.posthog.com/project/2/support/tickets), tags, priority, resolution status @@ -263,6 +263,8 @@ This is the most valuable part of the handover – relationship context doesn't - [ ] **Open proposals or negotiations** – anything in-flight that needs immediate follow-up? - [ ] **Renewal strategy** – what's the plan? Any risks? +- [ ] **Renewal ownership** – who on the customer side owns the renewal? Is that the champion or procurement? How long did the last renewal take, and what quirks should you expect (security review, legal redlines, PO process)? +- [ ] **Payment method** – is there a valid payment method on file? If not, why not, and what's the plan to fix it before the renewal? - [ ] **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? @@ -311,6 +313,8 @@ CSMs receive every $20k+ account, whether from a TAE at close or when a TAM come ### Billing and commercial - **Open invoices** — verify these have been resolved per the [handover requirements above](#handing-over-customers). You don't want your first interaction with a customer to be chasing payment. +- **Payment method** – is there a valid payment method on file? The handover note should say, and if there isn't one, it should say why not. Sort this out early rather than discovering it at renewal time. +- **Renewal ownership** – the handover note should name who on the customer side owns the renewal (champion or procurement), how long the last one took, and any quirks. If it doesn't, go back to the previous owner and get it. - **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. diff --git a/src/navs/index.js b/src/navs/index.js index 7f4f7fac9d3c..0189bc6d3e89 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -1596,6 +1596,10 @@ export const handbookSidebar = [ name: 'Cross sell motions', url: '/handbook/growth/cross-selling/cross-sell-motions', }, + { + name: 'Trial credits for new products', + url: '/handbook/growth/cross-selling/trial-credits', + }, { name: 'Error Tracking cross-sell', url: '/handbook/growth/cross-selling/error-tracking-cross-sell', From bc0e205942f5323380ca4822c97eb6a38575ec9c Mon Sep 17 00:00:00 2001 From: danazou <52993274+danazou@users.noreply.github.com> Date: Tue, 11 Aug 2026 18:10:48 +0100 Subject: [PATCH 2/3] Fold trial credit sizing into cross-sell motions instead of a standalone page Replaces the new trial-credits page with a compact "How much credit is reasonable?" block under the existing Trial/Evaluation incentives section, and points the credits mechanics page there. Generated-By: PostHog Desktop Task-Id: eec054f2-b378-4724-9f27-91996a4384a5 --- .../cross-selling/cross-sell-motions.md | 9 +++++++ .../growth/cross-selling/trial-credits.md | 27 ------------------- contents/handbook/growth/revops/credits.md | 2 +- src/navs/index.js | 4 --- 4 files changed, 10 insertions(+), 32 deletions(-) delete mode 100644 contents/handbook/growth/cross-selling/trial-credits.md diff --git a/contents/handbook/growth/cross-selling/cross-sell-motions.md b/contents/handbook/growth/cross-selling/cross-sell-motions.md index c85183ea0f5f..0aad73d5c64e 100644 --- a/contents/handbook/growth/cross-selling/cross-sell-motions.md +++ b/contents/handbook/growth/cross-selling/cross-sell-motions.md @@ -294,6 +294,15 @@ You may want to consider expanding usage of the same product within the same tea ## Trial/Evaluation incentives If we want customers to use more products, we should incentivize new product adoption. This could be in the form of credits for a specific timeframe to cover adoption and usage of the specific product. For example, if a customer wants to try out data warehouse, we offer 2-3 months of credit for any data warehouse usage as they figure out how they would use it and where it provides additional insight. +### How much credit is reasonable? + +- **Scale it to the account.** Anchor on what the product would cost this customer at their real volume. A flat number is too small to matter for big accounts and a giveaway for small ones. +- **Cover realistic usage, timeboxed.** Enough credits to run the product the way they actually would for a set period, so the trial ends with a decision point. Extending is fine, but that's a deliberate second offer, not a trial that quietly never ends. +- **Run the comfort test.** If you'd hesitate to post the number and your reasoning in a public Slack channel, the offer is too big or the reasoning isn't there yet. +- **Loop in the team that builds the product.** They know what realistic usage costs, and for new or pre-GA products there may already be an official alpha/beta credit offer. Check before inventing your own number. + +The mechanics of actually adding the credit are covered in [giving credits to customers](/handbook/growth/revops/credits). + We have opportunities to get creative with how we incentivize new product adoption with users. A few ideas are: - Bring them over at competitor pricing for X months diff --git a/contents/handbook/growth/cross-selling/trial-credits.md b/contents/handbook/growth/cross-selling/trial-credits.md deleted file mode 100644 index 08af7aa174d0..000000000000 --- a/contents/handbook/growth/cross-selling/trial-credits.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Trial credits for new products -sidebar: Handbook -showTitle: true ---- - -Credits are usually the fastest way to get a customer trying a new product: they remove "what will this cost me to evaluate?" without touching the contract. The mechanics of adding credits are covered in [giving credits to customers](/handbook/growth/revops/credits). This page covers the part that used to live in scattered Slack threads: what a reasonable offer actually looks like. - -## Sizing the offer - -**Scale it to the account.** A reasonable offer for a $200k account is not a reasonable offer for a $15k one. Anchor on what the product would realistically cost this customer per month at their volume, then cover enough of that for a real evaluation. A flat number applied to every account is too small to matter for the big ones and a giveaway for the small ones. - -**Set the trial up for realistic spend.** The credits should let the customer run the product the way they actually would, at their real volume, for the length of the trial. If they can only afford toy usage, the trial tells neither side anything: they don't learn whether it's valuable, and we don't learn whether they'd pay for it. Estimate what the trial period costs at their real volume and use that as the baseline. Timebox it (credits to cover X weeks or months of realistic usage), so the trial has a natural end and a decision point. - -**Run the comfort test.** If you'd hesitate to post the number and your reasoning in a public Slack channel, either the offer is too big or you don't have the reasoning yet. Work out which before you send it. - -## Before you offer - -**Involve the team that builds the product.** They know what realistic usage actually costs (some products meter differently, e.g. credit budgets or quotas rather than per-event pricing), they can sanity-check your estimate, and for newer products they often want to work directly with early customers. A quick message in their channel before the offer goes out is cheap and regularly changes the number. - -**Check whether an official offer already exists.** For new or pre-GA products, the owning team or marketing may already have a standard credit offer for alpha and beta testers. Ask before inventing your own number, so two customers don't get wildly different offers for the same product depending on who they talked to. - -## When the trial ends - -The point of the credits is a decision, not indefinitely free usage. When the timebox runs out, have the conversation: what did they learn, what would ongoing usage cost, and are they in? If they need more time, extending is fine, but it should be a deliberate second offer, not a trial that quietly never ends. - -Whatever you offer, record it: the credit itself goes in via [billing admin](/handbook/growth/revops/credits) with notes and a reference link, and the context (what was offered, why, and until when) belongs in Vitally so the next owner isn't guessing. diff --git a/contents/handbook/growth/revops/credits.md b/contents/handbook/growth/revops/credits.md index b706abd26c60..0af5c46690aa 100644 --- a/contents/handbook/growth/revops/credits.md +++ b/contents/handbook/growth/revops/credits.md @@ -4,7 +4,7 @@ sidebar: Handbook showTitle: true --- -Sometimes we might want to offer a customer one time credits to cover an upcoming invoice, for example when accommodating a trial for a new product or offering compensation for a recent incident. Here’s how to do that. If you're deciding how much to offer for a new product trial, see [trial credits for new products](/handbook/growth/cross-selling/trial-credits) first. +Sometimes we might want to offer a customer one time credits to cover an upcoming invoice, for example when accommodating a trial for a new product or offering compensation for a recent incident. Here’s how to do that. If you're deciding how much to offer for a new product trial, see [trial/evaluation incentives](/handbook/growth/cross-selling/cross-sell-motions#trialevaluation-incentives) first. - Go to Billing Admin → Credits - Click Add Credit at the top right. diff --git a/src/navs/index.js b/src/navs/index.js index 0189bc6d3e89..7f4f7fac9d3c 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -1596,10 +1596,6 @@ export const handbookSidebar = [ name: 'Cross sell motions', url: '/handbook/growth/cross-selling/cross-sell-motions', }, - { - name: 'Trial credits for new products', - url: '/handbook/growth/cross-selling/trial-credits', - }, { name: 'Error Tracking cross-sell', url: '/handbook/growth/cross-selling/error-tracking-cross-sell', From dd27ff914a8d2c1f2081cacc33086b42c5d1b9d9 Mon Sep 17 00:00:00 2001 From: danazou <52993274+danazou@users.noreply.github.com> Date: Tue, 11 Aug 2026 18:17:44 +0100 Subject: [PATCH 3/3] Lighten handover renewal additions, rebuild credit sizing around retroactive credits Renewal ownership folded concisely into the handover note list and call checklist; payment method reduced to a single checklist item. Credit sizing now leads with crediting retroactively (no per-product credits, upfront credits pad unrelated invoices), timeboxed 2-3 months with a cap. Generated-By: PostHog Desktop Task-Id: eec054f2-b378-4724-9f27-91996a4384a5 --- .../growth/cross-selling/cross-sell-motions.md | 12 ++++++++---- contents/handbook/growth/sales/account-allocation.md | 11 ++++------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/contents/handbook/growth/cross-selling/cross-sell-motions.md b/contents/handbook/growth/cross-selling/cross-sell-motions.md index 0aad73d5c64e..fade2e90b788 100644 --- a/contents/handbook/growth/cross-selling/cross-sell-motions.md +++ b/contents/handbook/growth/cross-selling/cross-sell-motions.md @@ -296,10 +296,14 @@ If we want customers to use more products, we should incentivize new product ado ### How much credit is reasonable? -- **Scale it to the account.** Anchor on what the product would cost this customer at their real volume. A flat number is too small to matter for big accounts and a giveaway for small ones. -- **Cover realistic usage, timeboxed.** Enough credits to run the product the way they actually would for a set period, so the trial ends with a decision point. Extending is fine, but that's a deliberate second offer, not a trial that quietly never ends. -- **Run the comfort test.** If you'd hesitate to post the number and your reasoning in a public Slack channel, the offer is too big or the reasoning isn't there yet. -- **Loop in the team that builds the product.** They know what realistic usage costs, and for new or pre-GA products there may already be an official alpha/beta credit offer. Check before inventing your own number. +Credit retroactively rather than upfront. We don't have per-product credits, so an upfront credit pads whatever the customer's next invoices are, whether or not there's any usage of the new product on them. Let them use the product, then credit back what it cost. + +That shapes the sizing: + +- **Timebox it** – usually 2-3 months of usage, so the trial ends with a decision point. +- **Cap it** – agree an upper limit up front, scaled to the account, so trial usage of a metered product (e.g. Replay Vision) can't blow up our infra or margins. +- **Run the comfort test** – if you'd hesitate to post the number and your reasoning in a public Slack channel, the offer is too big or the reasoning isn't there yet. +- **Loop in the team that builds the product** – they know what realistic usage costs, and for new or pre-GA products there may already be an official alpha/beta credit offer. Check before inventing your own number. The mechanics of actually adding the credit are covered in [giving credits to customers](/handbook/growth/revops/credits). diff --git a/contents/handbook/growth/sales/account-allocation.md b/contents/handbook/growth/sales/account-allocation.md index 2b609acc7995..937353e8a53e 100644 --- a/contents/handbook/growth/sales/account-allocation.md +++ b/contents/handbook/growth/sales/account-allocation.md @@ -85,7 +85,7 @@ TAM removals generally happen at the end of the quarter. Accounts can be added t The CSM stays on, so nothing about the customer relationship changes from their side. But the TAM knows things the CSM doesn't, and that context has to land somewhere before they leave: -- **A handover note in Vitally** covering: what expansion plays were run and how they went, commercial context (discounts given and why, anything promised, credit terms), open threads, and who the real decision makers are. The note must also document who on the customer side owns the renewal (champion or procurement? how long did the last one take, and what quirks should the next owner expect?) and whether there's a valid payment method on file (and if not, why not). Use the [handover note skill](https://github.com/PostHog/skills/tree/main/skills/team/product-led-sales/account-handover). +- **A handover note in Vitally** covering: what expansion plays were run and how they went, commercial context (discounts given and why, anything promised, credit terms), open threads, who the real decision makers are, and who on the customer side owns the renewal (champion or procurement, and how the last one went). Use the [handover note skill](https://github.com/PostHog/skills/tree/main/skills/team/product-led-sales/account-handover). - **A 15 minute call with the CSM** to cover what's not in the data. Politics, sensitivities, what you'd try next if a new opportunity shows up. - **The Slack channel stays open.** The CSM keeps it. Don't archive it. Channel archival only applies when an account exits managed coverage entirely. - **Removing the TAM in Vitally.** Once the note and call are done, the team lead removes the TAM and the `AM Managed` segment from the account, with Ben's approval. @@ -158,7 +158,7 @@ TAM add and removal aren't handoffs, since the CSM stays throughout. See [Adding 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. Check there's a valid payment method on file too – if there isn't, the handover note needs to say why not, because a renewal with no way to pay is blocked no matter how good the relationship is. +> 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. @@ -229,7 +229,7 @@ The incoming TAM should prepare by reviewing the following in Vitally and SFDC b #### 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, and whether there's a valid payment method on file (check Stripe) +- [ ] **Billing & contract details** – annual plan dates, credit balances, discounts, renewal date, billing limits, valid payment method on file (in Stripe) - [ ] **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 tickets in [PostHog Support](https://us.posthog.com/project/2/support/tickets), tags, priority, resolution status @@ -263,8 +263,7 @@ This is the most valuable part of the handover – relationship context doesn't - [ ] **Open proposals or negotiations** – anything in-flight that needs immediate follow-up? - [ ] **Renewal strategy** – what's the plan? Any risks? -- [ ] **Renewal ownership** – who on the customer side owns the renewal? Is that the champion or procurement? How long did the last renewal take, and what quirks should you expect (security review, legal redlines, PO process)? -- [ ] **Payment method** – is there a valid payment method on file? If not, why not, and what's the plan to fix it before the renewal? +- [ ] **Renewal ownership** – who on the customer side owns the renewal, the champion or procurement? How long did the last one take? - [ ] **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? @@ -313,8 +312,6 @@ CSMs receive every $20k+ account, whether from a TAE at close or when a TAM come ### Billing and commercial - **Open invoices** — verify these have been resolved per the [handover requirements above](#handing-over-customers). You don't want your first interaction with a customer to be chasing payment. -- **Payment method** – is there a valid payment method on file? The handover note should say, and if there isn't one, it should say why not. Sort this out early rather than discovering it at renewal time. -- **Renewal ownership** – the handover note should name who on the customer side owns the renewal (champion or procurement), how long the last one took, and any quirks. If it doesn't, go back to the previous owner and get it. - **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.