Zendesk Ticket Categorisation and Prioritisation Process
- Subrat Sandilya
Analytics
Process Flow Diagram
Ticket definition
All support requests, from all channels, become Zendesk Support tickets. Tickets capture the customer's initial request for support and all the conversations your agents have with the customer along the way to solving their support issue. Some key attributes are Priority, Severity, Solution Module, Time spent to solve a ticket, Status, etc. which helps to meet the customer needs in a better way.
Ticket Information
The managed services team has to create a Zendesk ticket for each of the client tasks with a Comprehensive list of things
Need to include hybrid system ticket references(Content from the client’s ticketing system ex: For AJG we can mention AJG Jira ID).
URL of client's tickets, and important attachments.
Update ticket with correct information (Ex: Organization name, notifying customer, priority, hours, status, etc)
Need to segregate planned, and unplanned tickets.
Managed Services Ticket Fields
Ticket fields contain all ticket data, such as subject, description, and priority. Below mentioned fields are added into default ticketing form.
Ticket Origination
Email
Phone
Customer Tools
Ticket Category
Issues
SR(Service Request)
CR(Change Request)
Client Meeting
Severity
Critical - Production System Down
High - Production System Impacted by critical loss of functionality or performance
Medium - Minor loss of application functionality
Low - Technical Query or Enhancement request
Priority
Ugent
High
Normal
Low
Internal Status
New
Assigned
Pending
Escalated to Product Team
Closed
Waiting for Client's’s reply
Waiting for the Product team’s reply
Adeptia Components
Adeptia Connect
Administration
Application Configuration
Custom Plugin/Native Call
Data Mapper
EDI
GUI/Web Page
Installation/Upgrade
License
Process Designer
Solution Support
Source/Target
Triggers/Events
Web Services
Build Tag
The build tag field is conditional(If a category is maintenance)
Guidelines to work on a ticket
MST has to create a ticket by sending an email to a client-supported email box. Ex: If a ticket has to be created for Hussmann then the team member has to send an email to hussmann@adeptia.com from the hussmann email box.
If a ticket is created through the Zendesk Create a Ticket option, the creator must make sure that the requester field has the right account so that the ticket can be moved to the correct organization.
MST must choose the correct ticket form while creating a ticket in Zendesk.
For Hussmann issues the user has to choose Hussmann ticketing form.
For System monitoring tickets the user has to choose the default ticketing form.
Team members must ensure that the correct category is filled into the assigned ticket.
Each team member is responsible for logging correct hours into tickets where he/she has worked.
Each team member has to use a self-audit dashboard on a daily basis to evaluate the tickets and hours.
While replying to the tickets, the user has to make sure that the right parties are included in the followers list.
Users have to make sure that the first reply time on a ticket should not exceed 30 minutes and in cases of urgent issues, it should be instant.
Each team member is responsible to take follow up on a ticket when a reply is awaited from the client. First, follow-up should be taken in 24 hours.
Most commonly used ticket categories and definitions
Ticket Category | Definition |
Issues-Infrastructure Issue-Network Issue | For network-related issues, users have to choose this category while reporting a ticket into Zendesk. Ex: Hussmann network issues |
SR(Service Request)-Maintenance-New Account Creation | For new account creation requests the user has to choose this category. Ex: Ilwotc user creation request. |
SR(Service Request)-Maintenance-File Processing | This category is to be used when processing ILWOTC DHS/Claim/Wage files. |
SR(Service Request)-Maintenance-Planned Maintenance | This has to be used when any client has planned maintenance and MST has to work on it. Ex: Hussmann disabling/enabling events. |
SR(Service Request)-Maintenance-System Monitoring | In monitoring tickets the user has to choose this category. Ex: Hussmann, Ilwotc solution monitoring. |
SR(Service Request)-Maintenance-Required Source Data | This category is required to be filled when a client requires source data. Ex: Hussmann XML request, Ilwotc report request. |
Client Meeting | For meeting with any of the clients MST has to choose this category. |
CR(Change Request)-Enhancement-Changes in an existing solution | This category is to be used when MST is working for any enhancement. Ex: AJG user stories. |
SR(Service Request)-Maintenance-Solution Health Check | This category is meant to be used in health check tickets. Ex: ILWOTC monthly health check, Server restart, etc. |
Ticket life cycle
Each ticket has a life cycle. In other words, the stages it goes through as it arrives in Zendesk Support until it is solved.
Here are the typical stages:
When a Zendesk Support request first arrives, it becomes a ticket and is automatically set to New.
When an agent is assigned to the ticket, the ticket is automatically set to Open.
If the agent has a follow-up question for the customer, the agent will set the ticket to Pending, which means that the agent is waiting for more information from the customer.
When the agent resolves the issue, they will set the ticket to Solved.
Finally, after a certain number of days, the ticket is automatically Closed and archived for later reference. Agents will never manually set a ticket to close (which is why you don't see it as an option on the Submit button).
Agents expect that when they set a ticket to solve the customer's issue has been resolved and the conversation around that particular issue is over. However, if the customer doesn't feel the same way, they can respond back to the agent by replying to the "ticket solved" email notification. When this happens, the ticket is reopened and it's the agent's job to follow up and go through the ticket lifecycle again.