Better Pending Ticket flow with Custom Statuses

Not every ticket can be solved with a single reply. Agents often need more information from customers in order to get the full context and reply with an answer.

Or, even if all info is there, they need confirmation that their suggestions worked before the ticket can be solved.

This is where the pending status comes in. Any ticket submitted with a pending status tells the agent and the system: “we did what we could do, now it’s up to the customer.”

Note the first part of the sentence: work’s done for now.

So for efficiency’s sake, the less those tickets need be be touched or looked at again, the better. You don’t want your agents spending time looking at handled tickets or worse manually reminding them about the replies they gave.

With automations in Zendesk you’ve long been able to automate this process (pun intended). Zendesk Admins often build automations that remind customers after a couple of days to reply, with additional automations to then solve or open those tickets after a few more days.

It’s a good concept cause it keeps tickets moving, reduces the pending backlog and does not increase agent handling time.

Custom Statuses

Zendesk released Custom Statuses in EAP late September. It expands on the regular open, pending, on hold statuses with an option to add subtypes for each.

It allows you to give more context with a specific status update, but it can also make setting up automations and triggers a lot easier.
You can find full documentation here or check the article below for a nice proof of concept flow.

Automating Pending tickets.

Without any automations, a typical ticket flow looks like this:

A better way is one where we add a reminder via an automation. That way, if a customer does not reply, we remind them and gently nudge them to reply.
If the customer still does not react, we can then add a final automation that either solves the ticket silently, or re-opens the ticket so the agent can either remind the customer one more time.

Automatic reminder emails

The reminder increases reply rates and often pulls reply time forward. Instead of the agents’ email lingering in the customers’ inbox, the reminder is just annoying enough that most customers do reply immediately, either because they forgot the first reply, or because they don’t want any more reminders.
And with a faster reply comes better handling time and thus better CSAT.

Changing the status

The second automation can be used to either resurface the ticket to your agents, or remove it from the queue. Which one you choose depends to your specific use case and the ticket content.

You can either solve tickets the customers hasn’t replied to or re-open them.

Automatic solving is ideal for tickets where you await a confirmation.

I can’t print > Try this > .. silence.

If the customer can print they often don’t bother replying, leaving the ticket pending forever.

Automatic opening is useful for complex tickets or tickets where the agent needs more information before able to go forward. In those cases re-opening allows for a personal reply to get the answer, or to solve the ticket anyway since they can see no reply will ever come.
Since the original reminder already turned a lot of silent tickets into actual replies, the amount of tickets surfaced by this last automation is greatly reduced.

How to set it up

Traditionally sending out reminder emails meant having automations that include a tag or other condition in order to make sure that the reminder gets send out only once.

Using Custom Statuses

Now with custom statuses we can do this more elegantly.

Overview

We first introduce two new pending statuses.

By splitting up pending we get a lot more information:

• The first type of tickets are the traditional pending tickets where you expect to get a reply before being able to move forward.
• The latter are tickets that are solved from the agents point of view but where there is a change tat the issue is not actually fixed. Moving them to solved immediately often leads to re-opened tickets and premature CSAT emails, so pending is the right choice here.

By giving those tickets a separate status we can have better reporting, and have a different automations flow.

Creating the custom statuses

Setting up Custom Statuses can be done in the Admin Center. I prefer to keep the default one as is and add new ones, but you could just as easily repurpose one of the existing ones.

I added the following ones:

1. Open > Reopened.
   A status to reflect tickets opened by the system vs tickets opened by a customer reply
2. Pending > Awaiting Reply
   Uses to show we wait for a customer comment or answers
3. Pending > Awaiting Confirmation
   Used to show we need to know if a ticket can be solved
4. Pending > Reminder Sent
   We reminded the customer. Used in triggers or by agents.

Creating the automations

Now that we have our custom statuses we can setup our automations.
We start with the existing automation we mentioned above and tweak a few important things:

• We remove the tags since we don’t need those anymore
• We change Status Category into a specific Ticket Status
• We use a different custom Open Status to make a difference between Open (Customer) and Reopened (System)

In the end we end up with 3 automations:

1. [Pending Awaiting Reply] Remind after 3 Calendar days
   Gently nudge the customer to react.
2. [Pending Reminder Send] Open after 3 Calendar days
   We open the ticket if no customer action for tickets where we need a ticket. The agent can then reply or solve.
3. [Pending Awaiting Confirmation] Solve after 5 Calendar days
   If we hear no confirmation we can assume it’s fixed.

Using it

How does this get used by your agents?

1. A ticket comes in and a customer has a complex inquiry
2. The agent replies with some additional questions to get a clearer view on the issue. They put the ticket on Pending - awaiting reply.
3. The ticket disappears from their open tickets view.
4. The customer does not immediately reply. After three days the system sends out a reminder email via an automation and sends the ticket to status‘Pending - Reminder Sent’.
5. The customer does not reply even with the reminder.
6. The system runs a second automation that reopens the ticket
7. The agent then solves the ticket or reminds them manually one final time.

Wrapping it all up

These new custom statuses give agents a lot more visibility in both what the real status of a ticket is, and in what the system does with their statuses behind the scenes.

Some other statuses and automations that could work in a similar manner: