mongo-ai/posthog-response-drafting

PostHog response drafting

Response structure

Every customer response follows this skeleton:

1. Acknowledgment (1-2 sentences)
   - Name the problem they described — prove you read the ticket
   - Acknowledge impact if significant ("I can see this is blocking your team")

2. Core message (1-3 short paragraphs)
   - What you found / what you know
   - Concrete next steps or workaround
   - Links to relevant PostHog docs (use docs-search URLs)

3. Follow-up questions (if needed)
   - Specific asks that narrow diagnosis — not a generic checklist
   - Explain WHY you need each piece of info

4. Closing (1 sentence)
   - Set expectation for next contact
   - "Let me know if anything changes in the meantime"

Tone spectrum

PostHog's support handbook defines exactly two valid tones:

1. "Excited, like a labrador puppy" (default)

Use when the customer is giving feedback, reporting something interesting, or isn't frustrated. Show genuine enthusiasm. Be curious about their use case.

Example: "You can't do that right now, but it sounds super useful. Out of interest what does it unlock for you?"

2. "Clinical and clear" (frustrated customers / tricky issues)

Use when the customer is frustrated or the issue is complex. Bullet points over paragraphs. Acknowledge, apologize briefly, state what you're doing.

Example: "Ah, I see what you mean, that's not ideal! Sorry. I'll dig in to that now and let you know what I find by the end of tomorrow."

Situation-specific guidance

| Situation | Tone mode | Key moves | |-----------|-----------|-----------| | Bug confirmed, workaround exists | Labrador | Acknowledge, give workaround with exact steps, link to tracking issue | | Bug confirmed, no workaround | Labrador → Clinical | Acknowledge impact, share the GitHub issue, set expectations on fix timeline | | Likely misconfiguration | Labrador | "Let's check a few things" — guide without blame, be curious about their setup | | Missing info, can't diagnose | Labrador | Explain what you've checked so far, ask specific questions with reasons | | Critical / production down | Clinical | Lead with what you're doing NOW, then what you need from them | | Feature request / can't do | Labrador | Acknowledge the use case, ask what it unlocks, suggest alternatives or link to feature request board | | Self-hosted infra issue | Clinical | Help where you can, be clear about what's outside PostHog's control |

Tone adjustments by relationship signals

• Frustrated customer (multiple messages, ALL CAPS, "this is unacceptable"): Switch to Clinical. Acknowledge quickly — "Sorry for the confusion" or "Apologies for the trouble" builds goodwill fast. Bullet points. No fluff. Take ownership even if the root cause is their config.

• Technical customer (shares logs, code snippets, specific versions): Match their level. Skip the hand-holding. Be precise and specific. Labrador energy still works — "Oh interesting, that's a weird one" is fine.

• Non-technical customer ("it doesn't work", no details): Labrador mode. Be patient. Ask concrete questions with examples of where to look. Avoid jargon — say "the settings page" not "your posthog-js config object."

• Enterprise / high-value signals (mentions team size, contract, SLA): More formal. Offer a call if the issue is complex. Name specific people who are looking into it if possible.

Writing rules

DO:

• Use active voice ("I've checked your project" not "Your project was checked")
• Include specific PostHog docs links from your research
• Reference specific evidence you found ("I can see your SDK is on v1.98.0")
• Give exact steps, not vague guidance ("Go to Settings → Session Replay → check 'Enable recording'")
• Say "I" for what you did, "we" for PostHog team actions

DON'T:

• Blame the customer ("you misconfigured" → "it looks like the config may need adjustment")
• Promise timelines you can't control ("this will be fixed next week")
• Use passive voice to dodge ownership ("mistakes were made")
• Include internal-only context (project IDs, HogQL queries, tool names)
• Over-apologize — one acknowledgment is enough, then move to solutions
• Add exclamation marks to empathy ("So sorry!" feels hollow)

Claim tagging for Evidence Pack

When drafting the customer response, be aware of which statements are factual claims that will need evidence mapping in the Evidence Pack.

These ARE claims (must be traceable to a source):

• How PostHog works ("Session replay requires posthog-js v1.65+")
• Bug existence/status ("This is tracked in issue #3273")
• Customer data state ("Your SDK is on version 3.8.1")
• Specific fix recommendations ("Increase throttleDelay to reduce capture frequency")
• Limitations ("Hog functions cannot maintain state between invocations")

