Satisfaction (SSAT) review and responding (for Managers)

To understand the factors contributing to Support Satisfaction, we review feedback received for support tickets. Issues are automatically created in the Feedback issue tracker (internal only) for all Support Satisfaction feedback received.

NOTE: The following categories of tickets do not receive surveys:

• Spam tickets (ones marked as spam and suspended)
• Free user tickets (ones containing the tag free_customer)
• Embargo tickets (ones containing the tag com_embargo)
• Tickets with the organization GitLab or DigitalOcean Support

Subscribing to Customer Feedback Issues

By territory

If you’d like to subscribe to SSATs submitted by customers from a certain territory, you can subscribe to the appropriate OrganizationRegion scoped label through the Feedback project labels page.

These labels are applied based on organization information synced to Zendesk from SFDC.

The single source of truth for these definitions can be found in the Go to Market Glossary handbook page.

Who is responsible for reviewing Support Satisfaction feedback

The SSAT Reviewing Manager PagerDuty schedule is the SSOT for who is on-call. The Support Week in Review document identifies the current SSAT Reviewing Manager, with a link to the PagerDuty schedule.

The SSAT Reviewing Manager on duty when a feedback issue is created is responsible for reviewing the issue and responding as needed. Feedback issues are assigned to the SSAT Reviewing Manager automatically. The manager receives email notification from GitLab and a To-Do item.

Sources of feedback

Currently, the following methods create feedback issues for review:

1. Automatic email survey – sent to customers when tickets are closed.
2. Mid-ticket feedback link – each Public Comment from a GitLab Support Engineer or Manager has a link to a form where a customer can provide feedback or request contact from a manager while the ticket is open (introduced in issue 2913).
   1. This feedback form creates issues in the customer feedback project, with a subject format of Positive/Negative/Neutral feedback for ticket nnnnnn, and is automatically assigned to the SSAT reviewing manager.
   2. If the feedback is negative, there is an option to request manager contact (within 48hrs Mon-Fri). If this option is chosen, a Slack notification is sent to the #support_ticket-attention-requests channel. The On Call Manager should promptly follow the guidance in Handling mid ticket feedback requesting manager contact during business hours.
3. GitLab team members (such as CSMs and Sales team) can open an Indirect Feedback issue with details they received from the customer.
4. Any issue requiring contact can also be identified by applying the SSAT::Contact label. In the Description or in a Comment, specify that manager contact was requested.

What does success look like?

At the end of your rotation:

1. You should have performed the triage work described in the handling “Good” and “Bad” sections for each feedback issue assigned to you.
2. You should have initiated any customer or GitLab group contact.
3. You should have closed all feedback issues assigned to you that have no outstanding dependencies on other groups or on the customer.

How fast do I need to respond?

Currently there is no SLA for responding to Feedback Issues, but if you follow the process defined on this page, you should send an initial response to each issue within 7 days of its creation.

Workflows for reviewing feedback

Our Feedback and Complaints handbook page provides general guidance on assessing and responding to feedback.

Handling “Good” Reviews

For each feedback issue labeled “satisfaction::good”:

1. read through the feedback and check for anything actionable - sometimes customers provide really good actionable feedback in positive reviews
2. consider sharing the feedback in the Support Week in Review document (see below)
3. if no further action is needed, /close the Feedback Issue.

Note: Support Engineers can see the Feedback comments on their tickets, and get notified by Zendesk when a Feedback comment is added. You do not need to notify them or their managers.

Note: After 7 days of inactivity, the GitLab Support Bot closes “satisfaction::good” issues.

Sharing positive feedback in Support Week in Review (SWIR)

To share positive feedback in the Support Week in Review, each week an issue will be created in the Support Week In Review Tracker and tagged with ~"SWIR::SSAT". If you’re the SSAT Reviewing manager it should be assigned to you automatically, but you can also search for the label.

Anything you add to the body of this issue will be included in the SWIR digest for the week. No further action is required other than having the body of the issue updated. Please do be aware of some considerations in formatting feedback in the SWIR issue.

Due Date: the cut off for content for the SWIR is close of business on your Thursday. Plan to add any ticket feedback before this time. Anything you want to add after this time needs to be added to the content for the following week, to ensure it is included in the audio recording.

When selecting feedback to share, you don’t need to share every piece of positive feedback. Consider the following when choosing what to share:

1. Comments that stand out to you - the ones that you dwell on and smile as you read them
2. The customer has taken the time to name the individual(s) they appreciated
3. The customer has described why they were satisfied or how our support improved their day (we get some great stories!)
4. If there are general sentiments or themes, feel free to congratulate the whole team. For example, if we were praised for our overall approach to support, speed, clarity, etc.
5. Is the feedback definitely positive? Sometimes comments in positive feedback can be neutral or even negative. For example “I would have liked a quicker response”, or “I was satisfied” are valuable to us, but they don’t really encourage the team when shared in the SWIR.

