De-silo problems and solutions surfaced in Support
Promoted to Epics
Follow these for updates:
Context
Issue prompted by Support Team Call Discussion on 2020-02-11
Problem:
Support is at risk of becoming a silo for:
- technical problems and solutions with our product
- answers to questions commonly asked outside of Support
- pain points for GitLab admins and GitLab users
- patterns in self-managed customer priorities, environments, and configuration
This is a problem when teams outside of Support cannot easily locate solutions, answers to FAQs, or find this type of information.
The risk of becoming a silo increases as we scale.
For example, Community Advocates seek assistance for technical questions from community (free) users if they're not sure how of the answer.
Sample questions:
- I upgraded to the latest version now I see a 500 error after I log in, what can I do to fix this?
- Is there any way to check the GitLab database migration status?
- I'm unable to push my 11Gb GitLab project to GitLab.com. Is there a size limit for GitLab.com projects, can I buy more storage?
- We want to upgrade GitLab today but if there's any risk that GitLab will experience downtime, we'll need to schedule a maintenance window on the weekend. Are there any known issues with the latest GitLab version that might result in downtime?
- I upgraded from GitLab x.x.x to 12.0.0 and now our GitLab logs are filled with error messages. What happened and how do I fix it?
-
x509
errors consistently cause our CI jobs to fail, how can we fix this? - We are using custom certificates for HTTPS but GitLab Pages Access Control only works if we use HTTP, how can I fix it?
These questions are "low-hanging fruit" for Support but the answers are not easily discoverable for others who might need them to do their job effectively. @LindsayOlson @slee
Ideally, Support will communicate issues/patterns/solutions to other teams as well as internally to ensure we are not a silo of technical solutions and user problems.
Proposal:
-
Find ways to increase efficiency, effectiveness, and results of communication between Support and GitLab users and other GitLab teams.
Results
-
Double-down on docs first Epic -
GitLab Forum for Ticket Deflection and Community Support -
Define Silo-breaker Community Forum workflow -
create a guide for GitLab team members with ZenDesk light agent access on how to use search and filters to find solutions to commonly answered technical questions - see https://about.gitlab.com/handbook/marketing/community-relations/community-advocacy/workflows/forum/#strategies-for-finding-solutions-for-the-forum
-
remind and encourage using Support Week in Review as SSoT for all "actionable items" and "things to know about" in GitLab Support
Preserved for historical value:
Ideas:
-
Iterate on Support Week in Review -
this is the closest thing we currently have for raising attention about Support stuff async, particularly the "Actionable" and "Things to know about" sections
-
https://about.gitlab.com/handbook/support/#support-week-in-review
-
add a "Support Stable Counterpart Updates:" section?
"Double-down" on docs-first
- 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
ZenDesk:
Distill & transfer knowledge from Support Team Call Agenda/Notes and Slack (#support-managers, #support_self-managed, #support_gitlab-com ) to a doc that all can read and benefit from
- lots of good knowledge and Support discussion in here not discoverable for others
- how can we do this without requiring a lot of back and forth copy/paste?