The majority of the response channels' mentions are routed to Zendesk via automation. Generally through Zapier or a native Zendesk integration.
Each mention is then converted into a ticket and filtered into a View, ordered by channel priority. As part of their daily workflow, Community Advocates process each one of these views and manage the ticket lifecycle.
A typical ticket lifecycle is as follows:
After a discussion with the GitLab Support team, it was concluded that for the specific Advocate workflows and metrics it would be best to keep the Community Relations Zendesk instance separate from the Support team's Zendesk instance.
The Community Relations instance runs on a Professional Zendesk Support subscription, with one seat per Advocate plus an extra seat for the team manager.
Zendesk access is provided for every Community Advocate and their manager via the Zendesk admin. Once access is set up, Advocates can log in as "Agent" via SSO and their GitLab Google Suite account.
There is a limit on the number of views that can be displayed on the main "Views" panel on Zendesk, regardless of the type of subscription:
If the number of views exceeds these limits, the additional views are moved to the
Settings > Views panel. As the Community Advocates make use of the shared views feature, and as the number of response channels already exceeds the limit of 12, this poses a hindrance on ticket visibility and effectivity.
As a workaround, the team has decided to standardize the personal views for each Advocate, thus effectively increasing the number of visible Views to 20. If the number of response channels exceed the count of 20, an alternative approach could be to consolidate some of the existing views –a practice already followed where it makes sense (e.g. E-mail view).
The workaround is based on two steps: creating a shared view, which then every advocate can clone as a personal view.
To create a new shared view:
Settings > Views
Add viewbutton or clone an existing shared view
Available for, choose
To create a personal view from a shared view:
Settings > Views
Available for, choose
A macro is similiar to an email template, but consists of one or more actions that modify the values of a ticket's fields. Macros are applied to tickets manually by Advocates. For example, we use macros for mentions or questions requests that we can answer with a single, standard response. Please keep in mind, though, that the goal is to personalize each response as much as possible.
Macros can perform the following tasks:
There are two types of macros: personal macros (created by an agent or administrator for their own use) and shared macros (created by an administrator with permission for multiple users).
Please make sure to focus on creating shared macros since we want to keep all the info transparent and available to the whole team.
Although only administrators can create the macros that are shared by all Community Advocates, Advocates can also create personal macros for their own use. A personal macro is only visible to and can only be used or modified by the creator.
Administrators (and agents in custom roles with permission) can create macros that are shared by all Zendesk Support agents or macros that are shared by only agents in a specific group. Administrators can also create personal macros for their own use.
A personal macro is only visible to and can only be used or modified by the creator. Administrators can create shared macros, and can modify all shared macros, regardless of who created them.
You can manually apply one or more macros to a ticket at once. Just as you can make bulk updates to many tickets at once, you can also apply a macro to more than one ticket using your views.
A typical use case is a ticket that contains more than one question or issue, let's say two in this example. You might have set up two macros that both insert a comment into a ticket to answer each issue separately. By applying each macro to the ticket, you add two comments and address both issues in a single response.
There is an option to view a description of a macro, and preview the update it will make to a ticket, before applying it.