Tickets

This guide covers ticket management in Zendesk, including ticket statuses, system settings, and common Support Operations workflows.

Understanding tickets

Creating tickets

Traditionally, we want end-users creating their own tickets. In situations where that may be less than ideal, there are set options available to be used.

Via the Zendesk Super App

This should be used when you need to make a new ticket from an existing user. For this, you would use the corresponding app:

• For Zendesk Global: Zendesk Super App
• For Zendesk US Government: Zendesk Super App

For outbound communication

See the Support team’s Sending Notices documentation for more information.

Viewing tickets

For information on viewing tickets, please see:

• Views
• Searching

Statuses

As per Zendesk the various status are defined as:

• New
  • This indicates that no action has been taken on the ticket. Once a New ticket’s status has been changed, it can never be set back to New.
• Open
  • This indicates that the ticket is waiting for action by the agent.
• Pending
  • This indicates that the agent is waiting for more information from the requester. When the requester responds and a new comment is added, the ticket status is automatically reset to Open.
• On-hold
  • This indicates that the agent is waiting for information or action from someone other than the requester. It is similar to the Pending status in that you as an agent can’t proceed with resolving the ticket until you receive more information from someone else. However, the On-hold is an internal status that the ticket requester never sees. While a ticket is set to On-hold, the requester sees the status as Open.
• Solved
  • This indicates that the agent has submitted a solution or the end-user has marked it as such. A solved ticket can still be edited or re-opened.
• Closed
  • This indicates that the ticket is in a state where it can no longer receive updates. Replying to a closed ticket opens a follow-up ticket, which contains all previous tags and links to the previous ticket.

At GitLab, we define them a bit differently:

• New
  • This is a new ticket. This means it has not yet been worked by GitLab.
• Open
  • This means the ticket is awaiting our reply.
• Pending
  • This means we are waiting on the end-user to reply. We should only use this specifically when the user will reply back to the ticket (or it will auto-solve). If you need to keep a ticket in a “pending” like state for lengthy periods of time, use On-hold.
• On-hold
  • This means the end-user is waiting on us, but we are waiting on something that is blocking us from replying. We should only be using this in situations where we are waiting on something such as a different department, time to pass (namesquatting requests as an example), or some other criteria that fits along the same concept.
• Solved
  • This means the ticket has been resolved, but the end-user might come back to us.
• Closed
  • We use them exactly as Zendesk defines them.

Current system ticket settings

These settings are documented here for reference and should rarely be changed.

Current ticket sharing settings

These settings are documented here for reference and should rarely be changed.

Administrator tasks

Modifying closed tickets

While Zendesk has the ability to update some values within closed tickets, it is not an action that we will perform. After discussions with several teams utilizing data from Zendesk and a review of the customer facing impact modifying closed tickets would have, the decision is based off the following reasons:

• Updating closed tickets would have a negative impact on customers (with no viable workaround)
• Updating closed tickets would severely impact reports/dashboards in Zendesk Explore, requiring full re-configuration
• Updating closed tickets would severely impact reports in our data warehouse, requiring full re-configuration
• Updating closed tickets would require a full re-index of the data within our data warehouse (consuming massive amounts of resources and requiring 5+ days)
• We have viable workarounds that can be done within our data warehouse using custom views, custom tables, and AI (negating any perceived benefits to performing updates on closed tickets)

Modifying system ticket settings

To modify the system ticket settings:

1. Navigate to the admin dashboard for the Zendesk instance
   • Zendesk Global (production)
   • Zendesk Global (sandbox)
   • Zendesk US Government (production)
   • Zendesk US Government (sandbox)
2. Go to Objects and rules > Tickets > Settings
   • Zendesk Global
   • Zendesk Global (sandbox)
   • Zendesk US Government
   • Zendesk US Government (sandbox)
3. Make modifications to the settings you wish to change
4. Click Save at the bottom-right of the page

Modifying ticket sharing settings

To modify the ticket sharing settings:

1. Navigate to the admin dashboard for the Zendesk instance
   • Zendesk Global (production)
   • Zendesk Global (sandbox)
   • Zendesk US Government (production)
   • Zendesk US Government (sandbox)
2. Go to Objects and rules > Tickets > Sharing
   • Zendesk Global
   • Zendesk Global (sandbox)
   • Zendesk US Government
   • Zendesk US Government (sandbox)
3. Make modifications to the settings you wish to change
4. Click Save tab at the bottom-right of the page

Customer Support Operations Workflows

Working tickets

