Allowing Support Engineers to define aliases in Zendesk and GitLab.com handles in ZD signatures
GitLab Support: Process Change Rollout Plan
Allow Support Engineers to define an alias in Zendesk and add their GitLab.com handle to signatures
The Story
Support Ops is looking to provide all Support Engineers with the ability to define a Zendesk Alias in their respective support-team.yaml files. This will be done by providing access to a new alias
value which can be used to define their desired alias when communicating with customers inside of Zendesk. SE's will have the ability to control whether they show their full name, surname, or even potentially a different name entirely in all messaging sent via Zendesk. We haven't really decided how/if this should be limited to begin with. At the moment, it'll be up to a manager's discretion, but perhaps this is something we should define either as part of this change, or in the future.
In addition, Support Ops is going to allow Support Engineers to decide if they would like to display their GitLab.com handle in their agent signatures in Zendesk. This will be updated by just setting their gitlab_handle:
value to true
or false
, e.g:
show_in_signature:
gitlab_handle: false
If an engineer has this value set to true, their signature will look something like this in ZD:
More context around how we came to this as a solution can be found in the following STM issues:
- Optionally allow agents to set aliases in Zendesk (#6072 - closed)
- Add GitLab.com handle to Zendesk signatures (#6040 - closed)
The Roles
Role | Description |
---|---|
Champions | @dtragjasi @lyle |
Users | Support Engineers/Support Operations |
Impacted Non-Users | N/A |
Schedule
- This functionality is expected to be live on 2024-06-01.
Training
There's no training required here, but we just want to make sure this is communicated across all of support so everyone has the opportunity to change these values as they see fit.
Success Determination
The main goal we have here is to provide a solution that allows Support Engineers to display their personal details in a way that makes them feel most comfortable/empowered when interacting with our customers. Every single individual will have a different preference for how they decide to use (or not use) what is available to them, and just by simply having these settings as options, we feel as though we're contributing to a more inclusive GitLab for our employees, and a more personalized experience for our customers.
I think this discussion here is a great example of why these are important changes, and why having specific success criteria is not really applicable here.
Action Plan
-
Create an item in the SWIR to announce the change and include The Story on 2024-05-29
- NOTE: On the SWIR form, add the
Manager Attention
tag for policy changes and action items for Support Managers specifically (you can add multiple tags to a SWIR item)
- NOTE: On the SWIR form, add the
-
Post a message in the #support_team-chat
Slack channel (or other support channel as appropriate) announcing the change and pointing to the SWIR announcement on2024-05-29
-
Announce the change and tell The Story in Team meetings by 2024-05-31
-
EMEA team meeting -
AMER team meeting -
APAC team meeting
-
Manager Acknowledgement Section
Expectations
Acknowledgement from all managers would be greatly appreciated here before the change is rolled out on 2024-06-01
. Please check off your name to indicate you have reviewed the information, and will share it with your team.
Due Date
Check off your name by midnight UTC on: 2024-05-31
Names
Support Managers
Sorted alphabetically by region / GitLab handle
AMER + USFed
APAC
EMEA
Senior Management team
Follow-Up Plan
- How will results be captured? By whom and by when?
- Continued discussion can take place in either of the STM issues linked above ( #6072 (closed) and #6040 (closed)). We're not capturing any specific results/metrics about this change but any feedback is always appreciated.
- Is a rollback feasible, and if so how will it happen?
- Rollback is technically feasible, but we don't expect a need to do this. The additional customizations engineers can make to their details in the support-team repo are all optional, so if they decide they would no longer like to utilize them, they can revert their details to their current state.