Unlike typical companies, part of the mandates of our Security, Infrastructure, and Support Departments is to contribute to the development of the GitLab Product. This follows from these concepts, many of which are also behaviors attached to our [core values](/handbook/values/):
*[Dogfooding](/handbook/values/#dogfooding)
*[Everyone can contribute](/company/mission/#everyone-can-contribute)
*[Everyone can contribute](https://about.gitlab.com/company/mission/#everyone-can-contribute)
As such, everyone in the department should be familiar with, and be acting upon, the following statements:
@@ -11,6 +11,6 @@ As such, everyone in the department should be familiar with, and be acting upon,
* If we need something, our first instinct should be to get it into the open source project so it can be given back to the community
* Try to get it in the open source project first, rather than later, even if it's 2x harder
* We should be using the whole product to do our jobs
* We are all familiar with our [Dogfooding process](/direction/dogfooding/) and follow it
* We are all familiar with our [Dogfooding process](https://about.gitlab.com/direction/dogfooding/) and follow it
* We should not expect new team members to join the company with these instincts, so we should be willing to teach them
* It is part of managers' responsibility to teach these values and behaviors
| A customer, or an advocate for a customer | Technical assistance | Public [Support Page](https://about.gitlab.com/support), which describes the best way to get the help you need and lists GitLab's paid service offerings |
| GitLab team member | Technical assistance | [Internal Support for GitLab Team Members page](internal-support) |
| New Support Team member | Onboarding / Learning | [Support Engineer Responsibilities](/handbook/support/support-engineer-responsibilities.html) page and [Support Learning Pathways](/handbook/support/training/) |
| New Support Manager | Onboarding / Learning | [Support Manager Responsibilities](/handbook/support/managers/manager-responsibilities.html) page and [Support Manager Pathways](/handbook/support/training/#support-manager-onboarding-pathway) |
| New Support Team member | Onboarding / Learning | [Support Engineer Responsibilities](/handbook/support/support-engineer-responsibilities) page and [Support Learning Pathways](/handbook/support/training/) |
| New Support Manager | Onboarding / Learning | [Support Manager Responsibilities](/handbook/support/managers/manager-responsibilities) page and [Support Manager Pathways](/handbook/support/training/#support-manager-onboarding-pathway) |
Know someone who might be a great fit for our team? Please refer them to the job-family descriptions below.
@@ -57,7 +57,7 @@ which are largely focused around pursuing customer success and satisfaction
while driving efficiency by increasing output while keeping costs within a
predefined range.
This is also why [Support Engineer responsibilities](/handbook/support/support-engineer-responsibilities.html)
This is also why [Support Engineer responsibilities](/handbook/support/support-engineer-responsibilities)
include contributing code and documentation and working alongside Product
Managers on our products: By using the knowledge gained from interacting with
our customers to make our products or docs better, we solve problems before
@@ -140,10 +140,10 @@ Below we also have some commonly referenced pages:
-[Support Global Groups](/handbook/support/support-global-groups/index.html) - all
about the smaller groups in which Support Engineers work on support tickets
@@ -197,7 +197,7 @@ Dogfooding is using a piece of GitLab *for its intended purpose*. For example, o
In other words: Dogfooding is using the product in the way that our customers would use it to the end of discovering and solving pain points that they have. Dogfooding supports [customer results](/handbook/values/#customer-results).
At GitLab Support we use Service Desk to process [Personal Data Requests](/handbook/gdpr/), but not for our global support because the customer for Service Desk is primarily small teams soliciting [*bug reports, feature requests, or general feedback*](https://docs.gitlab.com/ee/user/project/service_desk/). Through our use of Service Desk in this smaller setting we've been able to influence product direction towards adding features like [internal notes](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note).
At GitLab Support we use Service Desk to process [Personal Data Requests](https://about.gitlab.com/handbook/gdpr/), but not for our global support because the customer for Service Desk is primarily small teams soliciting [*bug reports, feature requests, or general feedback*](https://docs.gitlab.com/ee/user/project/service_desk/). Through our use of Service Desk in this smaller setting we've been able to influence product direction towards adding features like [internal notes](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note).
We continually evaluate product features for use-cases within Support and provide feedback and feature requests where blockers exist. Support will always prioritize [customer results](/handbook/values/#customer-results) over any other consideration.
@@ -215,7 +215,7 @@ TODO: Replace with current GitLab implementation
## Hazards and Challenges
See [Managers/Hazards page](/handbook/support/managers/hazards-and-challenges.html)
See [Managers/Hazards page](/handbook/support/managers/hazards-and-challenges)
## Communications
@@ -428,7 +428,7 @@ All Zoom and agenda links can be found on the relevant calendar entry in the [Su
#### Support Team Call
Support team members in some regions meet up regularly.
Details of these calls are on the [Weekly Support Team Call workflow page](/handbook/support/workflows/team/weekly_team_call.html).
Details of these calls are on the [Weekly Support Team Call workflow page](/handbook/support/workflows/team/weekly_team_call).
#### Support Leadership Meetings
@@ -517,7 +517,7 @@ between a product team and Support for the purpose of discussing product issues,
sharing product knowledge and representing customer needs. If you are interested
in becoming a Support Stable Counterpart, or would like to learn more about the
title:GitLab Support - Support Ticket Attention Requests (STAR)
description:Process documentation for getting additional attention on a ticket from Support leadership.
---
- TOC
{:toc .hidden-md .hidden-lg}
## Overview
This document outlines the process for managing support tickets that, due to business-critical situations, require our attention or an initial response more quickly than what is defined in our [standard response time.](https://about.gitlab.com/support/#priority-support).
@@ -81,7 +77,7 @@ The Zendesk STAR App is available only during our [Global Support Hours](https:/
To access, click on the Apps button located in the top right of the page (underneath your profile icon). When you click on it, it will expand to show the STAR form within Zendesk.
When you use this method, the app automatically acquires most of the required information directly from the ticket. That's a lot less work for you, and you can be assured that the data will already be validated before it is sent to the Support Managers for evaluation.
@@ -95,7 +91,7 @@ You will only need to provide:
Here is how the form will appar in the Zendesk App:
description:Details on how the priority prospect system works
---
@@ -12,9 +11,6 @@ If you've been contacted by a prospect whose evaluation of GitLab includes evalu
Free access to support granted in this way is not for any customer who wants it, but for strategically important prospects for whom evaluation of support is part of their decision criteria. There may be many factors Sales leadership will consider in deciding which prospects are eligible. Generally, prospects with potential ARR of less than $100,000 may not be likely to be approved.
- TOC
{:toc .hidden-md .hidden-lg}
## Process Restrictions
- Only 30 priority prospects can exist at any one time. The current reference