Managing support contacts

For Zendesk Global tickets about managing contacts, please see our Organization association documentation.

For Zendesk US Government tickets about managing contacts, all support contact association is done via a sync with the Salesforce account. As such, we cannot assist here. You will need to instruct the requester to contact their account manager via a new email. Make sure to provide the email of the account manager.

Shared organization requests

Please see our Shared Organization setup documentation.

Portal issues

These are reports of issues within the support portal. While each issue can present unique challenges, the common troubleshooting guide for the users can be found at:

• Zendesk Global
• Zendesk US Government

At the point you get the ticket, the user may or may not have done all of that. If they have not, point them to trying all that out first.

If they have, you will need to analyze the details of what is sent to determine next steps.

Adding a secondary email requests

Sometimes a customer will raise issue stating they want to add a secondary email to their support portal account. Secondary emails are used to tie submitted tickets to a specific account, although only the primary email address will be used as the submitter (and thus receive notifications).

• For GitLab.com Users:
  • The GitLab.com account associated to the requester’s email address should have listed the secondary email as verified. You can check this via the User Lookup app. To add secondary email to GitLab.com account, they can follow this documentation
• For Self Managed and GitLab Dedicated Users:
  • The ticket needs to be submitted from the email address they wish to have added to their existing profile
  • The customer will need to provide proof of support entitlement again via this secondary email address
  • The customer will need to CC the primary email address of the support portal account and have that email reply on the ticket confirming the request to add the secondary email address to their support portal account.
• For Partners:
  • Use the same steps you would for Self Managed and GitLab Dedicated Users

Incorrect form tickets

When a ticket is using the incorrect form, agents will use the General::Forms::Incorrect form used macro. This will change the form to Support Ops, tag the ticket, and leave an internal note. From there, we are expected to review the ticket and determine the next steps.

Your ultimate goal here is to move it to the correct form. The path to doing so depends on a great many factors, but in general:

• If being moved to a “paid only” form and the user is unassociated:
  • Follow the process of Organization association to get the user associated
    • If they are not able to be associated, the ticket cannot be moved
  • Set the Assignee value on the ticket to Support Ops (a group)
    • This will unassign the ticket. You should always do this unless the internal note added when it was sent to us indicated otherwise
  • Change the Form value on the ticket to the new form
  • Fill out all ticket metadata possible for the new form
    • If present on the ticket, set the Ticket Stage field to FRT
  • Remove the following tags:
    • base_weight_set
  • Make sure to submit the ticket as the same state it was sent to us in
• If being moved to a “paid only” form and the user is associated:
  • Set the Assignee value on the ticket to Support Ops (a group)
    • This will unassign the ticket. You should always do this unless the internal note added when it was sent to us indicated otherwise
  • Change the Form value on the ticket to the new form
  • Fill out all ticket metadata possible for the new form
    • If present on the ticket, set the Ticket Stage field to FRT
  • Make sure to submit the ticket as the same state it was sent to us in
• If being moved to a form available to anyone:
  • Set the Assignee value on the ticket to Support Ops (a group)
    • This will unassign the ticket. You should always do this unless the internal note added when it was sent to us indicated otherwise
  • Change the Form value on the ticket to the new form
  • Fill out all ticket metadata possible for the new form
    • If present on the ticket, set the Ticket Stage field to FRT
  • Make sure to submit the ticket as the same state it was sent to us in

Special form notes

• If moving the ticket to the 2FA Removal form
  • If the request for removal is for a user different than the requester, the requester must provide the email address of the target user. If they have not, leave an internal note stating the requester must provide that piece of information. After doing so, move the ticket to the SaaS Accounts form instead.
• If moving the ticket to the L&R form
  • When moving tickets to the L&R form, we need to ensure it is routed to the right subteam at the start. To do this, ensure the BPO Ticket checkbox (at the bottom of the ticket metadata) is checked. Failing to do so can potentially result in problems in ticket routing.
• If moving the ticket to the Billing form
  • You must ensure the Billing/AR Team attribute on the ticket is populated. If it is unclear which value to use, set it to Billing

Handling malicious users

When a ticket arises containing potential malicious actions (hacking, phishing, abuse, etc.), we need to always treat it seriously.

If, after a thorough investigation, it is determined to be malicious, ban the user

When in doubt, escalate the matter to your manager, a Customer Support Operations Fullstack Engineer, and/or the GitLab Security team.

Common issues and troubleshooting

This is a living section that will have items added to it as needed.

View page source - Edit this page - please contribute.