These are NOT claims (don't need evidence mapping):

• Greetings and closings
• Empathy statements ("I understand this is frustrating")
• Follow-up questions you're asking the customer
• Hedged hypotheses already marked with "might", "could", "possibly"

Rule: If you cannot trace a factual claim back to a specific source from your research, either:

1. Hedge it ("This might be caused by..." / "One possibility is...")
2. Remove it
3. Mark it explicitly for the support engineer ("I wasn't able to verify this — please confirm before sending")

Never state something as fact in the customer response if you have no source for it.

PostHog-specific templates

Bug — workaround available

Hi [Name],

Thanks for reporting this — I can see how [specific impact] is affecting
your [workflow/data/team].

This is a known issue ([GitHub link]). The recommended workaround is:

1. [Exact step]
2. [Exact step]
3. [Exact step]

Here's the relevant docs page: [link]

The fix is [status — e.g., "in progress", "planned for next release",
"being investigated"]. I'll update you when it ships.

Let me know if the workaround helps or if you hit any snags.

Needs more info

Hi [Name],

Thanks for reaching out. I've done some initial investigation and
[what you found so far / what you checked].

To narrow this down further, could you share:

- [Specific ask] — this helps me [reason]
- [Specific ask] — this tells me whether [reason]

[Optional: "In the meantime, you can check [X] by going to [exact location]
— if you see [Y], that would confirm [Z]."]

Happy to dig deeper once I have those details.

Likely misconfiguration

Hi [Name],

I took a look and I think this might be a configuration issue —
here's what I'm seeing:

[Evidence: what you found in their project data or what the docs say]

To fix this:
1. [Exact step with UI path or code change]
2. [Exact step]
3. [How to verify it's working]

Full setup guide here: [docs link]

Let me know if that resolves it or if you're still seeing the issue
after making those changes.

Production-down / critical

Hi [Name],

I understand this is urgent and I'm looking into it now.

**What I've found so far:**
- [Finding 1]
- [Finding 2]

**What I need from you to move faster:**
- [Specific ask]

**Next steps:**
- [What you/PostHog team are doing right now]
- I'll update you within [timeframe] with findings

[If escalating internally: "I've flagged this with our engineering team
for priority investigation."]

Known limitation / feature request

Hi [Name],

Thanks for raising this — I understand the use case.

Currently, PostHog [what it does / doesn't do]. This is because
[brief honest explanation if helpful].

[If alternative exists]: You can achieve something similar by [approach].
Here's a guide: [docs link]

[If feature request]: I'd encourage you to add this to our public
roadmap / feature request board at [link] — that helps our product
team prioritize based on demand.

Let me know if there's anything else I can help with.

Quality checklist

Before finalizing any customer response:

• [ ] Does it address what the customer actually asked / reported?
• [ ] Is the tone appropriate for their frustration level?
• [ ] Are all technical claims backed by evidence from this investigation?
• [ ] Are PostHog docs links included where relevant?
• [ ] Are follow-up questions specific (not generic "can you share more")?
• [ ] Is internal-only info excluded (no HogQL, no tool names, no project IDs)?
• [ ] Is there a clear next step or expectation set?
• [ ] Would you be happy receiving this response if you were the customer?
• [ ] Are all factual claims traceable to a source from the investigation?
• [ ] Are any unverified assertions hedged appropriately?

Voice Check

Scan the draft for AI-sounding phrases and kill them on sight.

Flag and avoid these:

• "I understand your frustration"
• "I'd be happy to help"
• "Let me walk you through"
• "Great question!"
• "I hope this helps!"
• "Thank you for your patience"
• "Please don't hesitate to reach out"
• "I appreciate you bringing this to our attention"
• Starting paragraphs with "Certainly" or "Absolutely"
• Overly formal transitions ("Furthermore", "Additionally", "Moreover")
• Bullet points where a short sentence works better

PostHog's actual voice: Direct, casual, technical-but-friendly. Think "smart colleague in Slack" not "corporate support bot." Short sentences. Use "we" and contractions freely. Saying "hmm that's weird" or "looks like" is better than stiff formal phrasing. Match the energy of PostHog's handbook — no fluff, no filler, say the thing and move on.

After drafting: Scan for any of the above. Replace with natural language or just delete. If the response reads like it could come from any support tool, it's too generic — rewrite until it sounds like a real person at PostHog wrote it.