The Community Forum is the official place for our wider community to seek technical support assistance with GitLab.
Technical support solutions shared in the forum reach a wide audience as they are indexed by search engines, making them easily discoverable to GitLab users looking for solutions.
Oftentimes, technical problems encountered and questions asked by our wider community have known solutions and answers that were provided to customers by GitLab Support team members in Support tickets. In this situation, having Support Engineers sharing these known tech support solutions in the community forum can be a highly effective form of ticket deflection.
Similar to GitLab Support ZenDesk tickets, unsolved GitLab technical support threads in the forum are often an opportunity to:
As such, GitLab Support Engineers should default to using a Docs-first approach to Community Support.
The critical points of the Docs-first approach for Community Support are:
There are several "special types" of content that are not well-suited for our documentation, such as Tutorials, "How-to" guides, and context-specific explanations.
A docs-first approach to Community Support in the Forum can help fill these "special type" gaps by making relevant answers/solutions easily discoverable and readily available.
For example, these Community forum threads where answers and solutions are "special types" that don't "fit" into the docs:
For detecting bugs, improving documentation, and identifying problems in our product that will affect paying customers, the GitLab community is an excellent resource.
The Community Forum is an early detection and early alert system for customer-facing problems.
GitLab FOSS makes up over 80% of the GitLab codebase. Any technical problems with this 80% of the codebase impact all GitLab users, including customers.
Free users often surface up bugs, regressions, and problems with our product or docs in the Community forum before we start getting support tickets from customers about them.
Silo-breakers take common answers/solutions in Support ZenDesk and ensure they're available and discoverable to all GitLab users.
Support team members may notice patterns or trends in incoming Support tickets - new FAQs, increasingly common problems, confusion regarding a new feature, unclear documentation, or bugs affecting customers.
We communicate internally, usually via Slack and Support Week in Review, to raise awareness in Support and help anyone who encounters tickets on the subject.
If these same patterns or trends are present in the Community forum, providing answers and solutions in forum threads helps ensure answers/solutions are discoverable via a search engine.
Specializes in picking "low-hanging fruit" by publicly sharing known answers and solutions.
It is more worthwhile to teach someone to do something (for themselves) than to do it for them (on an ongoing basis).
The forum is like fishing, "Toss in a question or problem, get an answer or solution".
"Fishing instruction" in this context is an opportunity to showcase the resources available and how to find them. (docs, issues, MRs, codebase, forum threads).
Currently, we have a lot of folks reach out to Support without first looking for easy answers/solutions.
The most efficient and effective way to connect users with appropriate support option is to act in a way that encourages and increases the following support-seeking user flow.
"Fishing instructors" enable and empower GitLab users and customers to catch their own fish - find solutions and answer questions without Support intervention.
By directing incoming Free user tickets to the Community forum, free users get in the habit of finding answers/solutions without relying on GitLab Support.
Win-win-win - benefits GitLab community, customers, and team members.
For additional tips and best practices when working in the Community forum, refer to the Community Relations Handbook entry for the Community forum.