Purpose
Provide clear, consistent guidance for selecting the correct Priority, Organization, Case Type, Case Avoidable, Ticket Status, and Pre‑Closure checks in Zendesk to ensure accurate routing, reporting, and customer satisfaction.
Scope
This SOP applies to all support agents and leads involved in handling, triaging, or resolving support tickets in Zendesk.
Selecting the Correct Priority
Refer the Ticket Priority Definitions Article.
| P-Level | Priority Values | Description |
| Critical | P0 | Critical issue that prevents communication processed by a group/BU, emergency weather event, Sev-0 Compliance Violation. Requires immediate attention. |
| High | P1 | Major issues that prevent processing of Voice/SMS for a particular region/country/carrier/group of users only. |
| Medium | P2 | Storm Prep / PSPS Execution, Non-urgent issues that affect functionality but don’t block users |
| Low | P3 | Minimal impact, general questions, future campaign requests, Report access, provisioning / deprovisioning, delivery issues for single end user. |
| Request | P4 | No immediate action required informational or feedback. |
Priority Decision Matrix
| Impact \ Urgency | High Urgency | Medium Urgency | Low Urgency |
| High Impact | P0 – Critical Major outage, severe disruption, financial/reputation risk. | P1 – High impact and time-critical. | P2 – Medium |
| Medium Impact | P1 – High Time-sensitive issue affecting multiple users. | P2 – Medium | P3 – Low |
| Low Impact | P2 – Medium | P3 – Low | P4 – Informational |
Customer Communication (When Changing Priority)
- Always inform the customer before changing priority.
- Use the approved communication macro (Downgrade Ticket Priority).
- For priority downgrades, consult Leads.
- For special accounts (PG&E, Duke, ConEd, SCE), consult Managed Services.
Re‑evaluate When Situation Changes
- Monitor the ticket closely to ensure timely escalation or resolution if it transitions from a low priority to a high or critical priority.
- Update priority if the impact/urgency increases or decreases.
Selecting Correct Organization
1. Understand What an Organization Represents
- A company, client, or user group.
- Users may belong to multiple organizations (e.g., JPMC – 4 orgs, PG&E – 9 orgs).
2. Check User’s Email Domain
- Zendesk can auto-assign an organization based on email domain mapping (e.g., @pge.com → PGE).
- Ensure the domain is set correctly in the organization settings.
3. Search Before You Assign
- Always search for an existing organization to avoid creating duplicate organization. Check with Leads if unsure.
Selecting Correct Case type
Refer to complete SOP - SOP-CO-Support- Case Type Definition- Zendesk .docx
| Case type | When to use | Example |
| Report an Incident | Unplanned service disruption or outage. | System down, users unable to log in. |
| Report a Defect | Bug or unexpected product/service behavior. | Incorrect data, wrong profiles, faulty search results. |
| Submit an Enhancement Request | Suggesting improvements or new features. | Add new dashboard column, bulk edit option. |
| Submit a Change Request | Planned modifications to system/process/configuration. | SLA updates, email template changes. |
| Submit a Support Request | General help, troubleshooting, or guidance. | Password reset, login help, how to‑ queries. |
| White glove Request | High‑touch, specialized support for VIP/enterprise customers. | Event support, large‑scale data migration. |
| Campaign Request | Planning or executing campaigns. | PSPS campaigns, storm notifications. |
| Submit a New Program Request | Starting a new initiative or program. | New portal launch, pilot program setup. |
| Helpdesk | Internal IT or employee support needs. | Access requests, VPN installation, new user setup. |
| Vendor Maintenance Notification | Tracks vendor, partner, external service provider announced planned maintenance. | AWS scheduled maintenance notice, SMS provider performing system updates |
| Submit an Account Related Query | Billing discrepancies, invoice questions, and payment disputes or clarification | Explain the new charge my account, Invoice is incorrect |
Selecting Correct Billable
| Field | Yes | No |
| Billable | Select Yes when the issue is billable eg. White gloves services/campaign/new program request. | Select No when the issue is not billable, eg. Access request, troubleshooting, bug report, general query. |
Mandatory Updates When Billable is Yes:
| Field | Guidance | Details |
| Estimated Total Hours | Update the estimated total hours | Info can be gathered from the engineering team |
| Actual Total Hours | Update the actual total hours | Info can be gathered from the engineering team |
| Project/PO | Update the Project/PO details | Project/PO info needs to be gathered from the customer |
Selecting Correct Case Avoidable
| Field | Yes | No |
| Case Avoidable | Select Yes when the issue did NOT require a ticket and could have been resolved through existing resources. | Select No when the issue did require investigation or a formal ticket. |
Mandatory Updates When Case Avoidable is Yes:
| Field | Guidance | Details |
| When to Select “Yes” |
Issue could have been resolved by: • Using an existing KB article • Following standard process/documentation • Steps within Tier 1/Tier 2 scope • Directing customer to self‑service tools |
— |
| Required Fields When “Yes” Is Selected | The following fields must be updated when Case Avoidable = Yes | — |
| 1. Source | Identify who could have resolved the case without opening a ticket |
• Tier 1: First‑level support • Tier 2: Second‑level support • Customer: Could resolve via self‑service or guidance • N/A: Avoidable but does not fit the above categories |
| 2. KB/Resource Exists | Indicate whether a KB, SOP, or tool exists to resolve the issue |
Yes: Provide the exact article/SOP/tool name or link No: Add an internal note describing how the issue could have been resolved without a KB; Else put an internal note that KB is needed and add it to the respective trackers. |
Choosing the Correct Ticket Status
| Status | Definition | When to Use |
| Assigned | Ticket has been assigned to an agent or team. | Ownership established, work not started |
| In Progress | Work is actively being done on the ticket. | Active investigation/troubleshooting |
| Fix Scheduled | A fix has been identified and scheduled for deployment/release. | Fix identified and planned for release |
| Sent to Other Team | Issue requires action from another team (Dev, Infra, Vendor, etc.). | Awaiting action from another team |
| Reopened | A previously resolved ticket has been reopened. | Issue recurs after closure |
| Customer Replied | Customer has responded and the ticket needs review. | Customer has responded |
| Pending | Waiting for customer input, confirmation, or details. | Waiting for customer input |
| Solution/Fix Sent | A solution or workaround has been provided to the customer. | Solution shared, awaiting confirmation |
| Future Release | The issue will be resolved in a future product release. | Fix planned for a future release |
| Escalated to Engineering | Issue is reported to the Engineering team for further investigation | Issue escalated to the engineering team |
| Defect | Issue identified as a product defect/bug. | Confirmed product bug |
| Closed | Ticket has been resolved or no longer requires action. | Issue resolved or no action required |
| Closed Duplicate | Ticket is a duplicate of an existing ticket. | Duplicate of existing ticket |
Comments
0 comments
Please sign in to leave a comment.