chore: update support goals for Q2

[abigailbramble]

Updated support goals for Q2

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🟢 Ready	View preview	Apr 13, 2026 09:43AM

[github-actions]

Vale prose linter → found 3 errors, 8 warnings, 0 suggestions in your markdown

Full report → Copy the linter results into an LLM to batch-fix issues.

Linter being weird? Update the rules!

contents/teams/support/objectives.mdx — 3 errors, 8 warnings, 0 suggestions

Line	Severity	Message	Rule
3:211	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
5:6	warning	'1. Deepen SME expertise and reduce ticket friction' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
7:42	warning	'SMEs' is a possible misspelling.	PostHogBase.Spelling
7:76	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
24:7	warning	'2.1 SDK Doctor improvements' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
28:64	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
58:7	warning	'3.1 Complete the Billing Support Superday task' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
58:40	warning	'Superday' is a possible misspelling.	PostHogBase.Spelling
60:63	warning	'Superday' is a possible misspelling.	PostHogBase.Spelling
75:7	warning	'4.2 Clarify the boundary between Sales/CS-owned tickets and support-owned tickets' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
79:7	warning	'4.3 Get the team working from their SME queues' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase

[abigailbramble]

@slshults @HaynesPostHog @darkopia @luke-belton @kyleswank @clr182 @eleftheriatrivyzaki @christiaan-ph @phillram @xljones
Can you all please check over the wording and that it aligns with your thoughts/understanding? If happy then please approve.

[luke-belton]

IMO perfect OST topic if we can wait until then!

[xljones]

🙌

[charlescook-ph]

nit - this is not big enough to be a quarterly goal!

[charlescook-ph]

@abigailbramble I know it's kinda stating the obvious, but I think we should always have some overall SLA attainment goal here (in addition to the specific one around high paying customers). It seems like we've kinda settled into around the 80% range, but sometimes lower, which doesn't feel right when we used to aspire to 90%+ before?

(Relevant Slack thread)

[abigailbramble]

@abigailbramble I know it's kinda stating the obvious, but I think we should always have some overall SLA attainment goal here (in addition to the specific one around high paying customers). It seems like we've kinda settled into around the 80% range, but sometimes lower, which doesn't feel right when we used to aspire to 90%+ before?

(Relevant Slack thread)

@charlescook-ph I agree that the SLA attainment is not where we want it to be and we'd all like it to improve (it came up in several post-it notes in HOGS).

The question I've been sitting with is not whether we improve SLAs, but how - and specifically, how we do it in a way that's scalable and doesn't just mean "hire more people" or "respond to tickets and nothing else."

Setting a goal of "achieve 90% SLA attainment" risks producing the wrong behaviours: sending meaningless responses to pause the SLA timer, over-escalating to avoid spending time investigating, or skipping difficult tickets that have already breached to clear ones that haven't. None of that makes us better at support — it just games the metric.

Instead, I've tried to construct goals around the things that will specifically move SLAs in a sustainable direction:

• Deepening SME knowledge means

  • engineers can answer questions faster, know where to look, and are already aware of recent changes that might have caused an issue
  • identifying common investigation steps and things we can surface at the point a ticket is created means less time finding common bits of information
  • we look at how we can reduce ticket volume through proactively helping users and by providing better feedback to engineering teams

• Surfacing context onto tickets (Kyle, Christian) builds on the above, actively putting more relevant information in front of engineers at the point they start working on a ticket, making us faster.

• Impersonation improvements (Xander) mean we get to the information we need more efficiently = faster investigation, faster resolution.

• Improvements to SDK Doctor is another way to surface more information about customer setups, providing that information both to us and users - helping to make us faster and deflect more tickets.

Ticket deflection reduces the volume of tickets we need to handle in the first place, which means more time to get to the ones we do have. Making us faster/more efficient has a similar effect.

I've also deliberately pulled back on 'extracurricular' goals this quarter. In recent quarters we've taken on work in parts of the codebase we don't own, only to get blocked on other teams or find the product changed faster than we could keep up. This quarter I want us focused on being excellent at the core job (responding to customers) and making that faster, more efficient, and more scalable.

We could add a short section at the top of the goals that outlines the metric levels we're collectively aiming for. That way there's a clear shared reference point without any single metric becoming the goal in itself.

[charlescook-ph]

Chatted with @abigailbramble re above - I think we're all on the same page here! She'll add a note to the top of the goals, main thing is to see the SLA attainment consistently improving over the quarter, rather than a 'hit this specific number'.