Formatting feedback in SWIR issue

When adding the comment to the SSAT issue in the support-week-in-review tracker, feel free to use markdown formatting. If you wish to use headers (#) please

• use H4 (####) or lower
• be aware that headers will be included in the table of contents in the issue

Generally, include the ticket number with a link to the ticket, the comment from the customer, and where applicable @ mention the person (or people) who primarily worked the ticket.

Automatically collecting positive feedback

The populate_ssat job in the support-week-in-review tracker will automatically collect open issues labeled with ~"satisfaction::good" and append a nicely formatted version to the open SSAT issue.

To run this job:

1. [Run a manual pipeline] (https://docs.gitlab.com/ee/ci/pipelines/#run-a-pipeline-manually) and run the populate_ssat job.

You can safely re-run this task as many times as you’d like as it will append to the issue.

Handling “Bad” Reviews

For feedback issues labeled “satisfaction::bad”, click through to the ticket, and review it to determine the following:

1. Why the feedback was given
2. If further action needs to be taken
3. If the customer should be contacted to discuss the feedback given
4. If the feedback should be discussed with a CSM

You should document your finding and any follow-up actions taken in the issue. You may use the following template to add a comment to the feedback issue (NOT the ticket!):

1
2
3
4

* **Summary of ticket/feedback:**
* **Action to be taken:**
* **Contact customer to discuss feedback? (Y/N)**
* **Make the CSM aware of this feedback? (Y/N)**

The above text will be automatically added as a comment to “bad” reviews. You might also consider adding the above snippet to a comment template for quick use.

If no action needs to be taken, and the customer does not need to be contacted to discuss the ticket, /close the Feedback Issue.

When you see “bad” feedback on an apparently successful ticket

Sometimes, when you review the ticket, you will see that the ticket seems to have been resolved successfully. The customer may have even said something like “thank you, you can close the ticket”. We strongly encourage you to contact the customer when this happens. If the ticket is still in Solved (but not Closed) status, the customer can change their rating, if they did not mean to mark it “bad”.

Understanding the customer’s reason

Many customers do not provide a reason for the “bad” review they submit. Even if a reason is provided, it may not be clear why the customer was dissatisfied. The reviewing manager should carefully review the ticket and seek to understand why a bad review was given. If necessary, contact the customer to learn more.

Once the reason behind the “bad” review is understood, apply the feedback scoped label that best describes the situation:

Note: For the full list of feedback labels and their descriptions, visit the labels page in the support-feedback project.

This is important to help Support understand and respond to Support Satisfaction trends.

If there is action to be taken

Determine the course of action and tag appropriate people. Note that indirect feedback received from a customer/prospect will typically have the next action chosen for us.

Examples of possible actions:

• Contact the customer (see below)
• Create a new Issue to discuss the feedback in support-team-meta (cross-link the Feedback Issue as related)
• Tag the manager of the person or people who participated in the ticket to discuss in a 1:1
• Tag a product group for awareness (some negative feedback is product related)

If further discussion is warranted, leave the Feedback Issue open. Otherwise, /close it.

If the customer should be contacted

When the customer requests contact via a mid ticket feedback request:

1. The On call manager is responsible for the follow up.

If you believe the customer should be contacted following completion of a closed ticket survey:

1. Determine the best way to reach out. Some options are:
   1. Sending the customer an email from your GitLab email address. This should be the appropriate option in the majority of cases.
   2. Responding directly on the Zendesk ticket. This is appropriate if you determine that the ticket was not adequately resolved and work should be continued.
      • If reopening a ticket, make sure that you assign and brief a support engineer (typically the existing assignee) on the next actions to be taken.
      • Note that reopening a closed or solved ticket affects measurements of reopen rate and time to resolution.
2. When reaching out to the customer, make sure you do the following:
   1. introduce yourself, describing who you are and your role at GitLab
   2. note the specifics of the situation, including ticket ID - you can include a link using the format https://support.gitlab.com/hc/requests/<ticket number>
   3. restate and validate the customer’s comments
   4. offer any apologies or clarifications required, including links to relevant documentation
   5. offer your Calendly link to schedule a video call
3. Update the Feedback Issue as follows:
   1. Add the text of your email as a comment in the Feedback Issue.
   2. Apply the label ~ssat-manager-contacted-customer.
   3. /close the Feedback Issue; followup continues via email.
   4. After closing the Issue, if there are any additional actions that arise from your interaction with the customer, go back and note them in the Feedback Issue.

View page source - Edit this page - please contribute.