PostHog Handbook Library / Growth

2,859 words. Estimated reading time: 13 min.

# Risk mitigation and churn prevention

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. Risk mitigation (proactive)
2. Quarterly account planning
3. Quarterly plan
4. Ongoing updates
5. Early warning signals
6. Drive adoption of behavioral products
7. Implementation health
8. De risking common churn scenarios

If you're actively thinking about churn prevention in response to a customer churn threat or major red flag, it's already way too late.

Churn prevention is best done from early, and often, risk mitigation practices.

We should default to flagging "at risk" accounts by adding the "Churn Risk" tag in PostHog Customer Analytics well before the customer has told you they are exploring alternatives. If you have the slightest inkling that something may look off or something has you feeling a bit uncomfortable, flag it. This could be anything from not taking action on a recommendation you gave them for too long, down-trending volume with no apparent seasonality cause, only one or two core users of the platform, or no Slack activity for an extended period. To name a few.

There are a few risk-mitigation strategies you'll want to incorporate that serve as early detection and proactive mitigation, as well as a process for what to do when an account is actively at risk.

---

### Risk mitigation (proactive)

Risk mitigation is about building habits that surface problems before they become emergencies. If you're doing this well, you'll rarely need the reactive playbook below.

#### Quarterly account planning

Every managed account should have an Account Plan note created in PostHog Customer Analytics, on the account's profile, once per quarter. You should also review this regularly with your manager and update it as needed. This forces you to step back and evaluate the account holistically rather than just reacting to whatever's in front of you.

The plan can be broken into two parts: the quarterly plan and ongoing updates.

##### Quarterly plan

Title format: `Q[X] Account Plan - [Company Name]`

Add the plan as an account note in PostHog Customer Analytics on the account's profile. For each account, work through these seven questions:

