Skip to content
Snippets Groups Projects
Commit 6e2b828a authored by Lyle Kozloff's avatar Lyle Kozloff :taco: Committed by Dylan Tragjasi
Browse files

Updates references to SSAT reviewing manager

parent 95b57bcb
No related branches found
No related tags found
1 merge request!6832Updates references to SSAT reviewing manager
......@@ -29,7 +29,7 @@ Our primary responsibility in the Support Leadership team is to ensure high qual
| Help support engineers to resolve tickets accurately and efficiently | Understand GitLab [Support Service Levels](https://about.gitlab.com/support/#gitlab-support-service-levels) and [KPIs](/handbook/support/#how-we-measure-our-performance) |
| | Know how we use Zendesk, [Slack](#working-in-slack), and GitLab for ticket management |
| | Serve as [Support Manager On-Call](/handbook/support/on-call/) for Customer Emergencies and Escalations |
| | Serve as [SSAT Reviewing Manager](/handbook/support/workflows/how-to-respond-to-feedback) for handling Customer Feedback |
| | Monitor and [respond to feedback](/handbook/support/workflows/how-to-respond-to-feedback) your Support Engineers receive |
| | Know how to use Zendesk Explore to monitor KPIs |
| | Work with GitLab Sales, Pricing, Product, and other teams when company initiatives change Support requirements |
| Help Support Engineers to manage tickets, manage customer expectations, and communicate well | Coach SEs on communication techniques |
......
......@@ -112,13 +112,6 @@ deleted. You might need to edit it first to remove rules and persons first.
- Escalates after 5 min
- If no one acknowledges, repeat this policy `5` times
### Customer Support SSAT
- [Escalation policy link](https://gitlab.pagerduty.com/escalation_policies#P0DPFUO)
- Level 1
- Notify the following users or schedules
- SSAT Reviewing Manager
### Incident Management - CMOC Rotation
- [Escalation policy link](https://gitlab.pagerduty.com/escalation_policies#PNH1Z1L)
......
......@@ -404,17 +404,6 @@ This rotation is used for Support Directors.
- Members
- Lee Matos
### SSAT Reviewing Manager
This rotation is used for assigning Support Managers SSAT reviewing duties.
- [Schedule link](https://gitlab.pagerduty.com/schedules#P9UIIDY)
- Timezone: UTC
- Layer 1
- Rotation type: weekly
- Handoff time: Tuesday 0000
- Hours: Not restricted to specific times
### Shadow - Customer Emergenices
- [Schedule link](https://gitlab.pagerduty.com/schedules#PLNQAAB)
......
......@@ -189,7 +189,7 @@ It is recommended that you complete the modules in the order listed, unless an i
| [ZenDesk Basics](https://gitlab.com/gitlab-com/support/support-training/-/blob/main/.gitlab/issue_templates/Zendesk-Basics.md) | 1 Day | Utilize ZenDesk to perform ticket management |
| [Triaging Tickets](https://gitlab.com/gitlab-com/support/support-training/issues/new?issuable_template=Triaging%20Tickets) | 4 Days | Understand how to triage tickets including the triage view in Zendesk |
| [Customer Emergencies](https://gitlab.com/gitlab-com/support/support-training/-/blob/main/.gitlab/issue_templates/Customer-Emergencies.md) | 1 Week | Understand the responsibilities of being on-call for Customer Emergencies |
| [SSAT Reviewing Manager](https://gitlab.com/gitlab-com/support/support-training/-/blob/main/.gitlab/issue_templates/SSAT-Reviewing-Manager.md) | 1 day | Understand how to handle Support Satisfaction feedback results |
| [SSAT Reviewing for Managers](https://gitlab.com/gitlab-com/support/support-training/-/blob/main/.gitlab/issue_templates/SSAT%20Reviewing%20Manager.md) | 1 day | Understand how to handle Support Satisfaction feedback results |
When this pathway is complete, let your manager know that you are ready to join the appropriate on-call rotations. (Your Support Manager Basics issue contains the instructions for this step.)
......
......@@ -43,10 +43,8 @@ Sometimes a customer may provide feedback via the ticket directly, or they may p
this feedback is captured, please create an issue in the Customer Feedback
project using the
[Indirect Feedback template](https://gitlab.com/gitlab-com/support/feedback/-/issues/new?issuable_template=Indirect%20Feedback)
and copy the feedback into the new issue. The
[SSAT Reviewing Manager](https://gitlab.pagerduty.com/schedules#P9UIIDY)
will be assigned to the issue and they will review the feedback and take
appropriate action.
and copy the feedback into the new issue. Assign the issue to the manager of the assignee
and they will review the feedback and take appropriate action.
In the meantime, you should continue to assist the customer with their queries
and address their feedback if appropriate. If you are unsure on how to proceed,
......
......@@ -59,7 +59,6 @@ Once you have the compiled audio:
#### Prepare SWIR for the next week
1. Run the `close_week_and_create_new_milestone` pipeline
1. Check [pagerduty for the SSAT Reviewing Manager(https://gitlab.pagerduty.com/schedules#P9UIIDY) to find the incoming SSAT manager (the one starting on the current Thursday) and reassign the new Positive SSAT issue to them.
1. You're done!
#### Notes on SSAT content
......@@ -71,7 +70,7 @@ The purpose of including SSAT content in the Support Week in Review is two-fold:
We do not include every SSAT review every week, both for brevity and because not every SSAT review fulfills the purposes above.
Depending on what the [SSAT Reviewing Manager](/handbook/support/workflows/how-to-respond-to-feedback/#who-is-responsible-for-reviewing-support-satisfaction-feedback) has populated the weekly SSAT issue with as a SWIR host you may need to edit the content.
Depending on what [managers reviewing SSAT](/handbook/support/workflows/how-to-respond-to-feedback/#who-is-responsible-for-reviewing-support-satisfaction-feedback) have populated the weekly SSAT issue with as a SWIR host you may need to add additional content.
With the above purposes in mind, SSAT comments in the Support Week in Review should:
......
......@@ -8,7 +8,7 @@ description: Discusses the Support Team's Support Satisfaction review process, a
To understand the factors contributing to [Support Satisfaction](/handbook/support/performance-indicators/#support-satisfaction-ssat),
we review feedback received for support tickets. Issues are automatically
created in the [Feedback issue tracker](https://gitlab.com/gitlab-com/support/feedback/-/issues)
(internal only) for all Support Satisfaction feedback received.
(internal only) for all Support Satisfaction feedback received and assigned to the manager of the person who assigned to the ticket.
**NOTE:** The following categories of tickets do **not** receive surveys:
......@@ -42,10 +42,18 @@ The single source of truth for these definitions can be found in the [Go to Mark
## Who is responsible for reviewing Support Satisfaction feedback
The [SSAT Reviewing Manager PagerDuty schedule](https://gitlab.pagerduty.com/schedules#P9UIIDY) is the [SSOT](/handbook/values/#single-source-of-truth) for who is on-call. The [Support Week in Review document](https://docs.google.com/document/d/1eyMzbzImSKNFMpmu33C6imvC1iWEWHREJqaD6mkVDNg/edit) identifies the current **SSAT Reviewing Manager**, with a link to the PagerDuty schedule.
Each Support Engineering Manager is responsible for reviewing and actioning feedback for their reports. Issues will be directly assigned to managers, and should be addressed within 7 days.
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](/handbook/support/readiness/operations/docs/zendesk/ssat/) to the SSAT Reviewing Manager automatically. The manager receives email notification from GitLab and a To-Do item.
This SSAT data will be reviewed by Senior Leaders and presented in Monthly region reviews.
### SSAT
The manager of the person to whom a ticket is assigned is responsible for reviewing customer feedback on that ticket.Feedback issues
[are assigned](/handbook/support/readiness/operations/docs/zendesk/ssat/) to the managers automatically. The manager receives email notification from GitLab and a To-Do item.
### Mid-ticket feedback
[Support Managers On-call](/handbook/support/workflows/support_manager-on-call) are responsible for initial triage of mid-ticket feedback received during their shift. Notifications are posted in the `#support_ticket-attention-requests` channel.
### Sources of feedback
......@@ -53,14 +61,14 @@ Currently, the following methods create feedback issues for review:
1. [Automatic email survey](/handbook/support/readiness/operations/docs/zendesk/ssat/) -- sent to customers when tickets are closed.
1. 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](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/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**.
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 **Support Manager On-call** and the manager of the Support Engineer assigned to the ticket.
1. 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**](/handbook/support/workflows/support_manager-on-call#expectations-for-support-manager-on-call) should promptly follow the guidance in [Handling mid ticket feedback requesting manager contact during business hours](/handbook/support/workflows/support_manager-on-call#handling-mid-ticket-feedback-requesting-manager-contact-during-business-hours).
1. GitLab team members (such as CSMs and Sales team) can open an [Indirect Feedback](https://gitlab.com/gitlab-com/support/feedback/-/issues/new?issuable_template=Indirect+Feedback) issue with details they received from the customer.
1. 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:
Within 7 days, for each of your Support Engineers who receive feedback:
1. You should have performed the triage work described in the handling
["Good"](#handling-good-reviews) and ["Bad"](#handling-bad-reviews) sections
......@@ -94,13 +102,18 @@ For each feedback issue labeled "satisfaction::good":
### 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](https://gitlab.com/gitlab-com/support/readiness/support-week-in-review/-/issues) 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](https://gitlab.com/gitlab-com/support/readiness/support-week-in-review/-/issues?label_name%5B%5D=SWIR%3A%3ASSAT).
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](#formatting-feedback-in-swir-issue).
You only need update the SWIR issue for feedback you want to be sure makes it in. SWIR hosts will select some positive feedback each week to share with the team.
**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:
#### Guidance for SWIR Hosts
Each week, take note of any positive feedback included by managers in the `~SWIR::SSAT` issue and be sure to include it.
When selecting additional 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
1. The customer has taken the time to name the individual(s) they appreciated
......@@ -127,7 +140,7 @@ 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.
### Handling "Bad" Reviews
## Handling "Bad" Reviews
For feedback issues labeled "satisfaction::bad", click through to the ticket, and review it to determine the following:
......@@ -151,11 +164,11 @@ The above text will be automatically added as a comment to "bad" reviews. You mi
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
### 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](#if-the-customer-should-be-contacted) 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
### 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
......@@ -193,7 +206,7 @@ that best describes the situation:
This is important to help Support understand and respond to Support Satisfaction
trends.
#### If there is action to be taken
### If there is action to be taken
Determine the course of action and tag appropriate people. Note that [indirect feedback](/handbook/support/internal-support/#regarding-gitlab-support-plans-and-namespaces) received from a customer/prospect will typically have the next action chosen for us.
......@@ -206,7 +219,7 @@ Examples of possible actions:
If further discussion is warranted, leave the Feedback Issue open. Otherwise, `/close` it.
#### If the customer should be contacted
### If the customer should be contacted
When the customer requests contact via a mid ticket feedback request:
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment