Conversation
Refactor objectives section for clarity and organization. Update team member assignments and objectives for support improvements.
Deploy preview
|
|
Vale prose linter → found 2 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!
|
| Line | Severity | Message | Rule |
|---|---|---|---|
| 3:6 | warning | '1. Deepen SME expertise and reduce ticket friction' heading should be in sentence case, and product names should be capitalized. | PostHogBase.SentenceCase |
| 5:42 | warning | 'SMEs' is a possible misspelling. | PostHogBase.Spelling |
| 5: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 |
| 22:7 | warning | '2.1 SDK Doctor improvements' heading should be in sentence case, and product names should be capitalized. | PostHogBase.SentenceCase |
| 26: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 |
| 56:7 | warning | '3.1 Complete the Billing Support Superday task' heading should be in sentence case, and product names should be capitalized. | PostHogBase.SentenceCase |
| 56:40 | warning | 'Superday' is a possible misspelling. | PostHogBase.Spelling |
| 58:63 | warning | 'Superday' is a possible misspelling. | PostHogBase.Spelling |
| 73: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 |
| 77: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 |
|
@slshults @HaynesPostHog @darkopia @luke-belton @kyleswank @clr182 @eleftheriatrivyzaki @christiaan-ph @phillram @xljones |
|
|
||
| ##### 4.1 Improve response times and coverage for high-paying customers | ||
|
|
||
| **Objective:** Define and document when it makes sense to share a ticket across timezones vs. take care of it yourself, with the goal of reducing time-to-first-response for managed accounts. We'll know this is working when we can point to a clear, agreed process and median response times for these customers are improving. |
There was a problem hiding this comment.
I can see how it helps with time-to-first response, but I'd imagined the really key thing would be reducing time-to-resolution. I know we don't really track this, but I think it's maybe important to flag as the desired outcome?
There was a problem hiding this comment.
I can see how it helps with time-to-first response
Should belp with TTR too, no? If we can cumulatively spend 2-working days accross timezones on a particular ticket. Unless you're just commenting that we should track this too; which I definitely agree with!
|
|
||
| ##### 4.2 Clarify the boundary between Sales/CS-owned tickets and support-owned tickets | ||
|
|
||
| **Objective:** Create clarity around which tickets should be picked up by support vs. managed by Sales/CS. We'll know this is done when these tickets are handled more efficiently and fewer of these tickets remain breaching (but answered) in the queue. |
There was a problem hiding this comment.
IMO perfect OST topic if we can wait until then!
|
|
||
| ##### 4.1 Improve response times and coverage for high-paying customers | ||
|
|
||
| **Objective:** Define and document when it makes sense to share a ticket across timezones vs. take care of it yourself, with the goal of reducing time-to-first-response for managed accounts. We'll know this is working when we can point to a clear, agreed process and median response times for these customers are improving. |
There was a problem hiding this comment.
I can see how it helps with time-to-first response
Should belp with TTR too, no? If we can cumulatively spend 2-working days accross timezones on a particular ticket. Unless you're just commenting that we should track this too; which I definitely agree with!
|
|
||
| **Owner:** <TeamMember name="Eleftheria Trivyzaki" photo /> | ||
|
|
||
| ##### 3.1 Complete the Billing Support Superday task |
There was a problem hiding this comment.
nit - this is not big enough to be a quarterly goal!
|
@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? |
@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:
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. |
10 participants
Updated support goals for Q2