1. What type of opportunities (opps) are there this quarter? Name each one – conversion (moving a pay-as-you-go plan onto a discounted credit plan), renewal (securing an existing contract for another term), or cross-sell (getting them onto a product they aren't using yet) – so you're clear on what you're actually driving toward.
2. What are the customer's business objectives? Capture what they're trying to achieve with PostHog and how it connects to their broader goals so it's clear what they are – and if you don't know, say so, so the gap is visible.
3. What's the desired outcome for the account by the end of the quarter? State the concrete result you want (renewal signed, in with a new team, Error Tracking adopted) so success is measurable rather than vague.
4. Does the customer know about this plan? Note whether you've aligned with them, because a plan they haven't bought into is just a guess.
5. Is it blocked on anything right now, and are there any other risks? Call out current blockers and any other risks so you can get ahead of them before they derail the outcome.
6. Link to the SFDC opp. Drop in the Salesforce opportunity link so anyone reviewing can jump straight to the deal.
7. Who are the key players? List the stakeholders – champions, budget holders, technical evaluators, and end-users – and where you stand with each.

##### Ongoing updates

1. What did you do with them last week.
2. Any risks to flag or opportunities you are working
3. Who are you talking to
4. What are you working on with them this week

This can largely mirror what goes in our sprint planning, and shouldn't be duplicate work.

#### Early warning signals

These aren't emergencies yet, but they should make you pay closer attention. Many of these are also tracked automatically as risk indicators in Vitally.

| Signal | Why it matters | |--------|----------------| | Recommendation not actioned for 2+ weeks | They're not engaging with your guidance | | Down-trending event volume (no seasonality) | Usage decline is a leading indicator of churn | | Only 1-2 active users | Single point of failure, low organizational buy-in | | No Slack activity for 14+ days | Relationship is going cold | | Billing page visits without context | They're evaluating costs, possibly shopping around | | Champion changed roles or left | Your internal advocate is gone | | Support tickets spiking | Something is broken or frustrating | | Single product usage | Low switching cost, easy to replace | | Data exported to external warehouse only | PostHog becomes a pipe, not a destination |

When you notice any of these, don't wait. Reach out, dig in, and address it before it compounds.

#### Drive adoption of behavioral products

Not all PostHog products carry the same switching cost. Customers who primarily use PostHog as a data pipe to an external warehouse are structurally riskier. If their analysts query Snowflake or BigQuery, PostHog becomes invisible and replaceable.

Behavioral products create stickiness because they're used directly in PostHog's UI and embed into day-to-day workflows:

| Product | Why it's sticky | |---------|-----------------| | Surveys | Active feedback collection tied to user segments. Hard to replicate externally. | | Cohorts | Saved user segments used across insights, feature flags, and experiments. Accumulated investment. | | Workflows | Automated actions triggered by product events. Operational dependency. | | Feature flags & experiments | Engineering teams build release processes around them. Deep integration. | | Session replay | Qualitative context that doesn't exist in a data warehouse. Unique value. |

When you see a customer heavily reliant on data pipelines and external analytics, proactively introduce behavioral products. Frame it as expanding what they can do, not replacing their warehouse workflow. The goal is to make PostHog the place where decisions get made, not just where data passes through.

Practical moves:

- Show them how cohorts can power targeted surveys or experiments
- Demo how session replay answers "why" questions that SQL can't
- Introduce workflows for automated follow-ups based on product events
- Help them build dashboards they actually use inside PostHog

If they're doing all their analysis in Looker or Mode, ask why. Sometimes it's habit, sometimes it's a gap we can fill. See communication templates for new feature adoption for outreach examples.

#### Implementation health

A lot of customers self-serve without ever talking to a PostHog human. This means they can implement PostHog in ways that cause problems down the road: inflated bills, inaccurate data, or features that don't work as expected. Left unchecked, these issues lead to avoidable churn.

Proactively check for common implementation issues, especially for newer accounts or accounts that haven't had a technical review. See checking the health of a customer's deployment for the full checklist.

When a customer wants to cut costs

If a customer expresses interest in reducing their PostHog spend, view it as an opportunity to act in their interest, help them optimize, and stabilize the relationship. The fact that they're telling you is a signal of trust. Deepen that trust by helping them save money (which is a totally reasonable goal to support).

- First, help them do what they asked, fast. At this point, the customer already decided that they need to cut costs, so don't lead with discovery questions that may suggest an effort to talk them out of that decision. Take action on their request first. Gather context along the way or after.
- Give them actionable ways to reduce spend. This is where your product expertise comes into play - what are the concrete levers they can pull to reduce spend? Customer health check is a good starting point to identify opportunities to reduce billing waste.
- Be transparent about trade-offs, but frame them as information, not as warnings. The goal is to help them make an informed decision, not to reopen the question. For example, if they don't want to pay for Product Analytics, let them know we'll stop ingesting events past the free tier. Frame this as "here's what to expect" rather than "are you sure?" Proactively flag non-obvious dependencies between products too; if you’re not sure, do some digging - use #ask-max, PostHog AI, ask the rest of the sales team, or ask the relevant product team in Slack (and add some commentary so they can better assist you).
- Consider proposing a target spend. Once you've acted on their initial request, consider aligning on a target monthly spend. You can then work backwards from that goal to improve their implementation and shape how you support them going forward.
- Pause any cross-selling or expansion work until they're at their target monthly spend. You make the call on when the relationship is stable enough to recommend increased adoption of our products, but it's a safe bet to pause on this while they're in the process of lowering their spend.

Billing waste:

- Group Analytics enabled but not implemented. We have a Vitally risk indicator for this. If they're B2B and could benefit, help them implement it. If not, tell them to remove the add-on.
- Autocapture noise. If >50% of events are autocapture and they haven't defined any autocapture actions, they're likely paying for events they don't use. Help them tune or disable it.
- Session replay capturing everything. Default settings capture all sessions. At minimum, recommend setting minimum duration to 2+ seconds to filter out low-value recordings.

Tracking issues that erode trust:

- Calling identify() on every page. Inflates event volume dramatically. They only need to call it once per session.
- Calling group() on every page. Same problem. Once per group per session is enough, or when the group changes.
- Calling posthog.reset() before identify. Creates unlinked anonymous users. Common culprit when web-to-app tracking seems broken. See guidance in the JavaScript Web SDK usage guide.
- No reverse proxy. Best practice is to use PostHog's managed reverse proxy or configure their own. Events from their own domain improve reliability and ad-blocker resistance.

Feature flag resilience:

- No fallback code. If flags fail to load, the app should still work. Check that they're falling back to working code when flags return unexpected values.
- No local evaluation (server-side). Server-side local evaluation ensures flags work regardless of network status. Important for reliability.

When you find implementation issues, don't just tell them what's wrong. Help them fix it. A customer who had a billing problem you solved is more loyal than one who never had a problem at all.

#### De-risking common churn scenarios

Most churn follows predictable patterns. See common churn reasons for the full list. Here's how to de-risk the scenarios we have some control over:

| Churn scenario | De-risking strategy | |----------------|---------------------| | Champion leaves | Multi-thread relationships across teams. The more users actively in PostHog, the less one departure matters. | | Champion isn't the decision maker | Identify and build relationships with actual decision makers. Your champion can help with introductions. | | Customer builds internally or switches to competitor | Drive multi-product adoption. Harder to replace five products than one. | | Poor customer experience | Stay on top of open issues proactively. Circle back before they have to follow up. Rebuild trust through responsiveness. | | Customer can't extract value | Offer workshops, training, or hands-on help building specific insights. Don't wait for them to ask. | | Missing critical feature | Loop in the relevant PM and engineering team. Be transparent about what we can and can't do. Make sure the request is also tracked in Vitally | | PostHog isn't trusted as source of truth | Dig into data discrepancies. Often an implementation issue. If they're exporting everything to another tool, they're one step from leaving. | | Privacy/compliance concerns | Help them understand data controls, masking, privacy controls, cookieless tracking, and data deletion options. Often they assume they can't use features when they actually can. |

For scenarios outside our control (acquisition, company shuts down, not ICP fit), document what happened and share learnings with the team. There's usually something we can learn even when we couldn't have changed the outcome.

---

### Churn prevention (reactive)

When an account is actively at risk (they've told you they're evaluating alternatives, usage has cratered, or you've lost a champion) you need to move fast and follow a clear process.

#### When to flag an account as at risk

Add the Churn Risk tag to the account in PostHog Customer Analytics if any of the following are true:

- Customer explicitly mentions evaluating alternatives or considering churning
- Usage has dropped 30%+ with no seasonal explanation
- Key champion has left and no replacement relationship exists
- Payment has failed and they're unresponsive
- They've asked for a full data export
- Health score has been "Poor" for 4+ consecutive weeks
- Contract is up for renewal in <90 days with negative engagement signals
- They're not using PostHog as source of truth (all analysis happens externally)

When in doubt, flag it. It's easier to remove a flag than to explain why we didn't see a churn coming.

#### Internal process

1. Add the Churn Risk tag in PostHog Customer Analytics

When you flag an account as at risk, add the Churn Risk tag to the account in PostHog Customer Analytics, and add a note on the account with:

- Account name and ARR
- What triggered the risk flag
- What you know about the situation
- What help you need (if any)
- What you are doing to mitigate the churn

Adding the tag triggers a PostHog workflow that automatically posts to the #customer-churn Slack channel. This keeps the team informed and surfaces accounts that might need additional support or visibility.

2. Weekly at-risk account review

We hold a weekly team meeting to review all accounts tagged Churn Risk in PostHog Customer Analytics. Come prepared to:

- Give a 60-second status update on each at-risk account you own
- Share what you've tried and what's working or not
- Ask for help or ideas from the team

The objective is accountability and support. If an account has been at-risk for 4+ weeks with no improvement, we need to either escalate for additional support or accept the loss and document learnings.

3. Escalation

Escalation means getting support at a higher level, not handing off the account. You remain the owner and primary contact. Use your best judgment on when to pull in additional resources:

- Engineering involvement: If there's a technical issue, bug, or feature gap that's driving the churn risk, loop in the relevant engineering team directly. Tag them in Slack, share context, and ask for their help.
- Product involvement: If the customer needs a feature we don't have or is struggling with product limitations, bring in the relevant PM. They may want to join a call to understand the use case.
- Leadership involvement: For strategic accounts or situations that need executive attention (pricing negotiations, product commitments, relationship rescue at the exec level), loop in your team lead. For accounts >$50k ARR at serious risk, involve Ben or Simon to get their perspective and support.

The goal of escalation is to get the right people involved to help you save the account, not to pass the problem to someone else. You're still driving the relationship and the recovery plan.

#### Recovery playbook

Once flagged, your job is to diagnose and act:

Diagnose the root cause. Is this price, product, relationship, implementation, or business change? You can't fix what you don't understand. Use the churn scenarios above as a checklist.

Get on a call. Don't try to save accounts over email. Get face-to-face (or video) time to have a real conversation.

Listen more than pitch. Understand their perspective fully before proposing solutions.

Be honest about gaps. If we can't do something they need, say so. Credibility matters more than closing a save. This aligns with our sales principles: we don't care about losing deals if we'd have to compromise on our principles.

Create a recovery plan. Document specific actions with dates and owners. Share it with the customer so they know you're taking this seriously.

Follow up relentlessly. A save isn't done until the risk is resolved and usage is stable. Check in weekly until you're confident.

#### When churn happens

Not every at-risk account can be saved. When a customer churns, write a retro and share it in #customer-churn as soon as possible while the details are fresh. See learn from churn for the template and guidance.

---

### Summary

| Activity | Cadence | |----------|---------| | Account Plan note in PostHog Customer Analytics | Quarterly | | Implementation health check | At onboarding + annually | | Early warning signal monitoring | Ongoing | | Behavioral product adoption push | Ongoing (especially for warehouse-heavy accounts) | | #customer-churn posts | As needed when flagging risk | | At-risk account review meeting | Weekly | | Recovery calls with at-risk accounts | Within 48 hours of flagging | | Churn retros in #customer-churn | Within 1 week of churn |

The best churn prevention is never needing to prevent churn. Build the habits, check implementation health, drive behavioral product adoption, and catch problems early.

Canonical URL: https://posthog.com/handbook/growth/sales/risk-mitigation-and-churn-prevention

GitHub source: contents/handbook/growth/sales/risk-mitigation-and-churn-prevention.md

Content hash: `c6b66386ac2d700f`