Support team "double-down" on docs-first
"Double down": strengthen one's commitment to a particular strategy or course of action
Proposal
Strengthen Support team commitment to docs-first methodology and involvement in ticket deflection through documentation to improve Ticket deflection through documentation updates performance indicator results.
performance indicator?
How to improveIdeal solution: deliver results that benefit everyone (customers, employees, community/free users) with minimal disruption and impact to existing workflow?
Improve team involvement and participation
- Add request for feedback/ideas/advice to Support Week in Review as top actionable item.
- Measure support team's current involvement in documentation updates based on customer interaction.
- Set goal of (roughly) doubling the Support teams involvement in documentation updates based on customer interaction.
- ???
Improve skills and abilities
-
Add
docs-first
item in Support Engineer onboarding issue (~15 min time to completion, links to Support workflow, performance indicators, and docs-first methodology entries in handbook) -
Create optional
docs-first
bootcamp for those interested in easily and efficiently contributing documentation updates and fixes based on customer interaction. - ???
How to measure results?
Data-driven is best.
Existing Support team KPI is Ticket deflection through documentation updates
- Define desired results, expected results.
- Define data points required to measure/track results, use as metrics.
- Get a baseline measurement.
- Set attainable goals.
- Communicate goals and effort.
- Track correlation between output/involvement and positive results.
Why?
Support team and ZenDesk can be a silo (#2104 (closed) ) for solutions that don't make it to our documentation.
Without adding these solutions to our documentation, the solutions are:
- not available to GitLab free/community/Core/CE/FOSS/EDU users
- only accessible to customers and GitLab Support
- not discoverable by anybody (Support is source of truth?)
For Support and GitLab employees with ZenDesk access, solutions are difficult to find and easy to lose. If action is not taken shortly after thinking about a documentation fix or update, an issue and MR doesn't get made.
Context
If it's okay to send to the customer, it's okay to add to the documentation - Sid
Conversation with Sid on GitLab Unfiltered
we should have a really low bar for adding things to the troubleshooting section of docs. Nothing should only be findable in ZD - @cynthia (paraphrasing Sid)
I would even go step further and say that we should lower the bar for adding to any part of the docs, not only troubleshooting section. I mean, exactly as he said, if it’s OK for one customer, it most likely won’t hurt others. - @mhuseinbasic
- Docs-first methodology
- Ticket deflection through documentation
- need to set a threshold to separate MR-worthy updates vs Support "things to know about"
- evaluate scope, impact on customers, and or likelihood of occurrence?
- if we can reproduce a problem ourselves, a customer will likely have that problem too
Created as part of the larger effort here: