This interactive "Full circle" session will provide best practices on using ticket status and type. When your agents use these features correctly, you optimize agent workflows and more easily scale your support operation. You’ll learn how to:

• Use ticket status and type in the right context
• Organize your workflows with status
• Automatically manage tickets in the pending status
• Utilize incident and problem tickets to scale your support team

Answering your questions in the comments below are members of our Customer Success Team.

Part 1: Understand when to use each status

There are five values for ticket status and you can see a definition for each in this article. It’s important to understand the purpose of each status as they help to power both workflow and reporting across your account, but we wanted to call out a few specific points to keep in mind.

Open vs. Pending: The open and pending statuses are essentially opposites. Open means that the ticket must be addressed by an agent at your company while pending means that more information is needed from the requester before the issue can be resolved.

It’s imperative that your agents use the pending status correctly to avoid delays in resolution time. Let’s walk through a simple example to see why…

Most ticket views are prioritized on tickets in the new and/or open status since those tickets require an agent response. If a ticket is transferred from one agent to another and is accidentally set to the pending status, it won’t appear in the new assignee’s views that are focused on new or open tickets. It might not be noticed at all until the customer replies wondering what is causing the delay.

So again, when an agent is responsible for the next step - always set the status to open ;) 

On-hold is an optional status and not available in Zendesk Support unless you enable it. It’s used to track tickets that require input or resolution from a third party and should not be used as an alternative for open or pending.

Solved vs. Closed: These two statuses are used to denote slightly different stages at the end of the ticket lifecycle.

Agents can mark tickets as solved when they believe the issue has been resolved and don't anticipate a follow-up question from the requester. If the end-user does respond, the ticket simply re-opens.

The closed status, on the other hand, is permanent and only applied by business rules or system automation. In this status, the ticket can’t be reopened or updated by anyone and any replies to the ticket will create a separate follow-up ticket.

There is a default automation with your Zendesk account that automatically closes a ticket four days after it is set to solved. You can edit the automation to close a ticket anywhere up to 28 days from the time it was solved (at which point all tickets are automatically closed).

If you want to update the number of days in the solved to closed automation, best practice guidelines recommend that you leave a ticket in a solved status for several days before moving it to closed. This allows your end-users or customer to re-engage with you in the same ticket.

Part 2: Utilize the pending status to automate your ticket workflow

It's best practice for agents to set a ticket to the pending status when they're waiting for an end-user to reply. This keeps their views clean so they can focus on tickets that are ready for their assistance.

A common next step is for the agents to review their pending tickets and send friendly reminders to these customers on a regular basis - but that takes time that could be spent with new inquiries.

This is where the “Bump Solve” process steps in to provide the same customer experience without wasting any agent time. It’s a series of two simple automations that:

• Bump: The first automation sends a reminder to the end-user after their ticket has been in the pending status for 48 hours.
• Solve: If the end-user doesn’t respond in another 48 hours, the ticket is solved.

As seen in his article, “Bump Solve” only takes a few minutes to configure before rewarding your team with time back in their day and a cleaner ticket backlog. 

Part 3: Use the on-hold status to keep track of third party tickets

The benefits of using the on-hold status when partnering with third parties to solve tickets include:

• Filtering out on-hold tickets when tracking agent performance.
• Creating views to keep track of tickets that need work by the third party.
• Building automations to email the third party requesting an update.
• Analyzing the amount of time that tickets spend in the on-hold status to identify opportunities for improvement.

All of this gives you better data on what’s actually going on in your support organization and track who is responsible for a ticket. 

Part 4: How to use ticket types

Properly leveraging the four different ticket types gives your agents the tools they need to efficiently manage the different scenarios they encounter on a daily basis. It also empowers you to make swifter decisions based on better data.

• Question: In most use-cases, the majority of  tickets are categorized as questions. As the name implies, these are simply customer questions that can be answered by your team
• Task: This ticket type allows you to set a specific due date which you could reference in automations to send notifications or reminders.
• Problem: These are larger issues with your product or service that could be impacting multiple customers.
• Incident: Individual occurrences of a larger problem that’s impacting multiple people  

Part 5: Working with problem and incident tickets

When used together, problem and incident tickets make life easier when large scale issues arise.  Understanding the full value of these related ticket types is easiest when considering an example:

Say that your company makes games for mobile devices. You might get multiple reports from customers saying that the app is closing out each time they try to upload a new avatar into their profile. Instead of managing these requests separately in a time-consuming and potentially confusing manner, each could be logged as an incident tied to the larger problem impacting these customers.

In doing so, you can easily see that this “Avatar Upload Problem” has been reported by X customers. As your team has updates to share and when the problem has been resolved, all they need to do is update the single problem ticket and their comment will cascade down to all of the related incidents and customers (saving loads of time for your agents).

When the time comes for analysis, it’ll be easy to compare your handle time and CSAT scores across the different problems your team managed. And, if managing multiple problems that’ll take a while to fix, your team could prioritize based on those with the highest number of incidents.

Another way of using the problem/incident tickets is in a proactive way. Using the same company example, let’s say you have a scheduled maintenance coming up for your app. You can create a problem ticket ahead of time for your agents to reference in the moment.

If you come across a problem/incident scenario, use these simple steps:

1. Create your own ticket to address the problem.

2. Change the other tickets to incidents and link them to your problem ticket.

From the problem ticket you can now easily track how many customers are being affected by this problem.

3. When you update or reply to the problem ticket and mark the status as solved, it’ll automatically flow to the related incident tickets (saving you lots of time!)

Bringing it “Full circle”

Sandip Karmakar said it best “A little push at the right direction, can make a big difference”.

We hope these minor tweaks to your use of ticket status and type will align your agents towards a workflow that truly scales.