posthog-inbound-leads

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PostHog Inbound Lead Disposition

PostHog 入站销售线索处置

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.

评估来自Salesforce的入站线索，要么起草回复邮件，要么推荐处置方案。此技能适用于处理入站销售咨询的所有PostHog TAE。

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)

获取线索上下文 — 读取TAE提供的所有信息（Salesforce字段、邮件正文、备注）
检查Vitally中的现有客户账户上下文 — 搜索线索的邮箱及邮箱域名（见下方步骤0）
调研公司信息 — 通过网页搜索了解公司业务、融资情况、规模及增长趋势（见下方步骤1）
识别使用场景 — 结合公司调研结果，将线索匹配到PostHog的六大使用场景之一或多个（见下方步骤2）
线索资格审核 — 结合公司调研和增长趋势，应用处置框架（见下方步骤3）
推荐处置方案 — 清晰说明推荐的行动方案及识别出的使用场景
起草回复邮件 — 根据其使用场景撰写合适的邮件（见下方步骤4）
验证所有URL — 获取草稿邮件中的每个链接，确认其可正常访问且指向预期内容（见下方步骤5）

Step 0: Check Vitally for Existing Account Context

步骤0：检查Vitally中的现有客户账户上下文

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.

在进行资格审核或起草任何内容之前，先检查Vitally，确认该线索（或其所属公司）是否已是PostHog用户。这会显著改变处置方式和邮件框架——现有客户寻求帮助与陌生入站线索的处理逻辑完全不同。

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.

使用线索的邮箱地址进行两次Vitally查询：

精确邮箱搜索 — 使用
```
vitally:search_users
```
，将
```
email
```
设置为线索的邮箱地址。这能确认该特定人员是否已拥有PostHog账户。
邮箱域名搜索 — 使用
```
vitally:search_users
```
，将
```
emailSubdomain
```
设置为线索邮箱的域名部分（例如，从
```
jane@acme.com
```
中提取
```
acme.com
```
）。这能确认其公司是否已有人员在使用PostHog。

若任一搜索返回结果，使用用户记录中的

accountId

，通过

vitally:get_account_full

获取关联账户信息。使用

detailLevel: "summary"

快速查看概览。

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.

线索邮箱对应的是现有用户：

他们已是PostHog用户。邮件中需提及这一点（“我看到您已在使用PostHog”），并聚焦于他们的具体需求，而非入门类资源。
查看其账户的MRR和健康评分——这能判断他们是寻求业务拓展的自助用户，还是存在扩容机会的现有客户。

同一公司的其他人员已是用户：

其公司已在使用PostHog。邮件中需提及这一点（“我了解到您的团队已在使用PostHog”），并询问他们的需求与现有使用情况的关联。
查看账户中的其他成员——线索可能需要与内部负责人对接，而非启动单独的评估流程。
若账户已分配TAE，需标记此信息，避免干扰他人的业务范围。

Vitally中无结果：

全新线索。继续执行下方的标准资格审核工作流。

What to surface to the TAE

需向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")

展示Vitally查询结果时，需包含：

是否找到该人员或其公司
账户名称及当前MRR（如有）
健康评分（如有）
已分配的TAE（如有——对路由至关重要）
账户中的用户数量
关于此结果如何改变回复方式的一句话建议（例如：“现有账户月均收入3000美元，未分配TAE——这是扩容机会，而非新线索”）

Step 1: Research the Company

步骤1：调研公司信息

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.

**此步骤对每条线索都是必需的。**仅通过线索的表单提交信息不足以进行资格审核或取消资格。来自估值60亿美元初创公司的1万MAU线索，与来自5人代理机构的1万MAU线索，需要完全不同的处置方式。

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

通过1-3次网页搜索了解公司情况，从公司名称和域名开始：

