# What is Support Pods? Support Pods is an initiative to introduce subject-specific ticket views and ways that support engineers can work them in Zendesk. The initial implementation will be carried out in APAC, with an eye on designing a solution that can scale globally while retaining sufficient flexibility to be adapted to account for region-specific challenges. Once teething problems are sorted out in APAC, Support Pods will be rolled out progressively in EMEA and AMER with the help and advice of support engineers and managers who were involved in the initial APAC execution. Support Pods was formerly known as Areas of Focus. # Why the name change to Support Pods? Why not just call it Areas of Focus? We want to clearly differentiate the current initiative, which is about how we can introduce subject-specific views and ways of working them within Zendesk, from other uses and understandings of the term "Areas of Focus". As a term, Areas of Focus can no longer be considered [MECEFU](https://about.gitlab.com/handbook/communication/#mecefu-terms). Over time, it has picked up many meanings. Some examples: 1. There are [Support Engineer Areas of Focus](https://about.gitlab.com/handbook/support/support-engineer-responsibilities.html#support-engineer-areas-of-focus), which comprises SaaS, Self-Managed, Licence and Renewals, Management, Operations and US Federal. This can also be viewed at the [Support Team info site](https://gitlab-com.gitlab.io/support/team/areas-of-focus.html). 1. Support team members have started to refer to [knowledge areas](https://gitlab-com.gitlab.io/support/team/skills-by-person.html) informally as areas of focus. 1. It can also refer to [a group of Support Engineers](https://www.youtube.com/watch?v=wqiCDCKEdVo) (internal only) who are knowledgeable resources for one or more specific customer. Due to this long and legitimate heritage of use and the inertia behind the phrase, it would be too much effort to retain the use of "Areas of Focus" for this initiative and get Support team members to stop using the term for other legitimate purposes. Instead, we will avoid this problem and use a new name, Support Pods, for the initiative. # How did Support Pods originate? 1. Support Pods initially started as a [Learning Areas proposal](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/2164#note_297433690) by Tom Atkins (`@tatkins`). 1. This evolved to the more familiar proposal for [Areas of Focus to improve ticket handling](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/2382). 1. This led to the creation of the [Areas of Focus Workgroup](https://docs.google.com/document/d/1TLub48gTRd1qD6BaqnFObY0FhwcCeQ7xU6k68XbLHoc/edit#heading=h.rahhbpybhwdd) which determined initial findings around what each Pod (Area) would be and how the views might work in Zendesk. 1. This all culminated in an [Areas of Focus implementation proposal](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3389) by Jason Colyer (`@jcolyer`). 1. Finally, it was decided to begin implementation in APAC as APAC can start from a cleaner slate as it does not have Support Response Crew implemented, and the smaller team size makes it more conducive for quick feedback and iteration. # Will Support Pods be an entirely new way of working tickets? No. Support Pods will introduce an additional layer that builds upon the foundation of the global [Working on Tickets workflow](https://about.gitlab.com/handbook/support/workflows/working-on-tickets.html) and its operating principles will stay consistent with that workflow. In particular, we will be retaining the emphasis on ticket assignment and avoiding a return to both the hot queue model and the casual "drive-by" collaboration that it encouraged. # What does the implementation plan for Support Pods look like? The current high-level implementation plan can be found in [this Google Doc](https://docs.google.com/document/d/195Fo-zAXeLlrbT2ComLHcSb0oQgxS2PRJC7Kfci6FvE/edit#) (internal only). This is where we got started, and will eventually be deprecated as we move fully into GitLab.com epics and issues. You are welcome to leave comments on the document. More immediately, the following will be taking place: * Expectations gathering and understanding. Identifying blockers. (Underway, target completion 2021-07-30) * [Cross-platform training](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3548) for selected Support Engineers in APAC. (Underway, thanks Cynthia Ng (`@cynthia`) for putting this together and making it happen!) * Initial Pilot pod. (currently planning, target implementation 2021-08-02) * Creation of user personas for planning purposes. (not yet started)