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:
If you'd like to subscribe to SSATs submitted by customers from a certain
territory, you can subscribe to the appropriate
label through the Feedback project labels page.
These labels are applied based on organization information synced to Zendesk from SFDC.
|EMEA||Europe, Middle East and Africa|
|LATAM||Latin America (includes all of Central & South America)|
|NCSA||North, Central, South America (legacy region being phased out)|
The single source of truth for these definitions can be found in the Go to Market Glossary handbook page.
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.
Currently, the following methods create feedback issues for review:
SSAT::Contactlabel. In the Description or in a Comment, specify that manager contact was requested.
At the end of your rotation:
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.
Our Feedback and Complaints handbook page provides general guidance on assessing and responding to feedback.
For each feedback issue labeled "satisfaction::good":
/closethe 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.
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
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:
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 (
####) or lower
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.
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:
You can safely re-run this task as many times as you'd like as it will append to the issue.
For feedback issues labeled "satisfaction::bad", click through to the ticket, and review it to determine the following:
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!):
* **Summary of ticket/feedback:** * **Action to be taken:** * **Contact customer to discuss feedback? (Y/N)** * **Make the CSM aware of this feedback? (Y/N)**
If no action needs to be taken, and the customer does not need to be contacted to discuss the ticket,
/close the Feedback Issue.
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".
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
that best describes the situation:
||The customer resolved the ticket|
||Encountered Documentation problem; new Issue and/or MR filed|
||Documentation unhelpful to customer and/or Support Engineer|
||Known issue with Issue already created|
||Encountered Product problem; new Issue and/or MR filed|
||Customer did not supply enough information for investigation|
||Support Engineer did not provide adequate information to customer|
||Problem internal to GitLab but not directly by Support|
||Customer found support process confusing or unclear|
||Support Engineer did not follow documented support process|
||Problem does not have an existing Support process|
||Problem caused by Zendesk-Salesforce integration (includes delays due to needs-org, incorrect contact info/matching in SFDC, unable to validate subscription)|
||Support Engineer responses unhelpful or customer expectations mishandled|
||Support Engineer lacks skills or permissions to troubleshoot or resolve problem|
||Customer lacks skills or permissions to troubleshoot or resolve problem|
||Support unable to fulfil the request according to the customer's expectations|
||The ticket time to resolve was extended due to troubleshooting requirements of the issue|
||The ticket time to resolve was extended due to the technical complexity of the issue|
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.
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:
support-team-meta(cross-link the Feedback Issue as related)
If further discussion is warranted, leave the Feedback Issue open. Otherwise,
When the customer requests contact via a mid ticket feedback request:
If you believe the customer should be contacted following completion of a closed ticket survey:
/closethe Feedback Issue; followup continues via email.