Plan requirement
| Subscription | Any plan |
| Access | Agent |
A ticket is one conversation about one question. Understanding its life explains most of what Zendesk does around it.
What a ticket carries
- A requester. The person whose problem it is.
- An assignee. The agent responsible, and usually a group as well.
- A status. Who has to act next.
- A channel. How it arrived: email, the web form, a message, a call.
- The thread. Every public reply and internal note, in order, with attachments.
- Fields. The standard ones plus whatever your organisation added.
How a ticket is born
Tickets are created whenever a message reaches you through a channel you have set up, or when an agent creates one by hand. Whichever route it takes, the result is the same kind of object, which is why a customer who phones and then emails can end up on one ticket.
Zendesk matches on the requester's email address. That is why two people sharing a mailbox, or a customer writing from a second address, produces surprises.
The life it goes through
| New | Nobody has picked it up. |
| Open | Someone is on it and the ball is with you. |
| Pending | You have asked the customer something. |
| On-hold | You are waiting on somebody who is not the customer. Optional: an admin has to switch it on. |
| Solved | Dealt with, but still able to reopen. |
| Closed | Locked. A reply now creates a follow-up ticket instead. |
Closing is not something an agent does. Zendesk closes solved tickets automatically, four days after they were solved by default. You can retime that, up to a ceiling of 28 days, but you cannot switch it off.
Why the status matters more than it looks
Triggers, automations, SLAs, views and every report read the status. A queue where everything sits on Open because nobody moved it produces figures that describe your habits rather than your work.
Comments
0 comments
Article is closed for comments.