搜索
```
[公司名称] [域名]
```
— 获取基础信息：业务范围、目标用户
搜索
```
[公司名称] funding employees
```
— 获取企业基本信息：融资阶段、员工数量、增长信号
若公司知名度较高或融资充足，搜索近期新闻：
```
[公司名称] 2026
```
或
```
[公司名称] 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

从调研结果中识别并记录以下内容：

信号	重要性	示例
业务方向	决定使用场景匹配及是否为ICP	“面向制造业的AI工具” → AI/LLM可观测性相关
融资阶段及金额	预算和增长趋势的参考指标	B轮融资5000万美元 → 可能有工具采购预算
员工数量	支出潜力和团队复杂度的参考指标	200名员工 → 多团队、多项目潜力
工程团队规模或占比	PostHog的目标客户是工程师；工程师越多，匹配度越高	“80%团队为工程师” → 强ICP信号
增长趋势	判断当前MAU是上限还是下限	成立6个月，正在大规模招聘 → MAU将快速增长
近期新闻	影响业务背景的收购、发布、转型事件	刚收购一家AI初创公司 → 产品覆盖面扩大
商业模式	SaaS、市场平台、开发工具、代理机构等	B2B SaaS → 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.

根据调研结果，将公司分为以下四类增长趋势：

加速增长：近期获得大额融资（尤其是过去12个月内）、大规模招聘、有大量资金的早期公司，或有明显快速扩张迹象。当前MAU几乎肯定不是上限。示例：融资充足的A+轮及以后初创公司、刚完成巨额融资的公司、有“数百个空缺岗位”的公司。
稳定增长：成熟公司，增长适度且可预测。当前MAU可作为短期支出的合理参考。示例：中型SaaS公司，收入稳定；成熟PLG公司。
早期/未知：新成立公司，公开信息有限，难以评估增长趋势。将当前MAU视为最佳可用信号，但需注明不确定性。示例：种子前初创公司、无公开信息的保密模式公司。
持平/下滑：无增长信号、裁员或收缩迹象。当前MAU可能高估未来支出。示例：近期裁员的公司、团队规模缩小的公司。

**增长趋势分类直接影响资格审核。**见步骤3了解其如何调整2万美元阈值。

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.

调研时，留意线索公司拥有（或正在开发）多个产品的信号。这是支出乘数，因为每个产品通常会成为独立的PostHog项目，拥有各自的事件量。

线索消息中的信号：

“我们的部分产品” / “多个产品” / “全产品线”
“多个团队” / “不同业务单元”
“我们的平台和应用” / “我们的网页应用和移动应用”
“集成到我们的技术栈”（暗示业务广度）

公司调研中的信号：

公司拥有多条产品线或多个品牌
公司近期收购了其他公司（每次收购可能带来独立产品）
招聘信息提及多个产品团队
公司网站展示多个不同产品

当检测到多产品信号时，记录预估的产品数量（或范围），并将其纳入MAU乘数计算。一家拥有5个产品、每个产品1万MAU的公司，对应的是5万MAU机会，而非1万。

Detect AI/ML company signals

识别AI/ML公司信号

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

若公司调研显示该公司为AI原生（核心业务是构建AI/ML产品），即使线索消息未提及AI、LLM、模型成本或提示词，也需将AI/LLM可观测性标记为可能的次要使用场景。

AI原生信号：

公司描述提及AI、ML、LLM或“人工智能”为核心业务
公司处于AI相关行业（AI基础设施、AI应用、AI研究）
团队以ML/AI工程师为主
近期有AI相关收购或产品发布

检测到此类信号时，在使用场景评估中纳入AI/LLM可观测性，并在邮件中提及这一相关能力，即使线索未询问。表述方式如：“鉴于您正在构建AI产品，您可能还会发现我们的LLM分析功能对跟踪模型成本和性能很有用。”

What to surface to the TAE

需向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.

将公司调研结果整理为简要概况，包括：

公司业务（一句话描述）
融资及估值（如有）
员工数量及工程团队构成（如有）
增长趋势分类
多产品信号（如有）
AI原生标记（如有）
任何重要背景（近期新闻、收购、领导层信息）

此部分需紧跟Vitally查询结果，位于使用场景评估之前。

Step 2: Identify the Use Case

步骤2：识别使用场景

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.

每条线索都会匹配到PostHog六大使用场景中的一个或多个。识别使用场景决定了回复的框架、要突出的产品以及要链接的资源。结合人员/角色、公司（基于步骤1的调研）和消息内容来确定匹配关系。

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

使用场景	核心需求	核心买家角色	线索中的关键信号
产品智能	“帮助我了解用户行为、行为原因以及下一步要构建的功能。”	产品经理、设计师、产品工程师、创始人	提及分析、漏斗、留存、用户行为、“用户流失原因”、功能采用率、NPS、调研、用于UX研究的会话重放
发布工程	“帮助我更快交付代码且不破坏现有功能。”	工程经理、平台团队、开发人员	提及功能开关、版本发布、A/B测试发布、紧急关闭、渐进式交付、替换LaunchDarkly
可观测性	“帮助我了解故障发生时间、原因并快速修复。”	SRE、平台工程师、DevOps	提及错误跟踪、Bug复现、替换Sentry/Datadog、日志、事件响应、堆栈跟踪
增长与营销	“帮助我了解驱动获客、转化和收入的因素。”	增长工程师、营销负责人、CRO、GTM工程师	提及归因、ROAS、广告系列效果、替换GA4/Segment、转化优化、入职自动化、营销技术栈整合
AI/LLM可观测性	“帮助我了解AI功能的性能、成本以及用户交互情况。”	AI/ML工程师、AI产品经理、AI创始人	提及LLM、AI功能、模型成本、提示词测试、AI质量、替换Langfuse/Helicone、令牌使用量。也可从公司调研推断——若公司为AI原生，即使线索未提及，此使用场景也相关。
数据基础设施	“帮助我统一产品数据与业务数据，并将数据传输到需要的地方。”	数据工程师、分析工程师、产品运营	提及数据仓库、Snowflake/BigQuery、数据管道、批量导出、将PostHog数据与Stripe/CRM结合、替换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

人员角色是最强信号之一：

产品经理、产品负责人、UX研究员、设计师 → 产品智能
工程经理、工程副总裁、平台工程师、开发人员 → 发布工程（若提及错误/事件则为可观测性）
SRE、DevOps、基础设施工程师 → 可观测性
增长工程师、营销负责人、CRO、GTM工程师、需求生成专员 → 增长与营销
AI/ML工程师、AI产品经理、AI创始人 → AI/LLM可观测性
数据工程师、分析工程师、数据负责人、营收运营 → 数据基础设施
创始人/CTO（早期阶段） → 通常为产品智能或AI/LLM可观测性，取决于产品；可能覆盖多个场景

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

公司类型（基于步骤1的调研）有助于缩小范围：

AI原生初创公司 → AI/LLM可观测性几乎总是相关，通常与产品智能搭配
PLG SaaS公司 → 产品智能 + 增长与营销是最常见组合
拥有多团队的企业 → 通常从一个场景开始，但扩容潜力覆盖多个场景
电商/市场平台 → 增长与营销（转化、归因） + 产品智能（用户行为）
开发工具/基础设施公司 → 发布工程 + 可观测性

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?"

具体需求会确认或覆盖角色/公司信号：

“我们想了解用户行为” → 产品智能
“我们需要功能开关”或“替换LaunchDarkly” → 发布工程
“我们需要错误跟踪”或“替换Sentry” → 可观测性
“我们需要归因”或“替换GA4” → 增长与营销
“我们正在构建AI功能”或“LLM成本” → AI/LLM可观测性
“我们需要将数据导入Snowflake” → 数据基础设施
模糊的“展示功能” / “想要演示” → 无法从消息内容确定使用场景；需利用公司调研推断最可能的场景，然后提出针对性的澄清问题确认

若结合公司调研后使用场景仍不明确，需在邮件中加入针对性的澄清问题以缩小范围。围绕他们的问题而非PostHog产品提问：“您主要想解决什么问题？”比“您对PostHog的哪款产品感兴趣？”更好。

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

许多线索会匹配到多个使用场景。出现这种情况时：

优先关注主使用场景——最贴近他们所述痛点的场景
将次要使用场景作为自然延伸提及——“PostHog还支持X功能，通常团队在使用Y功能后会需要它”
不要试图推销整个平台——聚焦于解决他们提出的问题

Step 3: Qualify the Lead

步骤3：线索资格审核

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

2万美元年度支出阈值是默认资格标准，但增长趋势可覆盖此标准。

当以下所有条件均满足时，即使当前MAU单独无法达到2万美元阈值，也需确认符合通话资格：

增长趋势为“加速增长”——近期大额融资、大规模招聘、有大量资金的早期公司
高价值公司信号——至少满足以下两项：融资1000万美元以上、员工50人以上、工程团队占比高、多产品、AI原生
12个月内有合理路径达到2万美元——基于增长趋势和多产品乘数，他们在扩张过程中有可能达到阈值

当覆盖规则适用时，需在处置方案中明确注明：“当前MAU为1万，低于2万美元阈值，但增长趋势为加速增长（[融资X美元、Y名员工等]），且有多产品潜力。基于增长趋势确认符合通话资格。”

覆盖规则不适用的情况：

增长趋势为稳定、早期/未知或持平——根据当前信号坚持2万美元阈值
公司有融资，但线索的使用场景狭窄且不太可能扩容（例如，一家融资充足的公司询问针对某内部工具的功能开关）
线索来自大公司，但使用PostHog的团队规模极小且无扩容路径

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

当检测到多产品信号（来自线索消息或公司调研）时，调整MAU预估：

声明的MAU × 预估产品数量 = 调整后的MAU预估
使用调整后的预估进行资格审核，而非原始声明的MAU
在处置方案中注明乘数：“声明MAU为1万，但‘我们的部分产品’ + 公司调研显示有3-5个产品 → 调整后MAU为3万-5万”

此乘数为预估，非保证值。它会将处置方案从“明确低于阈值”转为“可能高于阈值，值得通话确认”。

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

当线索提及当前正在使用竞品并计划切换时（例如，“使用Heap并计划迁移”、“替换Amplitude”、“评估Sentry的替代方案”、“弃用LaunchDarkly”），这是高信号入站线索。他们已为该类工具分配预算，有明确需求，且可能有一定紧迫性。

**但2万美元下限仍然适用（除非增长趋势覆盖规则生效）。**竞品替换线索仍需显示年支出2万美元以上的潜力，才能符合通话资格。不要仅因他们正在从付费工具切换就提供通话机会。

对于竞品替换线索，初始回复需先获取BANT信号，再提供通话机会或引导至自助服务。提出针对性的探索问题，以了解：

预算：切换的原因是什么？成本、缺失功能、数据所有权还是其他？（若为成本，意味着已有预算。）
决策权：决策涉及哪些人？这是工程师主导的评估还是自上而下的要求？
需求：您希望PostHog解决哪些竞品无法解决的问题？您是只想替换[产品]，还是有兴趣整合其他功能（重放、开关、实验等）？
时间线：您计划何时做出决策？（不要在第一封邮件中问这个问题——让它自然浮现或在后续邮件中询问。）

**无需在第一封邮件中获取所有四个BANT信号。**提出1-2个问题以揭示最重要的未知信息——通常是预算（为什么要切换？）和需求（您想要获得哪些现有工具没有的功能？）。决策权和时间线可在回复中浮现。

线索回复提供BANT上下文后：

若回复确认有2万美元以上潜力且有实际使用场景 → 确认符合通话资格，并提供日程链接
若回复显示团队规模小/支出低/仅需简单替换 → 引导至自助服务，并提供特定迁移资源
若线索在您获取BANT上下文前要求通话 → 可以提供日程链接，但同时指出评估PostHog所需的所有信息（定价、文档、免费注册）均已公开，他们可同时开始评估

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

当线索消息模糊（例如，“想要启动评估流程”、“想要了解更多”、“对PostHog感兴趣”）但公司调研显示为高价值账户时，不要默认引导至自助服务。

相反，将高价值公司的模糊请求视为“需求探索”，而非“不足以通话”。处置方案应为“确认符合通话资格并提出探索问题”。

高价值公司指标（满足两项及以上即可）：

总融资1000万美元以上
员工100人以上
工程团队占比>40%
多产品信号
AI原生公司
增长趋势分类为“加速增长”
知名品牌或知名创始人/领导层

此类线索的邮件应：

确认他们的兴趣，不对使用场景做假设
提出1-2个探索问题以了解他们想要解决的问题
提及1-2个与公司类型最相关的PostHog功能（基于调研）
提供通话机会，介绍PostHog如何适配他们的技术栈

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

需满足以下所有条件：

年支出潜力≥2万美元（基于当前MAU，或多产品乘数调整后的MAU，或增长趋势覆盖规则）
工程师参与或将参与通话
有明确的使用场景（匹配上述六大场景之一）——或高价值公司的模糊请求（见上述特殊情况）
公司规模和产品需求需要销售协助

若符合资格，起草回复邮件需：

确认他们的具体使用场景（或针对高价值公司的模糊请求，确认其公司背景及可能的使用场景）
从相关使用场景手册中提出1-2个针对性探索问题
提供日程安排链接

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

满足以下任一条件：

根据公司规模、调研结果及增长趋势，支出潜力明显低于2万美元，且覆盖规则不适用
明确提及低用量（例如，“1000 MAU”、“小团队”、“刚起步”）且公司调研确认这已是上限（小公司、持平增长趋势）
请求模糊且无具体使用场景，且公司调研未显示为高价值账户
未提及或预期无工程师参与
通用的“了解更多”或“获取演示”请求，无实质内容，且公司调研未改变现状

起草有用的邮件需：

针对其使用场景提供资源以解答问题
提供与已识别使用场景最相关的产品文档链接
引导至自助服务渠道（应用内支持、社区）
不提供通话机会

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

明显不符合ICP（错误行业垂直领域，无产品-工程使用场景）
垃圾邮件或无关咨询
无需回复，或简短礼貌拒绝

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

当推荐“确认符合通话资格”以外的任何处置方案时，必须提供取消资格原因（从下方列表选择）和取消资格备注（250字符以内，具体且可直接复制粘贴到Salesforce取消资格备注字段）。

可用取消资格原因：

BAA / DPA 请求
低于销售协助阈值 - 合格
低于销售协助阈值 - 潜在客户
账单支持请求
业务关闭
重复线索
活动请求
现有客户咨询
反馈
无效联系信息
无预算
当前无需求
无产品匹配度
无回复 - 合格
无回复 - 潜在客户
无技术资源
非商业用途
匹配度不佳
其他
合作请求
资源限制
自托管要求
垃圾邮件
过期 - 自动关闭
创业计划 / YC
支持请求
使用竞品 / 主动RFP

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.

低于销售协助阈值 - 合格：支出潜力低于2万美元，无增长趋势覆盖规则，且无合理增长路径达到阈值。适用于引导至自助服务的小公司。
低于销售协助阈值 - 潜在客户：当前低于2万美元，但公司显示有增长到阈值的信号（例如近期融资、团队扩张）。值得后续跟进。适用于增长趋势良好但尚未满足覆盖规则标准的情况。
BAA / DPA 请求：线索需要BAA或DPA。注意：标准（无修改）BAA可通过Boost附加组件（250美元/月 + 基于用量的定价）获取，或通过Enterprise计划（2000美元/月，按年付费）获取定制/修改版BAA。当线索的主要需求是HIPAA/BAA且已提供相关定价信息时，使用此原因。
无技术资源：联系人非技术人员，且未提及或预期无工程师参与。
创业计划 / YC：早期阶段公司，引导至创业计划申请。
支持请求：他们提出的是支持问题，而非评估PostHog以购买。
现有客户咨询：已是PostHog客户，有产品/账单问题 - 非新销售机会。
无产品匹配度：他们的需求不是PostHog擅长的（例如自托管要求、行业不匹配）。

**取消资格备注必须具体且可复制粘贴。**包括证明取消资格的关键数据点，包括公司调研的相关发现。

优秀的取消资格备注：

“30人电商代理机构，收入100万-1000万美元。营销角色，无工程师。免费层级25万MAU。已解答功能开关问题，引导至自助服务。”
“湾区非营利组织，2万MAU，ICP匹配度-5。产品总监，使用场景明确，但远低于2万美元阈值。可通过Boost（250美元/月）获取BAA。引导至自助服务并提供HIPAA + 漏斗指导。”
“15人种子轮初创公司。开发人员询问功能开关。免费层级可满足需求。指向文档 + 应用内支持。”
“5人预营收初创公司，未找到融资信息。2000 MAU。模糊的‘想要了解更多’。引导至自助服务，建议申请创业计划。”

糟糕的取消资格备注：

“匹配度不佳”（过于模糊）
“小公司”（哪个信号重要？）
“引导至自助服务”（为什么？）
“低MAU”（您是否确认公司确实规模小，还是产品处于早期阶段？）

Email Structure

步骤4：撰写回复邮件

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

起草前请阅读

references/writing-style.md

。核心规则：

直奔主题：无冗长介绍，无冗余内容，无企业行话。
提供帮助，而非推销：用具体指导解决他们的问题。
态度明确：不要用“视情况而定”含糊其辞——推荐明确路径。
围绕他们的使用场景，而非PostHog产品：谈论解决他们的问题，而非产品名称。
利用公司调研进行个性化：若了解他们的业务，提及相关内容。“鉴于您正在构建面向制造业的AI工具”比“鉴于您正在评估分析工具”更好。
将链接嵌入锚文本：绝不粘贴裸URL或使用“点击这里”。
尽量少用格式：仅在列出资源或步骤时使用项目符号。保持对话式风格。
每封邮件最多一个问题：避免让收件人不知所措。

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

步骤5：验证所有URL

Product Intelligence

—

**此步骤为必需项。**在呈现草稿邮件前，使用

web_fetch

获取邮件中的每个链接，以验证：

URL可正常访问 — 返回200状态码，而非404或重定向到通用页面
内容与意图匹配 — 页面确实包含您链接它的目的内容（例如，标记为“功能开关入门”的链接应指向功能开关入门页面，而非通用文档索引）

若URL验证失败：

使用
```
web_search
```
在posthog.com上搜索正确页面（例如，“posthog docs feature flags getting started”）
用正确链接替换失效链接
若该资源无有效页面，移除链接，而非发送失效链接

**为什么这很重要：**PostHog的文档结构会变化。下方资源列表中的URL是起点，但可能已移动。销售邮件中的失效链接会损害可信度。发送前务必验证。

Release Engineering

按使用场景分类的资源链接

—

产品智能

Observability

发布工程

Error Tracking
Session Replay (for error context)

功能开关入门
实验
会话重放（用于调试版本发布）

Growth & Marketing

可观测性

错误跟踪
会话重放（用于错误上下文）

AI/LLM Observability

增长与营销

AI Engineering / LLM Observability
Experiments (for prompt/model testing)

Data Infrastructure

AI/LLM可观测性

AI工程 / LLM可观测性
实验（用于提示词/模型测试）

General (all use cases)

数据基础设施

Installation guide
Pricing page
Community questions
HIPAA compliance guide
BAA generator
In-app support button (always mention for product questions)
Free tier: 1M events/month, all core features included

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.

安装指南
定价页面
社区问答
HIPAA合规指南
BAA生成器
应用内支持按钮（产品问题始终提及）
免费层级：每月100万事件，包含所有核心功能

Non-Profit Discount Reference

BAA / HIPAA定价参考

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.

当线索提及HIPAA、BAA或医疗数据时，使用以下定价信息：

标准BAA（无修改）：

可通过Boost附加组件获取，价格为250美元/月 + 基于用量的定价
也可通过Scale和Enterprise附加组件获取
BAA可在posthog.com/baa生成，由PostHog会签

定制/修改版BAA：

需要Enterprise计划，价格为2000美元/月（按年付费） + 基于用量的定价
仅当客户想要修改标准BAA条款时需要

**核心表述：**优先推荐Boost作为标准方案。250美元/月对大多数组织来说都可承受，包括非营利组织和小公司。不要默认提及“企业定价”——这会吓跑本可轻松承担Boost费用的线索。

**实用提示（针对混合PHI/非PHI数据的线索）：**若仅部分漏斗或数据流涉及PHI，他们可立即在免费层级跟踪非PHI活动，同时为涉及PHI的部分处理BAA。

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

PostHog对非营利组织的信用购买提供折扣：

**信用购买低于2.5万美元：**15%折扣
**信用购买2.5万-10万美元：**在标准批量折扣基础上额外享受5%折扣
**信用购买超过10万美元：**适用标准批量折扣（无额外非营利组织折扣）

要获得资格，客户需提供证明，表明他们符合所在国家对非营利组织的定义（原产国税法）。

**注意：**在低MAU用量下，使用量保持在免费层级内，非营利组织折扣暂时无关——他们的主要成本是平台附加组件（例如用于BAA的Boost）。提及折扣，让他们知道在增长到需要付费时可享受此优惠。

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

回复TAE时，始终提供：

Vitally查询结果 — 是否在Vitally中找到线索或其公司，以及这意味着什么
公司调研结果 — 网页调研的简要概况：业务范围、融资、员工数量、增长趋势、多产品信号、AI原生标记
使用场景评估 — 此线索匹配哪六大使用场景，以及原因（基于角色、公司调研和消息内容）
处置方案推荐 — 符合资格 / 自助服务 / 创业计划 / 取消资格
取消资格原因 — 从可用列表选择（除“确认符合通话资格”外的所有处置方案均需提供）
取消资格备注 — 250字符以内，具体且可复制粘贴（除“确认符合通话资格”外的所有处置方案均需提供）
草稿邮件 — 要发送的回复，围绕已识别的使用场景撰写，并结合公司调研结果

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.

起草回复前请阅读：

```
references/email-examples.md
```
— 常见入站场景的示例邮件
```
references/sales-context.md
```
— 销售流程、阈值、资格审核标准
```
references/writing-style.md
```
— PostHog的语气、格式和风格规则

—

重要提醒

—

始终先检查Vitally — 在进行任何操作前，搜索线索的邮箱和邮箱域名。现有客户会彻底改变回复方式。
始终调研公司信息 — 绝不仅根据声明的MAU和线索消息进行资格审核或取消资格。5分钟的网页搜索可能将“放弃”变为重要客户。
增长趋势可覆盖2万美元阈值 — 具有强信号的加速增长公司，即使当前MAU较低，也应确认符合资格。记录覆盖规则的理由。
多产品信号是支出乘数 — “我们的部分产品”意味着声明的MAU是下限，而非上限。调整您的预估。
AI原生公司需将AI/LLM可观测性作为次要使用场景 — 即使他们未提及。这几乎总是相关的。
高价值公司的模糊请求需要探索，而非自助服务 — 不要因为60亿美元的初创公司未提交详细表单就将他们引导至文档。
非覆盖规则情况下，2万美元阈值严格执行 — 对于增长趋势稳定/持平且无高价值信号的公司，不要提供低于此阈值的通话机会。
始终识别使用场景 — 这是一切的基础：处置方案、框架和链接的资源。
始终推荐处置方案 — 不要只写邮件；明确说明资格审核决策，以便TAE更新Salesforce。
产品问题始终提及应用内支持 — 这是最快的帮助途径。
PostHog为产品工程师打造 — 若无工程师参与，这是资格审核的危险信号。
围绕问题，而非产品 — “以下是了解用户流失原因的方法”而非“这是我们的产品分析功能”。
利用公司调研个性化邮件 — 提及他们的业务，而非仅他们的问题。这表明您做了功课。
匹配具体程度 — 模糊的入站线索引导至资源并提出澄清问题；具体的技术问题提供与使用场景相关的具体答案。
呈现草稿前始终验证URL — 获取每个链接以确认其可正常访问且指向正确内容。绝不发送失效链接。
始终提供取消资格原因和备注 — 除“确认符合通话资格”外的所有处置方案，均需从可用列表中选择取消资格原因，并提供可复制粘贴的备注（250字符以内）。要具体——提及线索消息和公司调研中的具体信号。