If a customer submits a ticket via the web ticket form, they can choose the starting priority of the ticket - this is the 'Customer Priority' field you will see in Zendesk. On ticket creation a trigger sets the main 'Priority' field to match the 'Customer Priority' choice.
If a customer emails in a ticket it will get a Prioriy of 'Normal' (unless it is sent to the special emergency contact).
Manually setting a ticket's priority in Zendesk will change the overall ticket SLA, for both the first and next replies. This allows support to prioritize tickets and update the urgency during the life of the ticket (for example the initial request may be 'High' priority and then follow up questions may need 'Low' priority.)
|Priority||First/Next Reply - SLA (business hours)|
|Normal||8 hours (Medium)|
|Urgent||30 mins (Emergency)|
Tickets should be prioritized based on the guidelines below. The priority can change at any stage in a ticket's lifecycle.
Questions or Clarifications around features or documentation or deployments (24 hours) Minimal or no Business Impact. Information, an enhancement, or documentation clarification is requested, but there is no impact on the operation of GitLab. Implementation or production use of GitLab is continuing and work is not impeded. Example: A question about enabling ElasticSearch.
Something is preventing normal GitLab operation (8 hours) Some Business Impact. Important GitLab features are unavailable, or somewhat slowed, but a workaround is available. GitLab use has a minor loss of operational functionality, regardless of the environment or usage. Example: A Known bug impacts the use of GitLab, but a workaround is successfully being used as a temporary solution.
GitLab is Highly Degraded (4 hours) Significant Business Impact. Important GitLab features are unavailable, or extremely slowed, with no acceptable workaround. Implementation or production use of GitLab is continuing; however, there is a serious impact on productivity. Example: CI Builds are erroring and not completing successfully, and the software release process is significantly affected.
GitLab is unavailable or completely unusable (30 Minutes) A GitLab server or cluster in production is not available, or is otherwise unusable. An emergency ticket can be filed and our On-Call Support Engineer will respond within 30 minutes. Example: GitLab showing 502 errors for all users.