PostHog Inbound Lead Disposition
Evaluate inbound leads from Salesforce and either draft a response email or recommend a disposition. This skill is for any PostHog TAE handling inbound sales inquiries.
Core Workflow
- Ingest lead context — Read whatever the TAE provides (Salesforce fields, email body, notes)
- Check Vitally for existing account context — Search for the lead's email and email domain (see Step 0 below)
- Research the company — Web search to understand who they are, their funding, size, and growth trajectory (see Step 1 below)
- Identify the use case — Map the lead to one or more of PostHog's six use cases, informed by company research (see Step 2 below)
- Qualify the lead — Apply the disposition framework, informed by company research and growth trajectory (see Step 3 below)
- Recommend a disposition — State the recommended action and identified use case(s) clearly
- Draft a response — Write the appropriate email, framed around their use case (see Step 4 below)
- Validate all URLs — Fetch every link in the draft email to confirm it resolves and points to the intended content (see Step 5 below)
Step 0: Check Vitally for Existing Account Context
Before qualifying or drafting anything, check Vitally to see if this lead (or their company) is already a PostHog user. This changes the disposition and email framing significantly — an existing customer asking for help is different from a cold inbound.
What to check
Run two Vitally lookups using the lead's email address:
- Search by exact email —
vitally:search_users with email set to the lead's email address. This tells you if this specific person already has a PostHog account.
- Search by email domain —
vitally:search_users with emailSubdomain set to the domain portion of the lead's email (e.g., acme.com from jane@acme.com). This tells you if anyone at their company is already using PostHog.
If either search returns results, pull up the associated account with vitally:get_account_full using the accountId from the user record(s). Use detailLevel: "summary" for a quick overview.
How to use what you find
Lead's email is an existing user:
- They're already in PostHog. The email should acknowledge this ("I can see you're already using PostHog") and focus on their specific ask rather than onboarding-style resources.
- Check their account's MRR and health score — this informs whether they're a self-serve user reaching out to grow, or an existing account with an expansion opportunity.
Different person at the same company is already a user:
- Their company is already on PostHog. Reference this in the email ("I see your team is already using PostHog") and ask how their request relates to the existing usage.
- Check who else is on the account — the lead may need to connect with the internal champion rather than start a separate evaluation.
- If the account already has a TAE assigned, flag this to avoid stepping on someone's book of business.
No results in Vitally:
- Net new lead. Proceed with the standard qualification workflow below.
What to surface to the TAE
When presenting the Vitally findings, include:
- Whether the person or company was found
- Account name and current MRR (if applicable)
- Health score (if applicable)
- Assigned TAE (if any — important for routing)
- Number of users on the account
- A one-line recommendation on how this changes the response (e.g., "Existing $3K/mo account, no TAE assigned — this is an expansion opportunity, not a new lead")
Step 1: Research the Company
This step is mandatory for every lead. The lead's form submission alone is not enough information to qualify or disqualify. A 10K MAU lead from a $6B startup and a 10K MAU lead from a 5-person agency require completely different dispositions.
What to research
Run 1-3 web searches to understand the company. Start with the company name and domain:
web_search for [Company Name] [domain] — Get the basics: what they do, who they are
web_search for [Company Name] funding employees — Get firmographics: funding stage, headcount, growth signals
- If the company appears to be notable or well-funded, search for recent news:
[Company Name] 2026 or [Company Name] news
What to extract
From the research, identify and record:
| Signal |
Why It Matters |
Example |
| What they build |
Determines use case mapping and whether they're ICP |
"AI tools for manufacturing" → AI/LLM Obs is relevant |
| Funding stage and amount |
Proxy for budget and growth trajectory |
Series B, $50M → likely has budget for tooling |
| Employee count |
Proxy for spend potential and team complexity |
200 employees → multiple teams, multi-project potential |
| Engineering team size or ratio |
PostHog's buyer is engineers; more engineers = better fit |
"80% of team is engineering" → strong ICP signal |
| Growth trajectory |
Determines whether current MAU is the ceiling or the floor |
Founded 6 months ago, hiring aggressively → MAU will grow fast |
| Recent news |
Acquisitions, launches, pivots that change context |
Just acquired an AI startup → expanding product surface |
| Business model |
SaaS, marketplace, dev tools, agency, etc. |
B2B SaaS → classic PostHog ICP |
Classify the growth trajectory
Based on the research, classify the company into one of four growth trajectories:
- Accelerating: Recent large funding round (especially if raised in last 12 months), aggressive hiring, early-stage with significant capital, or clear signs of rapid expansion. Current MAU is almost certainly not the ceiling. Examples: well-funded Series A+ startups, companies that just raised mega-rounds, companies with "hundreds of open roles."
- Steady: Established company, moderate and predictable growth. Current MAU is a reasonable proxy for near-term spend. Examples: mid-market SaaS with stable revenue, mature PLG companies.
- Early/unknown: New company, limited public information, hard to assess trajectory. Treat current MAU as the best available signal but note the uncertainty. Examples: pre-seed startups, stealth-mode companies with no public footprint.
- Flat/declining: No growth signals, layoffs, or signs of contraction. Current MAU may overstate future spend. Examples: companies with recent layoffs, shrinking teams.
The growth trajectory classification directly affects qualification. See Step 3 for how it modifies the $20K threshold.
Detect multi-product signals
While researching, watch for signals that the lead's company has (or is building) multiple products. This is a spend multiplier because each product typically becomes a separate PostHog project with its own event volume.
Signals in the lead's message:
- "some of our products" / "multiple products" / "across our portfolio"
- "several teams" / "multiple teams" / "different business units"
- "our platform and our apps" / "our web app and mobile app"
- "integrate into our stack" (implies breadth)
Signals from company research:
- Company has multiple product lines or brands
- Company recently acquired other companies (each acquisition may have its own product)
- Job postings reference multiple product teams
- Company website shows multiple distinct products
When multi-product signals are present, note the estimated product count (or range) and factor it into the MAU multiplier. A company with 5 products at 10K MAU each is a 50K MAU opportunity, not a 10K one.
Detect AI/ML company signals
If company research reveals the company is AI-native (building AI/ML products as their core business), flag AI/LLM Observability as a probable secondary use case even if the lead's message doesn't mention AI, LLMs, model costs, or prompts.
AI-native signals:
- Company description mentions AI, ML, LLM, or "artificial intelligence" as core to what they build
- Company is in an AI-adjacent industry (AI infrastructure, AI applications, AI research)
- Team is heavily ML/AI engineers
- Recent AI-related acquisitions or product launches
When detected, include AI/LLM Observability in the use case assessment and mention it in the email as a relevant capability, even if the lead didn't ask about it. Frame it as: "since you're building AI products, you might also find our LLM analytics useful for tracking model costs and performance."
What to surface to the TAE
Present the company research as a brief profile including:
- What the company does (one sentence)
- Funding and valuation (if available)
- Employee count and engineering composition (if available)
- Growth trajectory classification
- Multi-product signals (if any)
- AI-native flag (if applicable)
- Any notable context (recent news, acquisitions, leadership)
This goes right after the Vitally findings and before the use case assessment.
Step 2: Identify the Use Case
Every lead maps to one or more of PostHog's six use cases. Identifying the use case determines how to frame the response, what products to highlight, and what resources to link. Evaluate the person/persona, company (informed by your Step 1 research), and message to determine the match.
The Six Use Cases
| Use Case |
Job to Be Done |
Core Buyer Persona |
Key Signals in the Lead |
| Product Intelligence |
"Help me understand what users do, why they do it, and what to build next." |
PMs, designers, product engineers, founders |
Mentions analytics, funnels, retention, user behavior, "why users drop off", feature adoption, NPS, surveys, session replay for UX research |
| Release Engineering |
"Help me ship faster without breaking things." |
Engineering managers, platform teams, developers |
Mentions feature flags, rollouts, A/B testing releases, kill switches, progressive delivery, replacing LaunchDarkly |
| Observability |
"Help me know when things break, understand why, and fix them fast." |
SREs, platform engineers, DevOps |
Mentions error tracking, bug reproduction, replacing Sentry/Datadog, logging, incident response, stack traces |
| Growth & Marketing |
"Help me understand what drives acquisition, conversion, and revenue." |
Growth engineers, marketing leads, CRO, GTM engineers |
Mentions attribution, ROAS, campaign performance, replacing GA4/Segment, conversion optimization, onboarding automation, marketing stack consolidation |
| AI/LLM Observability |
"Help me understand how my AI features perform, what they cost, and how users interact with them." |
AI/ML engineers, AI PMs, AI founders |
Mentions LLM, AI features, model costs, prompt testing, AI quality, replacing Langfuse/Helicone, token usage. Also inferred from company research — if the company is AI-native, this use case is relevant even if the lead didn't mention it. |
| Data Infrastructure |
"Help me unify product data with business data and get it where it needs to go." |
Data engineers, analytics engineers, product ops |
Mentions data warehouse, Snowflake/BigQuery, data pipelines, batch exports, combining PostHog data with Stripe/CRM, replacing Segment/Fivetran |
Mapping Persona to Use Case
The person's role is one of the strongest signals:
- PM, Head of Product, UX Researcher, Designer → Product Intelligence
- Engineering Manager, VP Eng, Platform Engineer, Developer → Release Engineering (or Observability if they mention errors/incidents)
- SRE, DevOps, Infrastructure Engineer → Observability
- Growth Engineer, Marketing Lead, CRO, GTM Engineer, Demand Gen → Growth & Marketing
- AI/ML Engineer, AI PM, AI Founder → AI/LLM Observability
- Data Engineer, Analytics Engineer, Head of Data, RevOps → Data Infrastructure
- Founder/CTO (early stage) → Usually Product Intelligence or AI/LLM Obs depending on the product; may span multiple use cases
Mapping Company to Use Case
The company type (from your Step 1 research) helps narrow it:
- AI-native startup → AI/LLM Observability is almost always relevant, often alongside Product Intelligence
- PLG SaaS → Product Intelligence + Growth & Marketing are the most common pair
- Enterprise with multiple teams → Often starts as one use case but the expansion potential spans several
- E-commerce / marketplace → Growth & Marketing (conversion, attribution) + Product Intelligence (user behavior)
- Developer tools / infrastructure → Release Engineering + Observability
Mapping Message to Use Case
The specific ask confirms or overrides the persona/company signal:
- "We want to understand user behavior" → Product Intelligence
- "We need feature flags" or "replacing LaunchDarkly" → Release Engineering
- "We need error tracking" or "replacing Sentry" → Observability
- "We want attribution" or "replacing GA4" → Growth & Marketing
- "We're building AI features" or "LLM costs" → AI/LLM Observability
- "We need to get data into Snowflake" → Data Infrastructure
- Vague "show me features" / "want a demo" → Can't determine use case from the message alone; use company research to infer the most likely use case(s), then ask a targeted clarifying question to confirm
If the use case is ambiguous even after company research, include a targeted clarifying question in the email to narrow it down. Frame the question around their problem, not PostHog products: "What's the main problem you're trying to solve?" is better than "Which PostHog product are you interested in?"
Multiple Use Cases
Many leads map to more than one use case. When this happens:
- Lead with the primary use case — the one most closely matching their stated pain
- Mention the secondary use case as a natural extension — "PostHog also handles X, which tends to come up once teams are doing Y"
- Don't try to sell the entire platform — focus on solving the problem they came in with
Step 3: Qualify the Lead
Growth Trajectory Override
The $20K annual spend threshold is the default qualification bar, but growth trajectory can override it.
When all of the following are true, qualify for a call even if current MAU alone wouldn't hit $20K:
- Growth trajectory is "Accelerating" — Recent large funding, aggressive hiring, early-stage with significant capital
- High-value company signals — At least two of: $10M+ in funding, 50+ employees, engineering-heavy team, multi-product, AI-native
- Reasonable path to $20K within 12 months — Based on growth trajectory and multi-product multiplier, it's plausible they'll reach the threshold as they scale
When the override applies, note it explicitly in the disposition: "Current MAU of 10K is below the $20K threshold, but growth trajectory is Accelerating ([$X funding, Y employees, etc.]) with multi-product potential. Qualifying for call based on trajectory."
When the override does NOT apply:
- Growth trajectory is Steady, Early/unknown, or Flat — stick to the $20K threshold based on current signals
- The company has funding but the lead's use case is narrow and unlikely to expand (e.g., a well-funded company asking about feature flags for one internal tool)
- The lead is from a large company but the team using PostHog would be tiny with no expansion path
Multi-Product Spend Multiplier
When multi-product signals are detected (from the lead's message or company research), adjust the MAU estimate:
- Stated MAU × estimated product count = adjusted MAU estimate
- Use the adjusted estimate for qualification, not the raw stated MAU
- Note the multiplier in the disposition: "10K MAU stated, but 'some of our products' + company research suggests 3-5 products → 30-50K adjusted MAU"
This multiplier is an estimate, not a guarantee. It shifts the disposition from "definitely below threshold" to "plausibly above threshold, worth a call to confirm."
Special Case: Competitor Displacement
When a lead mentions they're currently using a competitor and looking to switch (e.g., "using Heap looking to move", "replacing Amplitude", "evaluating alternatives to Sentry", "moving off LaunchDarkly"), this is a high-signal inbound. They already have budget allocated to a tool in the category, they have a defined need, and they likely have some urgency.
However, the $20K floor still applies (unless the growth trajectory override kicks in). A competitor displacement lead still needs to show potential for $20K+ annual spend to qualify for a call. Don't offer a call just because they're switching from a paid tool.
For competitor displacement leads, the initial response should surface BANT signals before offering a call or routing to self-serve. Ask targeted discovery questions that uncover:
- Budget: What's driving the switch? Cost, missing features, data ownership, or something else? (If cost, that implies existing budget.)
- Authority: Who's involved in the decision? Is this an engineering-led eval or a top-down mandate?
- Need: What are you hoping PostHog solves that [competitor] doesn't? Are you looking to replace just [product], or are you interested in consolidating with additional capabilities (replay, flags, experiments, etc.)?
- Timeline: How soon are you looking to make a decision? (Don't ask this in the first email — let it emerge naturally or ask in a follow-up.)
You don't need all four BANT signals in the first email. Ask 1–2 questions that surface the most important unknowns — typically Budget (why are you switching?) and Need (what do you want beyond what you have?). Let Authority and Timeline emerge in the reply.
After the lead replies with BANT context:
- If the answers confirm $20K+ potential and a real use case → Qualify for call, and offer your calendar
- If the answers reveal a small team / low spend / simple replacement → Route to self-serve with specific migration resources
- If the lead asks for a call before you have BANT context → It's OK to offer the calendar, but also point out that everything needed to evaluate PostHog is publicly available (pricing, docs, free signup), so they can start evaluating in parallel
Special Case: Vague Request from a High-Value Company
When the lead's message is vague (e.g., "want to start a review process", "looking to learn more", "interested in PostHog") BUT company research reveals a high-value account, do not default to self-serve routing.
Instead, treat vague requests from high-value companies as "needs discovery" rather than "not serious enough for a call." The disposition should be "qualify for call with discovery questions."
High-value company indicators (any two or more qualifies):
- $10M+ in total funding
- 100+ employees
- Engineering team >40% of headcount
- Multi-product signals
- AI-native company
- Growth trajectory classified as "Accelerating"
- Well-known brand or notable founders/leadership
The email for these leads should:
- Acknowledge their interest without making assumptions about the use case
- Ask 1-2 discovery questions to understand what they're trying to solve
- Mention 1-2 PostHog capabilities most relevant to their company type (informed by research)
- Offer a call to walk through how PostHog fits their stack
Disposition: Qualify for Call
All of these should be true:
- Annual spend potential ≥ $20K (based on current MAU, OR adjusted MAU with multi-product multiplier, OR growth trajectory override)
- Engineers are involved or will be on the call
- Specific, defined use case (mapped to at least one of the six above) — OR vague request from a high-value company (see special case above)
- Company size and product needs justify sales-assisted motion
If qualified, draft a response that:
- Acknowledges their specific use case (or, for vague requests from high-value companies, their company context and likely use cases)
- Asks 1–2 targeted discovery questions from the relevant use case playbook
- Offers to schedule a call
Disposition: Route to Self-Serve
Any of these are true:
- Spend potential clearly below $20K based on company size, research, AND growth trajectory does not justify the override
- Low volume explicitly stated (e.g., "1,000 MAU", "small team", "just getting started") AND company research confirms this is the ceiling (small company, flat trajectory)
- Vague request with no specific use case AND company research does not reveal a high-value account
- No engineer involvement mentioned or expected
- Generic "learn more" or "get a demo" with no substance behind it AND company research doesn't change the picture
Draft a helpful email that:
- Answers their question with use-case-specific resources
- Provides links to the most relevant product docs for their identified use case
- Directs them to self-serve channels (in-app support, community)
- Does NOT offer a call
Disposition: Route to Startup Plan
- Company is early-stage and potentially eligible for the startup plan
- Direct them to the startup plan application
- Disqualify as an immediate sales opportunity
Disposition: Disqualify
- Clearly not ICP (wrong industry vertical, no product-engineering use case)
- Spam or irrelevant inquiry
- No response needed, or a brief polite decline
Disqualification Reasons & Notes
When recommending any disposition other than "Qualify for Call," you MUST provide a disqualification reason (from the list below) and disqualification notes (250 characters or fewer, specific and copy-pasteable into the Salesforce disqualification notes field).
Available disqualification reasons:
- BAA / DPA Request
- Below Sales Assist Threshold - Pass
- Below Sales Assist Threshold - Prospect
- Billing Support Request
- Business Closed
- Duplicate Lead
- Event request
- Existing customer inquiry
- Feedback
- Invalid Contact Info
- No Budget
- No Current Need
- No Product Fit
- No Response - Pass
- No Response - Prospect
- No Technical Resource
- Non-Commercial
- Not a Good Fit
- Other
- Partnership request
- Resource Constraints
- Self-Hosted Requirement
- Spam
- Stale - autoclosed
- Startup Plan / YC
- Support Request
- Using Competitor / Unsolicited RFP
How to choose the right reason:
- Below Sales Assist Threshold - Pass: Below $20K potential, no growth trajectory override, and no realistic growth path to get there. Use for small companies routed to self-serve.
- Below Sales Assist Threshold - Prospect: Below $20K now but company shows signals it could grow into threshold (e.g. recent funding, growing team). Worth revisiting later. Use when the growth trajectory is promising but doesn't meet the override criteria yet.
- BAA / DPA Request: Lead requires a BAA or DPA. Note: BAAs are available starting at the Boost add-on ($250/month + usage-based pricing) for standard (no redlines) BAAs, or Enterprise ($2K/month paid annually) for custom/redlined BAAs. Use this reason when the lead's primary need is HIPAA/BAA and they've been given the relevant pricing info.
- No Technical Resource: The contact is non-technical and no engineer is mentioned or expected to be involved.
- Startup Plan / YC: Early-stage company routed to the startup plan application.
- Support Request: They're asking a support question, not evaluating PostHog for purchase.
- Existing customer inquiry: Already a PostHog customer with a product/billing question - not a new sales opportunity.
- No Product Fit: What they need isn't something PostHog does well (e.g. self-hosted requirement, industry mismatch).
Disqualification notes must be specific and copy-pasteable. Include the key data points that justify the disqualification, including relevant findings from company research.
Good DQ notes:
- "30-employee e-commerce agency, $1M-$10M revenue. Marketing role, no engineer. 250K MAUs on free tier. Feature flag question answered, routed to self-serve."
- "Bay Area nonprofit, 20K MAUs, ICP -5. Sr Dir Product, strong use case but well below $20K threshold. BAA available via Boost ($250/mo). Routed to self-serve with HIPAA + funnel guidance."
- "15-person seed startup. Developer asking about feature flags. Free tier covers their needs. Pointed to docs + in-app support."
- "5-person pre-revenue startup, no funding found. 2K MAU. Vague 'want to learn more.' Routed to self-serve, suggested startup plan application."
Bad DQ notes:
- "Not a good fit" (too vague)
- "Small company" (which signal matters?)
- "Routed to self-serve" (why?)
- "Low MAU" (did you check if the company is actually small, or is the product just early?)
Step 4: Write the Response Email
Read references/writing-style.md before drafting. Key rules:
- Get to the point. No long intros, no fluff, no corporate jargon.
- Be helpful, not sales-y. Solve their problem with specific guidance.
- Be opinionated. Don't hedge with "it depends" — recommend a path.
- Frame around their use case, not PostHog products. Talk about solving their problem, not about product names.
- Use company research to personalize. If you know what they build, reference it. "Since you're building AI tools for manufacturing" is better than "Since you're evaluating analytics."
- Embed links in anchor text. Never paste bare URLs or use "click here."
- Minimal formatting. Use bullet points only when listing resources or steps. Keep it conversational.
- One question max per email to avoid overwhelming the recipient.
Email Structure
- Brief, friendly greeting
- Acknowledge their specific situation and use case (informed by company research)
- Provide the answer, guidance, or resources mapped to their use case
- Clear next step (self-serve action, schedule link, or "reply if you have questions")
- Simple sign-off
Step 5: Validate All URLs
This step is mandatory. Before presenting the draft email, fetch every URL included in the email using web_fetch to verify:
- The URL resolves — It returns a 200 status, not a 404 or redirect to a generic page
- The content matches the intent — The page actually covers what you're linking it for (e.g., a link labeled "Feature Flags getting started" should land on the Feature Flags getting started page, not a generic docs index)
If a URL fails validation:
- Search posthog.com for the correct page using
web_search (e.g., "posthog docs feature flags getting started")
- Replace the broken link with the correct one
- If no valid page exists for that resource, remove the link rather than send a broken one
Why this matters: PostHog's docs structure changes. URLs from the resource list below are a starting point, but they may have moved. A broken link in a sales email undermines credibility. Always verify before sending.
Use-Case-Specific Resources to Link
Product Intelligence
Release Engineering
Observability
Growth & Marketing
AI/LLM Observability
Data Infrastructure
General (all use cases)
BAA / HIPAA Pricing Reference
When a lead mentions HIPAA, BAA, or healthcare data, use this pricing info:
Standard BAA (no redlines):
- Available on the Boost add-on at $250/month + usage-based pricing
- Also available on Scale and Enterprise add-ons
- The BAA can be generated at posthog.com/baa for PostHog to countersign
Custom/redlined BAA:
- Requires the Enterprise plan at $2K/month (paid annually) + usage-based pricing
- Only needed if the customer wants to modify the standard BAA terms
Key framing: Lead with Boost as the standard path. $250/month is accessible for most organizations, including nonprofits and smaller companies. Don't default to "enterprise pricing" - that scares off leads who could easily afford Boost.
Practical note for leads with mixed PHI/non-PHI data: If only some of their funnels or data flows touch PHI, they can start tracking non-PHI activity on the free tier immediately while sorting out the BAA for the PHI-touching portions.
Non-Profit Discount Reference
PostHog offers non-profit discounts on credit purchases:
- Credit purchases below $25K: 15% discount
- Credit purchases $25K-$100K: additional 5% on top of standard volume discount
- Credit purchases above $100K: standard volume discounts apply (no additional non-profit discount)
To qualify, the customer needs to provide proof they fit their country's definition of a non-profit entity (tax law in country of origin).
Note: At low MAU volumes where usage stays within the free tier, the non-profit discount won't matter yet - their main cost would be the platform add-on (e.g. Boost for BAA). Mention the discount so they know it exists for when they grow into it.
Output Format
When responding to the TAE, always provide:
- Vitally findings — Whether the lead or their company was found in Vitally, and what that means
- Company research — Brief profile from web research: what they do, funding, headcount, growth trajectory, multi-product signals, AI-native flag
- Use case assessment — Which of the six use cases this lead maps to, and why (based on persona, company research, and message)
- Disposition recommendation — Qualify / Self-serve / Startup plan / Disqualify
- Disqualification reason — From the available list (required for all dispositions except Qualify for Call)
- Disqualification notes — 250 characters or fewer, specific and copy-pasteable (required for all dispositions except Qualify for Call)
- Draft email — The response to send, framed around the identified use case and informed by company research
Reference Files
Read these before drafting responses:
references/email-examples.md — Example emails for common inbound scenarios
references/sales-context.md — Sales process, thresholds, qualification criteria
references/writing-style.md — PostHog tone, formatting, and style rules
Critical Reminders
- Always check Vitally first — Search for the lead's email and email domain before doing anything else. An existing customer changes everything about the response.
- Always research the company — Never qualify or disqualify based solely on stated MAU and the lead's message. A 5-minute web search can turn a "pass" into a whale.
- Growth trajectory can override the $20K threshold — An accelerating company with strong signals should be qualified even if current MAU is low. Document the override reasoning.
- Multi-product signals are spend multipliers — "Some of our products" means the stated MAU is a floor, not a ceiling. Adjust your estimate.
- AI-native companies get AI/LLM Obs as a secondary use case — Even if they didn't mention it. It's almost always relevant.
- Vague requests from high-value companies need discovery, not self-serve — Don't punt a $6B startup to the docs because they didn't write a detailed form submission.
- $20K threshold is firm for non-override cases — Do not offer calls below this for companies with steady/flat trajectories and no high-value signals.
- Always identify the use case — This is the foundation for everything: the disposition, the framing, and the resources you link.
- Always recommend a disposition — Don't just write an email; state the qualification decision explicitly so the TAE can update Salesforce.
- Always mention in-app support for product questions — it's the fastest path to help.
- PostHog is built for product engineers — If no engineer is involved, that's a red flag for qualification.
- Frame around problems, not products — "Here's how to understand why users drop off" not "Here's our Product Analytics feature."
- Use company research to personalize the email — Reference what they build, not just what they asked. It shows you did your homework.
- Match specificity to specificity — Vague inbound gets pointed to resources with a clarifying question; specific technical questions get specific answers tied to their use case.
- Always validate URLs before presenting the draft — Fetch every link to confirm it resolves and points to the right content. Never send a broken link.
- Always provide a DQ reason and DQ notes — For every disposition except Qualify for Call, include the disqualification reason from the available list and copy-pasteable notes (250 chars or fewer). Be specific — name concrete signals from both the lead's message AND your company research.
1---2name: posthog-inbound-leads3description: Evaluate and respond to inbound PostHog sales leads from Salesforce. Use this skill when any PostHog TAE needs to triage an inbound lead — deciding whether to qualify for a call, route to self-serve, or disqualify — and then draft an appropriate response email. Checks Vitally for existing account context before qualifying. Triggers on "respond to this lead", "triage this inbound", "write a response to this lead", "disposition this lead", "evaluate this Salesforce lead", or any request involving an inbound sales inquiry that needs qualification and a reply. Also trigger when a TAE pastes or describes lead details and asks what to do with them.4---5
6# PostHog Inbound Lead Disposition
7
8Evaluate inbound leads from Salesforce and either draft a response email or recommend a disposition. This skill is for any PostHog TAE handling inbound sales inquiries.
9
10## Core Workflow
11
121. **Ingest lead context** — Read whatever the TAE provides (Salesforce fields, email body, notes)
132. **Check Vitally for existing account context** — Search for the lead's email and email domain (see Step 0 below)
143. **Research the company** — Web search to understand who they are, their funding, size, and growth trajectory (see Step 1 below)
154. **Identify the use case** — Map the lead to one or more of PostHog's six use cases, informed by company research (see Step 2 below)
165. **Qualify the lead** — Apply the disposition framework, informed by company research and growth trajectory (see Step 3 below)
176. **Recommend a disposition** — State the recommended action and identified use case(s) clearly
187. **Draft a response** — Write the appropriate email, framed around their use case (see Step 4 below)
198. **Validate all URLs** — Fetch every link in the draft email to confirm it resolves and points to the intended content (see Step 5 below)
20
21## Step 0: Check Vitally for Existing Account Context
22
23Before qualifying or drafting anything, check Vitally to see if this lead (or their company) is already a PostHog user. This changes the disposition and email framing significantly — an existing customer asking for help is different from a cold inbound.
24
25### What to check
26
27Run two Vitally lookups using the lead's email address:
28
291. **Search by exact email** — `vitally:search_users` with `email` set to the lead's email address. This tells you if this specific person already has a PostHog account.
302. **Search by email domain** — `vitally:search_users` with `emailSubdomain` set to the domain portion of the lead's email (e.g., `acme.com` from `jane@acme.com`). This tells you if anyone at their company is already using PostHog.
31
32If either search returns results, pull up the associated account with `vitally:get_account_full` using the `accountId` from the user record(s). Use `detailLevel: "summary"` for a quick overview.
33
34### How to use what you find
35
36**Lead's email is an existing user:**
37- They're already in PostHog. The email should acknowledge this ("I can see you're already using PostHog") and focus on their specific ask rather than onboarding-style resources.
38- Check their account's MRR and health score — this informs whether they're a self-serve user reaching out to grow, or an existing account with an expansion opportunity.
39
40**Different person at the same company is already a user:**
41- Their company is already on PostHog. Reference this in the email ("I see your team is already using PostHog") and ask how their request relates to the existing usage.
42- Check who else is on the account — the lead may need to connect with the internal champion rather than start a separate evaluation.
43- If the account already has a TAE assigned, flag this to avoid stepping on someone's book of business.
44
45**No results in Vitally:**
46- Net new lead. Proceed with the standard qualification workflow below.
47
48### What to surface to the TAE
49
50When presenting the Vitally findings, include:
51- Whether the person or company was found
52- Account name and current MRR (if applicable)
53- Health score (if applicable)
54- Assigned TAE (if any — important for routing)
55- Number of users on the account
56- A one-line recommendation on how this changes the response (e.g., "Existing $3K/mo account, no TAE assigned — this is an expansion opportunity, not a new lead")
57
58## Step 1: Research the Company
59
60**This step is mandatory for every lead.** The lead's form submission alone is not enough information to qualify or disqualify. A 10K MAU lead from a $6B startup and a 10K MAU lead from a 5-person agency require completely different dispositions.
61
62### What to research
63
64Run 1-3 web searches to understand the company. Start with the company name and domain:
65
66- `web_search` for `[Company Name] [domain]` — Get the basics: what they do, who they are
67- `web_search` for `[Company Name] funding employees` — Get firmographics: funding stage, headcount, growth signals
68- If the company appears to be notable or well-funded, search for recent news: `[Company Name] 2026` or `[Company Name] news`
69
70### What to extract
71
72From the research, identify and record:
73
74| Signal | Why It Matters | Example |
75|---|---|---|
76| **What they build** | Determines use case mapping and whether they're ICP | "AI tools for manufacturing" → AI/LLM Obs is relevant |
77| **Funding stage and amount** | Proxy for budget and growth trajectory | Series B, $50M → likely has budget for tooling |
78| **Employee count** | Proxy for spend potential and team complexity | 200 employees → multiple teams, multi-project potential |
79| **Engineering team size or ratio** | PostHog's buyer is engineers; more engineers = better fit | "80% of team is engineering" → strong ICP signal |
80| **Growth trajectory** | Determines whether current MAU is the ceiling or the floor | Founded 6 months ago, hiring aggressively → MAU will grow fast |
81| **Recent news** | Acquisitions, launches, pivots that change context | Just acquired an AI startup → expanding product surface |
82| **Business model** | SaaS, marketplace, dev tools, agency, etc. | B2B SaaS → classic PostHog ICP |
83
84### Classify the growth trajectory
85
86Based on the research, classify the company into one of four growth trajectories:
87
88- **Accelerating**: Recent large funding round (especially if raised in last 12 months), aggressive hiring, early-stage with significant capital, or clear signs of rapid expansion. Current MAU is almost certainly not the ceiling. Examples: well-funded Series A+ startups, companies that just raised mega-rounds, companies with "hundreds of open roles."
89- **Steady**: Established company, moderate and predictable growth. Current MAU is a reasonable proxy for near-term spend. Examples: mid-market SaaS with stable revenue, mature PLG companies.
90- **Early/unknown**: New company, limited public information, hard to assess trajectory. Treat current MAU as the best available signal but note the uncertainty. Examples: pre-seed startups, stealth-mode companies with no public footprint.
91- **Flat/declining**: No growth signals, layoffs, or signs of contraction. Current MAU may overstate future spend. Examples: companies with recent layoffs, shrinking teams.
92
93**The growth trajectory classification directly affects qualification.** See Step 3 for how it modifies the $20K threshold.
94
95### Detect multi-product signals
96
97While researching, watch for signals that the lead's company has (or is building) multiple products. This is a spend multiplier because each product typically becomes a separate PostHog project with its own event volume.
98
99**Signals in the lead's message:**
100- "some of our products" / "multiple products" / "across our portfolio"
101- "several teams" / "multiple teams" / "different business units"
102- "our platform and our apps" / "our web app and mobile app"
103- "integrate into our stack" (implies breadth)
104
105**Signals from company research:**
106- Company has multiple product lines or brands
107- Company recently acquired other companies (each acquisition may have its own product)
108- Job postings reference multiple product teams
109- Company website shows multiple distinct products
110
111When multi-product signals are present, note the estimated product count (or range) and factor it into the MAU multiplier. A company with 5 products at 10K MAU each is a 50K MAU opportunity, not a 10K one.
112
113### Detect AI/ML company signals
114
115If company research reveals the company is AI-native (building AI/ML products as their core business), flag AI/LLM Observability as a probable secondary use case even if the lead's message doesn't mention AI, LLMs, model costs, or prompts.
116
117**AI-native signals:**
118- Company description mentions AI, ML, LLM, or "artificial intelligence" as core to what they build
119- Company is in an AI-adjacent industry (AI infrastructure, AI applications, AI research)
120- Team is heavily ML/AI engineers
121- Recent AI-related acquisitions or product launches
122
123When detected, include AI/LLM Observability in the use case assessment and mention it in the email as a relevant capability, even if the lead didn't ask about it. Frame it as: "since you're building AI products, you might also find our LLM analytics useful for tracking model costs and performance."
124
125### What to surface to the TAE
126
127Present the company research as a brief profile including:
128- What the company does (one sentence)
129- Funding and valuation (if available)
130- Employee count and engineering composition (if available)
131- Growth trajectory classification
132- Multi-product signals (if any)
133- AI-native flag (if applicable)
134- Any notable context (recent news, acquisitions, leadership)
135
136This goes right after the Vitally findings and before the use case assessment.
137
138## Step 2: Identify the Use Case
139
140Every lead maps to one or more of PostHog's six use cases. Identifying the use case determines how to frame the response, what products to highlight, and what resources to link. Evaluate the **person/persona**, **company** (informed by your Step 1 research), and **message** to determine the match.
141
142### The Six Use Cases
143
144| Use Case | Job to Be Done | Core Buyer Persona | Key Signals in the Lead |
145|---|---|---|---|
146| **Product Intelligence** | "Help me understand what users do, why they do it, and what to build next." | PMs, designers, product engineers, founders | Mentions analytics, funnels, retention, user behavior, "why users drop off", feature adoption, NPS, surveys, session replay for UX research |
147| **Release Engineering** | "Help me ship faster without breaking things." | Engineering managers, platform teams, developers | Mentions feature flags, rollouts, A/B testing releases, kill switches, progressive delivery, replacing LaunchDarkly |
148| **Observability** | "Help me know when things break, understand why, and fix them fast." | SREs, platform engineers, DevOps | Mentions error tracking, bug reproduction, replacing Sentry/Datadog, logging, incident response, stack traces |
149| **Growth & Marketing** | "Help me understand what drives acquisition, conversion, and revenue." | Growth engineers, marketing leads, CRO, GTM engineers | Mentions attribution, ROAS, campaign performance, replacing GA4/Segment, conversion optimization, onboarding automation, marketing stack consolidation |
150| **AI/LLM Observability** | "Help me understand how my AI features perform, what they cost, and how users interact with them." | AI/ML engineers, AI PMs, AI founders | Mentions LLM, AI features, model costs, prompt testing, AI quality, replacing Langfuse/Helicone, token usage. **Also inferred from company research** — if the company is AI-native, this use case is relevant even if the lead didn't mention it. |
151| **Data Infrastructure** | "Help me unify product data with business data and get it where it needs to go." | Data engineers, analytics engineers, product ops | Mentions data warehouse, Snowflake/BigQuery, data pipelines, batch exports, combining PostHog data with Stripe/CRM, replacing Segment/Fivetran |
152
153### Mapping Persona to Use Case
154
155The **person's role** is one of the strongest signals:
156
157- **PM, Head of Product, UX Researcher, Designer** → Product Intelligence
158- **Engineering Manager, VP Eng, Platform Engineer, Developer** → Release Engineering (or Observability if they mention errors/incidents)
159- **SRE, DevOps, Infrastructure Engineer** → Observability
160- **Growth Engineer, Marketing Lead, CRO, GTM Engineer, Demand Gen** → Growth & Marketing
161- **AI/ML Engineer, AI PM, AI Founder** → AI/LLM Observability
162- **Data Engineer, Analytics Engineer, Head of Data, RevOps** → Data Infrastructure
163- **Founder/CTO (early stage)** → Usually Product Intelligence or AI/LLM Obs depending on the product; may span multiple use cases
164
165### Mapping Company to Use Case
166
167The **company type** (from your Step 1 research) helps narrow it:
168
169- **AI-native startup** → AI/LLM Observability is almost always relevant, often alongside Product Intelligence
170- **PLG SaaS** → Product Intelligence + Growth & Marketing are the most common pair
171- **Enterprise with multiple teams** → Often starts as one use case but the expansion potential spans several
172- **E-commerce / marketplace** → Growth & Marketing (conversion, attribution) + Product Intelligence (user behavior)
173- **Developer tools / infrastructure** → Release Engineering + Observability
174
175### Mapping Message to Use Case
176
177The **specific ask** confirms or overrides the persona/company signal:
178
179- "We want to understand user behavior" → Product Intelligence
180- "We need feature flags" or "replacing LaunchDarkly" → Release Engineering
181- "We need error tracking" or "replacing Sentry" → Observability
182- "We want attribution" or "replacing GA4" → Growth & Marketing
183- "We're building AI features" or "LLM costs" → AI/LLM Observability
184- "We need to get data into Snowflake" → Data Infrastructure
185- Vague "show me features" / "want a demo" → Can't determine use case from the message alone; **use company research to infer the most likely use case(s)**, then ask a targeted clarifying question to confirm
186
187**If the use case is ambiguous even after company research**, include a targeted clarifying question in the email to narrow it down. Frame the question around their problem, not PostHog products: "What's the main problem you're trying to solve?" is better than "Which PostHog product are you interested in?"
188
189### Multiple Use Cases
190
191Many leads map to more than one use case. When this happens:
192
193- **Lead with the primary use case** — the one most closely matching their stated pain
194- **Mention the secondary use case as a natural extension** — "PostHog also handles X, which tends to come up once teams are doing Y"
195- **Don't try to sell the entire platform** — focus on solving the problem they came in with
196
197## Step 3: Qualify the Lead
198
199### Growth Trajectory Override
200
201**The $20K annual spend threshold is the default qualification bar, but growth trajectory can override it.**
202
203When all of the following are true, qualify for a call even if current MAU alone wouldn't hit $20K:
204
2051. **Growth trajectory is "Accelerating"** — Recent large funding, aggressive hiring, early-stage with significant capital
2062. **High-value company signals** — At least two of: $10M+ in funding, 50+ employees, engineering-heavy team, multi-product, AI-native
2073. **Reasonable path to $20K within 12 months** — Based on growth trajectory and multi-product multiplier, it's plausible they'll reach the threshold as they scale
208
209When the override applies, note it explicitly in the disposition: "Current MAU of 10K is below the $20K threshold, but growth trajectory is Accelerating ([$X funding, Y employees, etc.]) with multi-product potential. Qualifying for call based on trajectory."
210
211**When the override does NOT apply:**
212- Growth trajectory is Steady, Early/unknown, or Flat — stick to the $20K threshold based on current signals
213- The company has funding but the lead's use case is narrow and unlikely to expand (e.g., a well-funded company asking about feature flags for one internal tool)
214- The lead is from a large company but the team using PostHog would be tiny with no expansion path
215
216### Multi-Product Spend Multiplier
217
218When multi-product signals are detected (from the lead's message or company research), adjust the MAU estimate:
219
220- **Stated MAU × estimated product count = adjusted MAU estimate**
221- Use the adjusted estimate for qualification, not the raw stated MAU
222- Note the multiplier in the disposition: "10K MAU stated, but 'some of our products' + company research suggests 3-5 products → 30-50K adjusted MAU"
223
224This multiplier is an estimate, not a guarantee. It shifts the disposition from "definitely below threshold" to "plausibly above threshold, worth a call to confirm."
225
226### Special Case: Competitor Displacement
227
228When a lead mentions they're currently using a competitor and looking to switch (e.g., "using Heap looking to move", "replacing Amplitude", "evaluating alternatives to Sentry", "moving off LaunchDarkly"), this is a high-signal inbound. They already have budget allocated to a tool in the category, they have a defined need, and they likely have some urgency.
229
230**However, the $20K floor still applies (unless the growth trajectory override kicks in).** A competitor displacement lead still needs to show potential for $20K+ annual spend to qualify for a call. Don't offer a call just because they're switching from a paid tool.
231
232**For competitor displacement leads, the initial response should surface BANT signals** before offering a call or routing to self-serve. Ask targeted discovery questions that uncover:
233
234- **Budget:** What's driving the switch? Cost, missing features, data ownership, or something else? (If cost, that implies existing budget.)
235- **Authority:** Who's involved in the decision? Is this an engineering-led eval or a top-down mandate?
236- **Need:** What are you hoping PostHog solves that [competitor] doesn't? Are you looking to replace just [product], or are you interested in consolidating with additional capabilities (replay, flags, experiments, etc.)?
237- **Timeline:** How soon are you looking to make a decision? (Don't ask this in the first email — let it emerge naturally or ask in a follow-up.)
238
239**You don't need all four BANT signals in the first email.** Ask 1–2 questions that surface the most important unknowns — typically Budget (why are you switching?) and Need (what do you want beyond what you have?). Let Authority and Timeline emerge in the reply.
240
241**After the lead replies with BANT context:**
242- If the answers confirm $20K+ potential and a real use case → Qualify for call, and offer your calendar
243- If the answers reveal a small team / low spend / simple replacement → Route to self-serve with specific migration resources
244- If the lead asks for a call before you have BANT context → It's OK to offer the calendar, but also point out that everything needed to evaluate PostHog is publicly available (pricing, docs, free signup), so they can start evaluating in parallel
245
246### Special Case: Vague Request from a High-Value Company
247
248When the lead's message is vague (e.g., "want to start a review process", "looking to learn more", "interested in PostHog") BUT company research reveals a high-value account, **do not default to self-serve routing.**
249
250Instead, treat vague requests from high-value companies as "needs discovery" rather than "not serious enough for a call." The disposition should be "qualify for call with discovery questions."
251
252**High-value company indicators** (any two or more qualifies):
253- $10M+ in total funding
254- 100+ employees
255- Engineering team >40% of headcount
256- Multi-product signals
257- AI-native company
258- Growth trajectory classified as "Accelerating"
259- Well-known brand or notable founders/leadership
260
261The email for these leads should:
262- Acknowledge their interest without making assumptions about the use case
263- Ask 1-2 discovery questions to understand what they're trying to solve
264- Mention 1-2 PostHog capabilities most relevant to their company type (informed by research)
265- Offer a call to walk through how PostHog fits their stack
266
267### Disposition: Qualify for Call
268
269All of these should be true:
270- Annual spend potential ≥ $20K (based on current MAU, OR adjusted MAU with multi-product multiplier, OR growth trajectory override)
271- Engineers are involved or will be on the call
272- Specific, defined use case (mapped to at least one of the six above) — OR vague request from a high-value company (see special case above)
273- Company size and product needs justify sales-assisted motion
274
275If qualified, draft a response that:
276- Acknowledges their specific use case (or, for vague requests from high-value companies, their company context and likely use cases)
277- Asks 1–2 targeted discovery questions from the relevant use case playbook
278- Offers to schedule a call
279
280### Disposition: Route to Self-Serve
281
282Any of these are true:
283- Spend potential clearly below $20K based on company size, research, AND growth trajectory does not justify the override
284- Low volume explicitly stated (e.g., "1,000 MAU", "small team", "just getting started") AND company research confirms this is the ceiling (small company, flat trajectory)
285- Vague request with no specific use case AND company research does not reveal a high-value account
286- No engineer involvement mentioned or expected
287- Generic "learn more" or "get a demo" with no substance behind it AND company research doesn't change the picture
288
289Draft a helpful email that:
290- Answers their question with use-case-specific resources
291- Provides links to the most relevant product docs for their identified use case
292- Directs them to self-serve channels (in-app support, community)
293- Does NOT offer a call
294
295### Disposition: Route to Startup Plan
296
297- Company is early-stage and potentially eligible for the startup plan
298- Direct them to the [startup plan application](https://posthog.com/startups)
299- Disqualify as an immediate sales opportunity
300
301### Disposition: Disqualify
302
303- Clearly not ICP (wrong industry vertical, no product-engineering use case)
304- Spam or irrelevant inquiry
305- No response needed, or a brief polite decline
306
307### Disqualification Reasons & Notes
308
309When recommending any disposition other than "Qualify for Call," you MUST provide a **disqualification reason** (from the list below) and **disqualification notes** (250 characters or fewer, specific and copy-pasteable into the Salesforce disqualification notes field).
310
311**Available disqualification reasons:**
312
313- BAA / DPA Request
314- Below Sales Assist Threshold - Pass
315- Below Sales Assist Threshold - Prospect
316- Billing Support Request
317- Business Closed
318- Duplicate Lead
319- Event request
320- Existing customer inquiry
321- Feedback
322- Invalid Contact Info
323- No Budget
324- No Current Need
325- No Product Fit
326- No Response - Pass
327- No Response - Prospect
328- No Technical Resource
329- Non-Commercial
330- Not a Good Fit
331- Other
332- Partnership request
333- Resource Constraints
334- Self-Hosted Requirement
335- Spam
336- Stale - autoclosed
337- Startup Plan / YC
338- Support Request
339- Using Competitor / Unsolicited RFP
340
341**How to choose the right reason:**
342
343- **Below Sales Assist Threshold - Pass**: Below $20K potential, no growth trajectory override, and no realistic growth path to get there. Use for small companies routed to self-serve.
344- **Below Sales Assist Threshold - Prospect**: Below $20K now but company shows signals it could grow into threshold (e.g. recent funding, growing team). Worth revisiting later. Use when the growth trajectory is promising but doesn't meet the override criteria yet.
345- **BAA / DPA Request**: Lead requires a BAA or DPA. Note: BAAs are available starting at the Boost add-on ($250/month + usage-based pricing) for standard (no redlines) BAAs, or Enterprise ($2K/month paid annually) for custom/redlined BAAs. Use this reason when the lead's primary need is HIPAA/BAA and they've been given the relevant pricing info.
346- **No Technical Resource**: The contact is non-technical and no engineer is mentioned or expected to be involved.
347- **Startup Plan / YC**: Early-stage company routed to the startup plan application.
348- **Support Request**: They're asking a support question, not evaluating PostHog for purchase.
349- **Existing customer inquiry**: Already a PostHog customer with a product/billing question - not a new sales opportunity.
350- **No Product Fit**: What they need isn't something PostHog does well (e.g. self-hosted requirement, industry mismatch).
351
352**Disqualification notes must be specific and copy-pasteable.** Include the key data points that justify the disqualification, including relevant findings from company research.
353
354Good DQ notes:
355- "30-employee e-commerce agency, $1M-$10M revenue. Marketing role, no engineer. 250K MAUs on free tier. Feature flag question answered, routed to self-serve."
356- "Bay Area nonprofit, 20K MAUs, ICP -5. Sr Dir Product, strong use case but well below $20K threshold. BAA available via Boost ($250/mo). Routed to self-serve with HIPAA + funnel guidance."
357- "15-person seed startup. Developer asking about feature flags. Free tier covers their needs. Pointed to docs + in-app support."
358- "5-person pre-revenue startup, no funding found. 2K MAU. Vague 'want to learn more.' Routed to self-serve, suggested startup plan application."
359
360Bad DQ notes:
361- "Not a good fit" (too vague)
362- "Small company" (which signal matters?)
363- "Routed to self-serve" (why?)
364- "Low MAU" (did you check if the company is actually small, or is the product just early?)
365
366## Step 4: Write the Response Email
367
368Read `references/writing-style.md` before drafting. Key rules:
369
370- **Get to the point.** No long intros, no fluff, no corporate jargon.
371- **Be helpful, not sales-y.** Solve their problem with specific guidance.
372- **Be opinionated.** Don't hedge with "it depends" — recommend a path.
373- **Frame around their use case, not PostHog products.** Talk about solving their problem, not about product names.
374- **Use company research to personalize.** If you know what they build, reference it. "Since you're building AI tools for manufacturing" is better than "Since you're evaluating analytics."
375- **Embed links in anchor text.** Never paste bare URLs or use "click here."
376- **Minimal formatting.** Use bullet points only when listing resources or steps. Keep it conversational.
377- **One question max** per email to avoid overwhelming the recipient.
378
379### Email Structure
380
3811. Brief, friendly greeting
3822. Acknowledge their specific situation and use case (informed by company research)
3833. Provide the answer, guidance, or resources mapped to their use case
3844. Clear next step (self-serve action, schedule link, or "reply if you have questions")
3855. Simple sign-off
386
387## Step 5: Validate All URLs
388
389**This step is mandatory.** Before presenting the draft email, fetch every URL included in the email using `web_fetch` to verify:
390
3911. **The URL resolves** — It returns a 200 status, not a 404 or redirect to a generic page
3922. **The content matches the intent** — The page actually covers what you're linking it for (e.g., a link labeled "Feature Flags getting started" should land on the Feature Flags getting started page, not a generic docs index)
393
394**If a URL fails validation:**
395- Search posthog.com for the correct page using `web_search` (e.g., "posthog docs feature flags getting started")
396- Replace the broken link with the correct one
397- If no valid page exists for that resource, remove the link rather than send a broken one
398
399**Why this matters:** PostHog's docs structure changes. URLs from the resource list below are a starting point, but they may have moved. A broken link in a sales email undermines credibility. Always verify before sending.
400
401## Use-Case-Specific Resources to Link
402
403### Product Intelligence
404- [Product analytics docs](https://posthog.com/docs/product-analytics)
405- [Funnels](https://posthog.com/docs/product-analytics/funnels)
406- [Session Replay](https://posthog.com/docs/session-replay)
407- [Surveys](https://posthog.com/docs/surveys/creating-surveys)
408- [Experiments](https://posthog.com/docs/experiments)
409
410### Release Engineering
411- [Feature Flags getting started](https://posthog.com/docs/feature-flags/start-here)
412- [Experiments](https://posthog.com/docs/experiments)
413- [Session Replay](https://posthog.com/docs/session-replay) (for debugging rollouts)
414
415### Observability
416- [Error Tracking](https://posthog.com/docs/error-tracking)
417- [Session Replay](https://posthog.com/docs/session-replay) (for error context)
418
419### Growth & Marketing
420- [Web Analytics](https://posthog.com/docs/web-analytics/getting-started)
421- [Marketing Analytics](https://posthog.com/docs/web-analytics/marketing-analytics)
422- [Data Pipelines](https://posthog.com/docs/cdp)
423- [Workflows](https://posthog.com/docs/workflows/start-here)
424
425### AI/LLM Observability
426- [AI Engineering / LLM Observability](https://posthog.com/docs/ai-engineering)
427- [Experiments](https://posthog.com/docs/experiments) (for prompt/model testing)
428
429### Data Infrastructure
430- [Data Warehouse](https://posthog.com/docs/data-warehouse)
431- [Batch Exports](https://posthog.com/docs/cdp/batch-exports)
432- [Realtime Destinations](https://posthog.com/docs/cdp/destinations)
433
434### General (all use cases)
435- [Installation guide](https://posthog.com/docs/getting-started/install)
436- [Pricing page](https://posthog.com/pricing)
437- [Community questions](https://posthog.com/questions)
438- [HIPAA compliance guide](https://posthog.com/docs/privacy/hipaa-compliance)
439- [BAA generator](https://posthog.com/baa)
440- In-app support button (always mention for product questions)
441- Free tier: 1M events/month, all core features included
442
443## BAA / HIPAA Pricing Reference
444
445When a lead mentions HIPAA, BAA, or healthcare data, use this pricing info:
446
447**Standard BAA (no redlines):**
448- Available on the **Boost add-on** at **$250/month** + usage-based pricing
449- Also available on Scale and Enterprise add-ons
450- The BAA can be generated at posthog.com/baa for PostHog to countersign
451
452**Custom/redlined BAA:**
453- Requires the **Enterprise plan** at **$2K/month** (paid annually) + usage-based pricing
454- Only needed if the customer wants to modify the standard BAA terms
455
456**Key framing:** Lead with Boost as the standard path. $250/month is accessible for most organizations, including nonprofits and smaller companies. Don't default to "enterprise pricing" - that scares off leads who could easily afford Boost.
457
458**Practical note for leads with mixed PHI/non-PHI data:** If only some of their funnels or data flows touch PHI, they can start tracking non-PHI activity on the free tier immediately while sorting out the BAA for the PHI-touching portions.
459
460## Non-Profit Discount Reference
461
462PostHog offers non-profit discounts on credit purchases:
463
464- **Credit purchases below $25K:** 15% discount
465- **Credit purchases $25K-$100K:** additional 5% on top of standard volume discount
466- **Credit purchases above $100K:** standard volume discounts apply (no additional non-profit discount)
467
468To qualify, the customer needs to provide proof they fit their country's definition of a non-profit entity (tax law in country of origin).
469
470**Note:** At low MAU volumes where usage stays within the free tier, the non-profit discount won't matter yet - their main cost would be the platform add-on (e.g. Boost for BAA). Mention the discount so they know it exists for when they grow into it.
471
472## Output Format
473
474When responding to the TAE, always provide:
475
4761. **Vitally findings** — Whether the lead or their company was found in Vitally, and what that means
4772. **Company research** — Brief profile from web research: what they do, funding, headcount, growth trajectory, multi-product signals, AI-native flag
4783. **Use case assessment** — Which of the six use cases this lead maps to, and why (based on persona, company research, and message)
4794. **Disposition recommendation** — Qualify / Self-serve / Startup plan / Disqualify
4805. **Disqualification reason** — From the available list (required for all dispositions except Qualify for Call)
4816. **Disqualification notes** — 250 characters or fewer, specific and copy-pasteable (required for all dispositions except Qualify for Call)
4827. **Draft email** — The response to send, framed around the identified use case and informed by company research
483
484## Reference Files
485
486Read these before drafting responses:
487- `references/email-examples.md` — Example emails for common inbound scenarios
488- `references/sales-context.md` — Sales process, thresholds, qualification criteria
489- `references/writing-style.md` — PostHog tone, formatting, and style rules
490
491## Critical Reminders
492
4931. **Always check Vitally first** — Search for the lead's email and email domain before doing anything else. An existing customer changes everything about the response.
4942. **Always research the company** — Never qualify or disqualify based solely on stated MAU and the lead's message. A 5-minute web search can turn a "pass" into a whale.
4953. **Growth trajectory can override the $20K threshold** — An accelerating company with strong signals should be qualified even if current MAU is low. Document the override reasoning.
4964. **Multi-product signals are spend multipliers** — "Some of our products" means the stated MAU is a floor, not a ceiling. Adjust your estimate.
4975. **AI-native companies get AI/LLM Obs as a secondary use case** — Even if they didn't mention it. It's almost always relevant.
4986. **Vague requests from high-value companies need discovery, not self-serve** — Don't punt a $6B startup to the docs because they didn't write a detailed form submission.
4997. **$20K threshold is firm for non-override cases** — Do not offer calls below this for companies with steady/flat trajectories and no high-value signals.
5008. **Always identify the use case** — This is the foundation for everything: the disposition, the framing, and the resources you link.
5019. **Always recommend a disposition** — Don't just write an email; state the qualification decision explicitly so the TAE can update Salesforce.
50210. **Always mention in-app support** for product questions — it's the fastest path to help.
50311. **PostHog is built for product engineers** — If no engineer is involved, that's a red flag for qualification.
50412. **Frame around problems, not products** — "Here's how to understand why users drop off" not "Here's our Product Analytics feature."
50513. **Use company research to personalize the email** — Reference what they build, not just what they asked. It shows you did your homework.
50614. **Match specificity to specificity** — Vague inbound gets pointed to resources with a clarifying question; specific technical questions get specific answers tied to their use case.
50715. **Always validate URLs before presenting the draft** — Fetch every link to confirm it resolves and points to the right content. Never send a broken link.
50816. **Always provide a DQ reason and DQ notes** — For every disposition except Qualify for Call, include the disqualification reason from the available list and copy-pasteable notes (250 chars or fewer). Be specific — name concrete signals from both the lead's message AND your company research.