<commit_before>---
layout: markdown_page
title: Service Engineer Onboarding
---

## On this page
- [Expectations of the support team](#expectations)
- [First steps when you join the team](#first-steps)
   - [Training](#training)
   - [WebEx](#webex)
- [Handling tickets](#handling-tickets)
   - [Assigning a ticket to yourself](#assign-yourself)
   - [Point to documentation, or make it](#document-it)
   - [Create issues](#create-issue)
   - [Recording information about the organization](#fix-organization)
   - [Tags tickets](#tags)   
   - [After the first response](#first-response)   
   - [When and how to escalate a ticket?](#when-escalate)
   - [When to mark a ticket as solved?](#when-solved)
   - [Clearing out suspended tickets](#clear-suspended)
   - [Allowing teammates to adopt a ticket](#allow-others)
- [Receiving feedback](#feedback)
- [Dedicated Service Engineers](#dse)
- [Customer Training](#customer-training)
- [Team member is unavailable](#not-available)


## Expectations of the support team<a name="expectations"></a>

As members of the support team we are the first to interact with someone when they have a problem or question.
As such it is up to us to represent the company and make sure we present ourselves properly. Therefore we are
expected to:

- Always be friendly and respectful
- Be open to new ideas and points of view
- It is OK if you don't know something. You can always ask someone else
- It is OK to say no to a customer, but try to suggest a workaround and escalate to a Senior if necessary
- Read the guidelines on how to [respond on social media](https://about.gitlab.com/handbook/social-media-guidelines).

## First steps when you join the team <a name="first-steps"></a>

When you first join the team everything will be new to you. In order to get you started with GitLab quickly
you should take a look at the resources we have available at the [GitLab University](https://university.gitlab.com/).

The [user training](https://gitlab.com/gitlab-org/University/tree/master/training) we use for our customers
is also a great resource to get you started with the basics of Git and GitLab.

If you want to dig deeper into the inner workings of our great features, the best place to do that is
our [documentation](http://doc.gitlab.com) page.

You also need to familiarize yourself with the GitLab codebase. A great place to start is by installing the
[GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit). Any problem that our customers have will first
go through you, so you need to make sure you understand the issue and are able to radiate the information
you collect in a precise manner to the rest of the team. Make sure that you know how to install and upgrade
GitLab using our different installation methods:

- Omnibus (preferred)
- Docker
- From source

To familiarize yourself with ZenDesk, you can follow [this guide](https://support.zendesk.com/hc/en-us/articles/203921213).
This great resource written by ZenDesk Support will help you better know how ZenDesk works and how you can
use it to be more productive.

It is also encouraged to go over your colleagues' responses to previously submitted tickets, to see how they
craft their replies, and to get more insight and knowledge into topics with which you are unfamiliar.

### Training<a name="training"></a>

Right after joining the team you will go through a [training process](https://university.gitlab.com/support/)
with the guidance of a fellow Service Engineer. In this training you will learn the ins and
outs of GitLab, how to integrate it with the most used enterprise tools, like LDAP, JIRA,
Jenkins and SAML, how to best talk to our customers, and how to best radiate information you
collect across the team.

Initially, you will pick up relatively less complex tickets, and learn more about the product and the process by
responding to a large volume of these tickets. Typically, you will start by answering tickets that come in
through social media, advancing to general support tickets, and eventually subscriber, security, and emergency tickets.

### WebEx<a name="webex"></a>

More often than not, WebEx will be the best tool for customer calls, so you can save yourself a step and already start
a WebEx session for a call. To do this you can use the `GitLab Support` WebEx account. Go to our
[WebEx Portal](https://gitlabmeetings.webex.com), click on the login button on the top right and use the
credentials found in the Support Vault on 1password.

![WebEx Login](/images/support/web-ex-login.png)

Once logged in, click the `Enter Room` button to start the WebEx meeting and send the following link to
the customer and ask them to join the call.

```
https://gitlabmeetings.webex.com/meet/gitlabsupport
```

![WebEx Room](/images/support/web-ex-room.png)

WebEx is usually the best choice, since it allows you to see the customer's desktop and
to control it on request. It also gives the customer the possibility to join via phone and
us the possibility to use our computer audio connection.


## Handling tickets <a name="handling-tickets"/>

### Assigning a ticket to yourself<a name="assign-yourself"></a>

Assign a ticket to yourself the moment you decide you are going to work on it. If the nature of the problem
requires you to investigate further, let the customer know that you need further time to investigate, assign
the ticket to yourself, and submit the reply. By assigning the ticket to yourself you are letting your team members
know that you will work with this customer and by replying to the customer, even if you need further time to
craft a proper answer, you are acknowledging their request.


### Point to documentation, or make it<a name="document-it"></a>

As a general rule, you should always include a link to the applicable documentation as
part of your response to a ticket. If the documentation does not exist yet, then
_make_ the documentation and send the link in the response. For those situations
where making documentation is a more time consuming exercise:

- click the "Document this" checkbox on the ticket,
- respond to the ticket,

Tickets with the "Document this" option ticked will be added to a Google spreadsheet which the docs team can access.<commit_msg>Update wording and add internal links<commit_after>---
layout: markdown_page
title: Service Engineer Onboarding
---

## On this page
- [Expectations of the support team](#expectations)
- [First steps when you join the team](#first-steps)
   - [Training](#training)
   - [WebEx](#webex)
- [Handling tickets](#handling-tickets)
   - [Assigning a ticket to yourself](#assign-yourself)
   - [Point to documentation, or make it](#document-it)
   - [Create issues](#create-issue)
   - [Recording information about the organization](#fix-organization)
   - [Tags tickets](#tags)   
   - [After the first response](#first-response)   
   - [When and how to escalate a ticket?](#when-escalate)
   - [When to mark a ticket as solved?](#when-solved)
   - [Clearing out suspended tickets](#clear-suspended)
   - [Allowing teammates to adopt a ticket](#allow-others)
- [Receiving feedback](#feedback)
- [Dedicated Service Engineers](#dse)
- [Customer Training](#customer-training)
- [Team member is unavailable](#not-available)


## Expectations of the support team<a name="expectations"></a>

As members of the support team we are the first to interact with someone when they have a problem or question.
As such it is up to us to represent the company and make sure we present ourselves properly. Therefore we are
expected to:

- Always be friendly and respectful
- Be open to new ideas and points of view
- It is OK if you don't know something. You can always ask someone else
- It is OK to say no to a customer, but try to suggest a workaround and escalate to a Senior if necessary
- Read the guidelines on how to [respond on social media](https://about.gitlab.com/handbook/social-media-guidelines).

## First steps when you join the team <a name="first-steps"></a>

When you first join the team everything will be new to you. In order to get you started with GitLab quickly
you should take a look at the resources we have available at the [GitLab University](https://university.gitlab.com/).

The [user training](https://gitlab.com/gitlab-org/University/tree/master/training) we use for our customers
is also a great resource to get you started with the basics of Git and GitLab.

If you want to dig deeper into the inner workings of our great features, the best place to do that is
our [documentation](http://doc.gitlab.com) page.

You also need to familiarize yourself with the GitLab codebase. A great place to start is by installing the
[GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit). Any problem that our customers have will first
go through you, so you need to make sure you understand the issue and are able to radiate the information
you collect in a precise manner to the rest of the team. Make sure that you know how to install and upgrade
GitLab using our different installation methods:

- Omnibus (preferred)
- Docker
- From source

To familiarize yourself with ZenDesk, you can follow [this guide](https://support.zendesk.com/hc/en-us/articles/203921213).
This great resource written by ZenDesk Support will help you better know how ZenDesk works and how you can
use it to be more productive.

It is also encouraged to go over your colleagues' responses to previously submitted tickets, to see how they
craft their replies, and to get more insight and knowledge into topics with which you are unfamiliar.

### Training<a name="training"></a>

Right after joining the team you will go through a [training process](https://university.gitlab.com/support/)
with the guidance of a fellow Service Engineer. In this training you will learn the ins and
outs of GitLab, how to integrate it with the most used enterprise tools, like LDAP, JIRA,
Jenkins and SAML, how to best talk to our customers, and how to best radiate information you
collect across the team.

Initially, you will pick up relatively less complex tickets, and learn more about the product and the process by
responding to a large volume of these tickets. Typically, you will start by answering tickets that come in
through social media, advancing to general support tickets, and eventually subscriber, security, and emergency tickets.

### WebEx<a name="webex"></a>

More often than not, WebEx will be the best tool for customer calls, so you can save yourself a step and already start
a WebEx session for a call. To do this you can use the `GitLab Support` WebEx account. Go to our
[WebEx Portal](https://gitlabmeetings.webex.com), click on the login button on the top right and use the
credentials found in the Support Vault on 1password.

![WebEx Login](/images/support/web-ex-login.png)

Once logged in, click the `Enter Room` button to start the WebEx meeting and send the following link to
the customer and ask them to join the call.

```
https://gitlabmeetings.webex.com/meet/gitlabsupport
```

![WebEx Room](/images/support/web-ex-room.png)

WebEx is usually the best choice, since it allows you to see the customer's desktop and
to control it on request. It also gives the customer the possibility to join via phone and
us the possibility to use our computer audio connection.


## Handling tickets <a name="handling-tickets"/>

### Assigning a ticket to yourself<a name="assign-yourself"></a>

Assign a ticket to yourself the moment you decide you are going to work on it. If the nature of the problem
requires you to investigate further, let the customer know that you need further time to investigate, assign
the ticket to yourself, and submit the reply. By assigning the ticket to yourself you are letting your team members
know that you will work with this customer and by replying to the customer, even if you need further time to
craft a proper answer, you are acknowledging their request.


### Point to documentation, or make it<a name="document-it"></a>

As a general rule, you should always include a link to the applicable documentation as
part of your response to a ticket. If the documentation does not exist yet, then
_make_ the documentation and send the link in the response. For those situations
where making documentation is a more time consuming exercise:

- click the "Document this" checkbox (found on the left-hand side of the ticket)
- enter an ["internal note"](https://support.zendesk.com/hc/en-us/articles/213519318-Adding-comments-to-tickets#topic_bpn_sbd_bv) describing the documentation requirements
- update the ticket

Tickets with the "Document this" option are added to a ZenDesk view ["Documentation"](https://gitlab.zendesk.com/agent/#/filters/91188447). 
A [Zap](https://zapier.com/app/editor/9938098/overview) is used to add ticket details to a [Google Spreadsheet](https://docs.google.com/spreadsheets/d/1GcQvDThsXuV_n4OFwdYNmq07oO7coiS8xkMP84_-eKo/edit#gid=0).
{'fraction_non_alphanumeric': 0.07270201435517482, 'fraction_numerical': 0.004090453036968434, 'mean_word_length': 4.405924071756362, 'pattern_counts': {'":': 0, '<': 29, '<?xml version=': 0, '>': 29, 'https://': 20, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3306951', 'n_tokens_mistral': 3522, 'n_tokens_neox': 3326, 'n_words': 1807}