Zendesk for GitLab Developer Relations

Developer Relations Zendesk instance

The Developer Relations team uses a dedicated Zendesk instance to centralize the management of relevant community mentions, and to process Education Program, Open Source Program, and Startup Program applications and requests. This instance is separate from other Zendesk instances GitLab uses.

The majority of cases in Zendesk are routed there via Zapier automation, or a native Zendesk integration.

Each case is then converted into a Zendesk ticket and filtered into a View, ordered by category. As part of their daily workflow, the Community Operations Team, and the Education and Open Source Program Managers monitor these views and process tickets through completion.

Zendesk subscription

After a discussion with the GitLab Support team, it was concluded that for the specific Developer Relations workflows and metrics it would be best to keep the Developer Relations Zendesk instance separate from the Support team’s Zendesk instance.

The Developer Relations instance runs on a Professional Zendesk Support subscription, with one Agent seat per Developer Relations team member, plus extra seats for the team manager and collaborators. Additionally, the Collaboration Add-on provides us extra seats for Light Agents with read-only access to tickets.

Adding new agent seats to existing subscription

• If there is a need to increase the number of agent seats, contact the GitLab Account Manager at Zendesk. Their details are in the Developer Relations - Zendesk contact secure note in 1Password, on the Marketing vault.
• Account billing details (only accessible by the Zendesk instance owner)

After the initial contact and agreeing to the subscription plan update:

1. The GitLab Account Manager at Zendesk sends the unsigned service order to the DRI at GitLab via e-mail.
2. DRI submits a finance issue following the Procure to pay process, attaching the unsigned service order. See this existing subscription add-on issue for reference.
3. DRI works with stakeholders to complete the approval chain
4. DRI reaches back to the GitLab Account Manager at Zendesk and asks them to:
   1. Please send the DocuSign contract to our CFO to sign. His e-mail address is: {ADD_CFO_EMAIL}
   2. Please add the comment: “Approved by GitLab at {ADD_FINANCE_ISSUE_LINK}” to the DocuSign e-mail
   3. Please add me as CC on the DocuSign document so that I have visibility of it and get a notification when it’s been signed by GitLab
5. DRI uploads signed contract to ContractWorks after CFO signature.

Zendesk access

Zendesk access is provided during onboarding for members of the Developer Relations team when needed. Access as an Agent (read/write access to tickets) or a Light Agent (read-only access to tickets) can also be provided for other team members using the access request process if needed.

Once access is set up:

1. Go to https://gitlab-community.zendesk.com
2. Log in as “Agent” via SSO and your GitLab Google Workspace account.

Provisioning agents

To add an Agent:

1. Log into Zendesk
2. Go to Settings > Manage > People
3. Click on add agent
4. Fill in name and e-mail address
5. Choose the role, either Agent (read/write access to tickets) Light Agent (read-only access to tickets, but can leave internal notes)
6. Click Add
7. Choose the relevant groups for the new agent, and optionally set their time zone

Deprovisioning agents or changing roles

To find a user account and edit their status:

1. Log into Zendesk
2. Go to Settings > Manage > People
3. Enter their e-mail on the search box and click on Search
4. When the user appears on the list of results, click on Edit

To change the role for an account (e.g. promote or demote as Admin):

1. Follow steps above to find a user account and edit status
2. Click on the Role dropdown on the left
3. Select the appropriate role. The status is saved automatically upon change.

To deprovision (remove agent status):

1. Follow steps above to find a user account and edit status
2. Click on the Role dropdown on the left
3. Set the role to End User (no read/write access). The status is saved automatically upon change.

Zendesk views

View limits workaround

There is a limit on the number of views that can be displayed on the main “Views” panel on Zendesk, regardless of the type of subscription:

• 12 shared views
• 8 personal views

If the number of views exceeds these limits, the additional views are moved to the Settings > Views panel. As the Community Operations Manager makes use of the shared views feature, and as the number of response channels already exceeds the limit of 12, this poses a hindrance on ticket visibility and effectivity.

As a workaround, the team has decided to standardize our personal views, thus effectively increasing the number of visible Views to 20. If the number of response channels exceed the count of 20, an alternative approach could be to consolidate some of the existing views –a practice already followed where it makes sense (e.g. E-mail view).

The workaround is based on two steps: creating a shared view, which then can be cloned as a personal view.

Creating new shared views

To create a new shared view:

1. Navigate to Settings > Views
2. Click on the Add view button or clone an existing shared view
3. Set up or modify the filter conditions if necessary
4. On Available for, choose All agents
5. Inform the rest of the team about the availability of the new view

Cloning shared views as personal views

To create a personal view from a shared view:

1. Navigate to Settings > Views
2. In the views list, hover over the right hand side of view you want to clone
3. Click on the ellipsis to open the context menu
4. Choose Clone
5. Do not modify the filter conditions
6. On Available for, choose Me only

Zendesk macros

A macro is similar to an email template and consists of one or more actions that modify the values of a Zendesk ticket’s fields. Macros are applied to tickets manually from the drop down within each message.

While macros provide template responses, please keep in mind that the goal is to personalize each response as much as possible in order to provide excellent service to our community.

Macros can perform the following tasks:

• Add comment text
• Update ticket fields
• Add or remove ticket tags
• Add CCs
• Change the assignee
• Set the ticket subject
• Add attachments to ticket comments

Creating macros

There are two types of macros: personal macros (created by an agent or administrator for their own use) and shared macros (created by an administrator with permission for multiple users).

Please make sure to focus on creating shared macros since we want to keep all the info transparent and available to the whole team.

Tips:

• If you are creating a new Macro, open an existing one in another tab so you can see the formatting and all of the Actions you should add.
• If you think you need Admin access, let your manager know.
• Without Admin access, you can create Macros that are available only to you (e.g a Macro with your personal email signature).

Creating personal macros

Although only administrators can create the macros that are shared by all, we can also create personal macros. A personal macro is only visible to and can only be used or modified by the creator.

1. Click the Admin icon in the sidebar, then select Macros.
2. Click the All shared macros drop-down menu and select Personal macros.
3. Click the Add macro button.
4. Enter the macro name, and add actions for your macro as described in Building macro action statements.
5. Click Create.

Creating shared macros

Administrators (and agents in custom roles with permission) can create macros that are shared by all Zendesk Support agents or macros that are shared by only agents in a specific group. Administrators can also create personal macros for their own use.

A personal macro is only visible to and can only be used or modified by the creator. Administrators can create shared macros, and can modify all shared macros, regardless of who created them.

1. Click the Admin icon in the sidebar, then select Macros.
2. Click the Add macro button.
3. Enter a Macro name.
4. (Optional) Enter a Description.
5. Select an option from the Available for menu:
   • All agents, available to all agents.
   • Agents in group, available only to agents in the group specified. A drop-down menu to choose the group appears when you select this option.
   • Me only, available only to you.
6. Under Actions, use the drop-down menus to add actions for your macro as described in Building macro action statements.
   • If you choose the Comment/description macro action, and you have rich text formatting enabled, you can add formatting and inline images and you can add attachments to your macro comments.
7. Click Create.

Applying macros

You can manually apply one or more macros to a ticket. Just as you can make bulk updates to many tickets at once, you can also apply a macro to more than one ticket using your views.

A typical use case is a ticket that contains more than one question or issue, let’s say two in this example. You might have set up two macros that both insert a comment into a ticket to answer each issue separately. By applying each macro to the ticket, you add two comments and address both issues in a single response.

1. In a ticket , click the Apply macro button in the bottom toolbar.
2. Typically, your five most commonly used macros from the past week appear at the top of the macros list.
   • You can select one of these, begin typing the name of the macro, or scroll through the list to find the one you want to use.
3. The actions defined in the macro will be applied. If the macro updated the ticket comment, you can edit the text before submitting the ticket.
4. To apply another macro, click Apply macro again and select another macro.

Previewing macros

There is an option to view a description of a macro, and preview the update it will make to a ticket, before applying it.

1. In a ticket, click the Apply macro button in the bottom toolbar.
2. Scroll through the list to locate the macro you want to use.
3. Hover your cursor over the macro to display its description tooltip.
   • If the macro does not have a description, the tooltip does not appear.
4. If the description matches the macro you want to apply, click on it to use it.

Current macro stack (click link for macro details)

Common Requests

• Application Form Not Visible
• Authenticating Gold
• Delayed Response
• e-signature request via eSertifi (Salesforce)
• Error with processing application (Salesforce error)
• Handing off to sales team (Send via Gmail)
• Internal Support Ticket Filed
• License Update
• Pandemic response
• Redirect Technical Support Question to Forum (Support)
• Request modification to our terms
• Send Quote via Email
• Ultimate license download instructions

EDU

• EDU new application approval Zendesk notification
• EDU Renewal quote sent Zendesk notification
• Basic info on EDU program
• Collecting EDU qualification info
• EDU Announcement
• EDU General Rejection
• EDU Rejecting Students
• EDU Renewal Thank You
• EDU Requesting Email Domain
• EDU Requesting Non-Profit Verification
• EDU Requesting Renewal Information
• EDU Welcome
• Second email asking for participants data

NP

• Non-Profit Application

Ops

• CoC Violation:: Unable to moderate
• Email::Hackathon
• Email::Meetups
• Free CI/CD Update

OSS

• Clarifying “not-seeking-profit” req and Qualification Examples
• OSI-approved license
• OSS Announcement
• OSS Basic Program Information
• OSS new app need more info
• OSS new application approval (Zendesk notification)
• OSS Rejection
• OSS Renewal quote sent (Zendesk notification)
• OSS Renewal Reminder and Request for Info
• OSS Welcome (new applicants)
• OSS Welcome (Renewals)
• Qualification error, OSS federal exception rejection, and sales intro

Startups

• Need info about product and seats
• Providing basic program information
• Qualification for program
• Renewal request sales handoff
• Startup Rejection
• Startups Welcome

Swag

• Ask Customer to Contact Printfection
• Lost Order
• Out of Stock

Sending emails through Zendesk

Emails sent to our list of contact emails create a new ticket in Zendesk, and public comments in Zendesk are sent as an email from that contact email back to the recipient.

There are instances where it is necessary to change the email address of the recipient, the sender, or both, which can be done through Zendesk.

Changing the email recipient

1. Click (change) next to the recipient’s email address at the top of the ticket. Alternatively, you can click the 👤 symbol on the left pane to bring up the Requester field.
2. This will open the Requester panel on the left side. Paste the new email address in the Requester field.
3. If their email address is already in Zendesk, the record will show up, which you can select.
4. If their email isn’t in Zendesk, add them as a new user.
   1. Click Add new user
   2. Add their name and email to the corresponding fields
   3. Select End User as the role
   4. Click Add

5. If the email has been successfully changed, the new recipient will show up at the top of the ticket.

Changing the email sender

1. Check what email address is currently used to send replies from at the top of the ticket. It will say Via {email address}
2. On the top-right of Zendesk underneath your profile picture, click Apps Change sender step 2
3. The app panel on the right-hand side will open up. Click the dropdown next to Select an Email
4. Select the email address you want to send the email from via the drop-down list of email addresses.
5. If the sender address has been successfully changed, a notification saying This ticket will be sent from {email address} will pop up by the Apps tab, and the field at the top of the ticket will change.