## Introduction This Epic is about a strategic and structural team change, and how we need to evolve the support experience that we deliver to our customers. It begins with our plan to disband SGGs by 2024-08-01 and at the same time to return to using a single global queue. It won’t be the hot queue of old, though, as you’ll be able to see in the details laid out below. This new design aims to fix current problems without reintroducing past problems, such as overwhelmingly large queues and unassigned tickets. We will need to iterate from now until August to make the transition as smooth as possible. Everyone will have time and encouragement to contribute. **Please read the entire description before commenting.** ## Story We’ve enjoyed many positive effects of the SGG system, and we’ve also experienced some of its shortcomings. The SGG system was developed when our team grew faster than it recently has, and many of us have experienced the resulting inefficiencies such as PTO coverage and ticket transfers sometimes being a struggle. It has become clear that the SGG system is no longer meeting the team's needs. So it’s time for strategic changes. Our goal is to improve our operations, increase our efficiency and deliver even higher quality support than we already do. Let’s be clear: all change causes some amount of stress. We as leaders - managers, staff SEs, directors, and I - recognize that fact and don’t decide on changes like this lightly. We believe that the changes we have in mind will serve Support and all of us very well, and will set the stage for future improvements. Our Support Senior Leaders have created a vision for Support along with high level goals and a set of operating principles. As our [Handbook](https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/#dris-and-our-values) notes, this “might seem to impair our ability to collaborate effectively at first glance, but that’s misleading.” For efficiency and alignment, the Support Senior Leaders will make **all** final decisions, while also “trust\[ing\] in the experience and judgment of their teams” to work out the details. Only collaborating in this way can we achieve our goals and turn our shared vision into reality. ## Vision 1. We deliver a seamless experience for our customers by helping them through every step of their support journey 2. All of Support is simpler in terms of processes, policies and workflows with a guiding principle of doing the right thing for the customer at the right time 3. SGGs are disbanded by 2024-08-01, at which time all tickets route to a single, global view/queue for all areas of focus 4. Tickets are aligned to an accountable region 5. 100% FRT SLA achievement during each region’s coverage hours, with a stretch goal of greater than 70% of tickets replied to within half of each region’s FRT SLA clock 6. Support Pods continue and have enhanced purpose and participation that lead toward a skills-based or use-case-based future ## Goals | Category | Goal | |----------|------| | Our People | Improve the SE experience by decreasing per SE active assigned tickets to a stable level (discovery needed as to what a “stable level” would look like) | | | Improve: ticket transfer/handover, ticket coordination, ticket management | | | Create more time for SE training | | | Make it easy to understand manager responsibilities and paths for influencing results. Make it clear how SEs are empowered to achieve results and have agency to make decisions | | | Prevent unhealthy competition within GitLab | | | Continue to be highly collaborative | | | Enhance our capacity to efficiently address complex technical requests by implementing [self-service](https://handbook.gitlab.com/handbook/values/#self-service-and-self-learning) resources, including a robust knowledge base, to deflect ([1](https://handbook.gitlab.com/handbook/support/workflows/how-to-respond-to-tickets/#improving-the-customer-experience-through-ticket-deflection) , [2](https://handbook.gitlab.com/handbook/support/workflows/how-to-respond-to-tickets/#improving-the-customer-experience-through-ticket-deflection)) and manage tickets effectively. | | Our People AND Customers | Value customers and team members over processes; view processes as a guide rather than as a rule. | | Customers | Meet our customers’ increasing needs and expectations better by enhancing the speed and effectiveness of our first (FRT) and subsequent (NRT) ticket responses. | | | Improve ticket closure rate (Mean Time to Resolution, or MTTR) | | | Replace CSAT with Customer Effort Score (CES), establish a baseline and improve on it | | | Make the best and most appropriate use of cross-department collaboration in service of customers and team members | | | Let every interaction be filled with empathy and genuine care in order to build trust and strong relationships with our customers. | | Finance and Business | Be cost efficient with hiring | | | [Optimize at the right level](https://handbook.gitlab.com/handbook/values/#efficiency-for-the-right-group) for global results | ## Initial Foundational Changes 1. Team structure may change as we incorporate new roles such as ASEs and CSRs into Support. The structure may differ between regions 2. All types of escalated events - STARs, Support-involved Customer Escalations, gitlab.com and Dedicated incidents, security incidents, emergencies - have a home region to ensure consistent communication, leadership and direction, even if work is done in more than one region 3. Remove the `All Regions` option on ticket forms and make the `Preferred Region` field mandatory in order to reduce complexity for customers and for us - This will require approval from GitLab Legal 4. Managers within each region will collaborate to ensure fair ticket workload distribution 5. All SEs will work primarily from a single view, which will contain all unassigned tickets presented in decreasing order of weight ## Global Operating Principles 1. Deliver the same initial experience to all customers regardless of when during business hours they open a ticket: - Take tickets during your working hours as they come in - Assign and then respond to each new ticket regardless of which region was specified - At the end of your day, transfer each new out-of-region ticket you took that day unless the customer has explicitly agreed to continue working with you 2. Managers are responsible for tracking the health of ticket management within their region 3. Basic ticket management should be covered by any new way forward. This includes: - Evolving a method to make it easy to determine the next ticket to work on (assign) - A ticket transfer must be initiated before the target region’s day starts and must be completed (ticket assigned) within 4 hours of the target region’s day start (the ticket transfer window) - Ensuring sufficient coverage throughout the day to meet the SLA achievement goal, including consideration for: - Having sufficient coverage during the ticket transfer window - How new ticket volume will be fairly distributed - Honoring each customer’s region choice, or questioning it within 8 business hours of ticket creation - Supporting the use of “clarifying” and “starting to troubleshoot” responses - Tracking and addressing idle tickets appropriately - Ensuring customer awareness of, and agreement on, ticket update timing - Using customer calls as a routine (not exception) tool for troubleshooting, clarifying, guiding and rapport building - Elevating - seeking help from Development or others in Support - based on agreed upon criteria such as time, skill level, customer expectations - Attempting to reach agreement with the customer on ticket closure by summarizing the ticket progress and resolution - (Future) Setting a ticket to an appropriate, non-closed status while its linked product issue remains unresolved ## More Detail While I, Johnny, am posting this epic, The Support Managers and Staff Support Engineers built this epic based on this [Final Guidance: Support Team Structure & Routing](https://docs.google.com/document/d/1nf6gxdWaTL2A0rbBLvsIfLcEcFkHqr7p1JrYRi9983k/edit#heading=h.nmbodan6lyah) document, which the Senior Support Leaders developed and shared with managers. If you want to learn more about the history of the formulation of this plan, we invite you to start by reading that document. Please contribute and ask questions in our [AMA document](https://docs.google.com/document/d/1FSU4ojc4VobnY4b9Nna1340kwFjF7j4i6q5jajaZX0U/edit?usp=sharing), which will be addressed in each upcoming regional team meeting. There will be a feedback issue for questions arising after the AMA sessions , and feel free to bring questions and concerns directly to your manager. ## Potential Child List <table> <tr> <th>Description</th> <th>Epic/Issue</th> </tr> <tr> <td>How can we retain the safety and supportiveness of the small group setting that SGGs have provided? (crush sessions, queue management, etc.)</td> <td> [☕️ What things about SGGs should we retain?](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6221) (gitlab-com/support/support-team-meta#6221) </td> </tr> <tr> <td>How can we retain the safety and responsiveness of the SGG views when an SE needs help on a ticket?</td> <td> </td> </tr> <tr> <td>How can we prevent multiplication of effort when two or more SEs start looking at the same new ticket?</td> <td> </td> </tr> <tr> <td>How do we want to handle ticket coverage for an absent SE?</td> <td> </td> </tr> <tr> <td>What process will be most welcome and effective in completing ticket transfers?</td> <td> </td> </tr> <tr> <td>What process will be most welcome and effective in finding an SE to take a STARred ticket?</td> <td> </td> </tr> <tr> <td>How can we prevent the self-managed and gitlab.com support channels from becoming overly busy, as they were pre-SGGs?</td> <td> https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6156+ </td> </tr> <tr> <td> The daily standup bot in [#spt_gg_forest](https://gitlab.slack.com/archives/C03LL7Z2291) is slated to go away with SGGs.  [Issue thread.](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/5939#note_1950477264 "💡 Using #spt_gg_forest for daily stand-up posts for Staff SEs, too") The bot also reports daily (per region) on * managers with PTO * which engineers are on call for CMOC and emergencies * the on call manager and SSAT manager The channel also gets reports on very breached tickets ([example](https://gitlab.slack.com/archives/C03LL7Z2291/p1718227885615129)). Should we modify/replace the bot, and if so what do we want it to do? </td> <td> https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6259+ </td> </tr> <tr> <td>Should we modify/replace the Slack Breach Bot, and if so how?</td> <td> https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6157+ </td> </tr> </table> ## Epics and Issues Organization In a conversation with me (Mike Dunninger) on 2024-06-14, Lyle showed me the issue board that Support Ops uses in planning its various projects. I liked what I saw and decided to bring some of that structure over to this epic in the hope of helping us to keep track of all the ideas and questions that people bring forth and to organize them in a way that will allow us to work on them in order of importance. Please iterate on the structure I've created to ensure it is clear, easy and valuable: ### Labels | Label | Description and Usage | |-------|-----------------------| | ~"Support Evolution" | For this epic and all of its descendants | | ~"Support:APAC" | For any item that is relevant to APAC | | ~"Support:EMEA" | For any item that is relevant to EMEA | | ~"Support:AMER" | For any item that is relevant to AMER | | ~"Support Evolution::NOW" | For all items we should be addressing immediately | | ~"Support Evolution::NEXT" | For all items we should address after the `NOW` items | | ~"Support Evolution::LATER" | For all items we can address at a later time | * For items that apply to 2 or all regions, use the appropriate combination of the region labels ### Issue Boards There is one issue board per region: * each shows all issues with both ~"Support Evolution" and the label for the board's region * each has lists for ~"Support Evolution::NOW" , ~"Support Evolution::NEXT" and ~"Support Evolution::LATER" The boards are: * [FY25 Support Evolution - APAC](https://gitlab.com/groups/gitlab-com/support/-/boards/7610252) * [FY25 Support Evolution - EMEA](https://gitlab.com/groups/gitlab-com/support/-/boards/7610253) * [FY25 Support Evolution - AMER](https://gitlab.com/groups/gitlab-com/support/-/boards/7610238)