Remove references to SGGs in workflow pages for support

   1. Let customer know in the ticket description that follow-up work will continue in this ticket.

   1. Add an internal comment linking to the (closed) emergency ticket.

   1. Add an internal comment in the emergency ticket, linking to this ticket as the follow-up ticket.

   1. The new ticket will now be picked up by the round robin automation and assigned to an SGG, like any other ticket. Optionally, an engineer involved in the emergency can take ownership of the ticket instead.

   1. Optionally, an engineer involved in the emergency can take ownership of the ticket.

Why do follow up work in another ticket?

[escalating to unblock](/handbook/values/#escalate-to-unblock)

is an operating principle of Results.

#### Ask in your SGG

Ask in [your group's Slack channel](/handbook/support/support-global-groups/#slack) for help. You might get all the help you

   need in responses right there, or you might open up the group's Zoom room

   for an impromptu pairing session to work on the ticket. And remember:

   1. Be sure to provide a link to the ticket

   1. Be specific about the help you need

      - For example: "Kubernetes Runner help needed: user is running into X

        error, logs are saying Y, and we've tried Z. What else could it be?"

#### Bring the ticket before a group of peers

Other Support Engineers are a great resource to help out with tickets. To get help from peers, you can try one or more of the following:

    - Senior Support Office Hours (varying times)

1. Ask for help in one of the broader

   [Support Slack channels](/handbook/support/#slack).

1. Initiate a [Branch Out session](/handbook/support/support-global-groups/branch-out-sessions)

   - This is like a crush session, with the specific intention of helping 1 or 2

     groups with FRTs

#### Expand to Support Pods and other subject matter experts

the Support Handbook, such as:

- [Working on Tickets](../working-on-tickets)

- [Support Global Groups FAQ](/handbook/support/support-global-groups/sgg-faq)

- [Support Engineer Responsibilities](/handbook/support//support-engineer-responsibilities)

### Using the OOO Ticket Summary macro

As part of this workflow, the Support Engineer going on leave will leave notes on currently Open, Pending and On-Hold tickets for their group with a macro. This macro will provide a summary of the ticket, add the Support Engineer to the ticket's CC list (in case someone else in the SGG group takes over assignment of the ticket), and adds the `ooo_summary` tag to the ticket.

As part of this workflow, the Support Engineer going on leave will leave notes on currently Open, Pending and On-Hold tickets with a macro. This macro will provide a summary of the ticket, add the Support Engineer to the ticket's CC list, and adds the `ooo_summary` tag to the ticket.

It is recommended to follow this workflow if 3 days or more of PTO are planned.

#### Workflow

Go to the [My Assigned Tickets](https://gitlab.zendesk.com/agent/filters/360062369834) view in Zendesk. For each ticket you wish to summarize for your group because you anticipate on-going work will be required, do the following:

Go to the [My Assigned Tickets](https://gitlab.zendesk.com/agent/filters/360062369834) view in Zendesk. For each ticket you wish to summarize because you anticipate on-going work will be required, do the following:

1. Use the [OOO Ticket Summary](https://gitlab.com/search?search=360080271299&group_id=2573624&project_id=17008590&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar) macro.

1. Fill in the sections of the internal note with details for your SGG group. It is important that you summarize:

1. Fill in the sections of the internal note with details for your peers. It is important that you summarize:

   1. What is the problem to be solved?

   1. What information has been collected?

   1. What actions have been taken?

   1. What progress has been made?

   1. What are the potential next steps? Alternatively, clarify if you are uncertain what the next steps are.

Feel free to also ask group members if they can pickup tickets in [other forms of communication](/handbook/communication/#multimodal-communication), such as Slack, but Zendesk should remain as the single source of truth for tickets that need attention from other group members.

Feel free to also ask regional peers if they can pickup tickets in [other forms of communication](/handbook/communication/#multimodal-communication), such as Slack, but Zendesk should remain as the single source of truth for tickets that need attention from other team members.

#### Finding your tickets upon your return

would be suitable candidates for reassigment.

This has the advantage for faciliating collaboration that would otherwise clutter up the other main Support Slack channels. It also ensures that tickets

are not left in limbo as other Support Engineers are actively being pinged as part of the workflow. When pinging other Support Engineers for reassignment

you are not limited to your Support Global Group, so please feel free to ping globally.

are not left in limbo as other Support Engineers are actively being pinged as part of the workflow. 

It is recommended to follow this workflow if 5 days or more of PTO are planned, and you have more than 10 tickets to handover.

    - If there is missing, incomplete, or erroneous information the ticket assignee should highlight the deficiencies and provide any insight that may be helpful to correcting them to the user.

    - The ticket assignee may opt to use the `Upgrade Request Missing Info` macro in Zendesk to request for missing information.

1. (Optional) When the required information has been collected, the assignee can reach out to any of the folks with an `Upgrade` or `Upgrade Assistance` focus on the [Skills by Subject](https://gitlab-support-readiness.gitlab.io/support-team/skills-by-subject.html) page to pair or offer insight asynchronously.

Based on the region, consult one of the following trackers to determine who to ask.

    - [AMER Upgrade Assistance Request Tracker](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3789)

    - [EMEA Upgrade Assistance Request Tracker](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3562) (deprecated, Check within your SGG)

    - [APAC Upgrade Assistance Request Tracker](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3399) (deprecated, Check within your SGG)

1. If the customer requests to have the optional 30-minute call for a final review, send a personal one time use Calendly link for a 30 minute meeting at least 2-3 days in advance of when the customer plans to upgrade their GitLab instance.

    - If the reviewing engineer needs to hand off the ticket, they **must** sync up with the engineer who will be performing the final review to ensure proper handoff.

1. Once the user has scheduled the upgrade, the ticket assignee should put the ticket in an `on-hold` state until the customer has confirmed that the upgrade has been successfully completed.