What is a support ticket?

A support ticket is one case: a structured record that holds a single customer request from the first message to the moment it is resolved. It bundles the conversation, the people involved and the status into one place, so the request can be owned, tracked and answered.

The word ticket comes from older service desks, where each request was written on a paper docket that moved through a queue until it was dealt with. A modern support ticket is the digital version of that docket. It is created the moment a customer gets in touch, it carries an identifier so it can be referred to later, and it keeps a complete history of what was said and done.

The practical difference a ticket makes is accountability. An email sitting in a shared inbox belongs to nobody in particular, so it is easy for two people to answer it or for everyone to assume a colleague has. A ticket has an owner, a state and timestamps, which turns a loose pile of messages into a queue of work that can be measured and finished.

1. Creation. A ticket is opened when a customer makes contact, usually by emailing a support address. The first message becomes the ticket, and the sender is matched to a contact record so their history is in one place.
2. Triage. Someone reads the request, sets a priority, adds tags or a category, and either takes ownership or assigns it to the right person or team.
3. Work and reply. The owner investigates, may add private notes for colleagues, and sends one or more public replies to the customer. The ticket usually moves to a waiting state while the customer responds.
4. Resolution. Once the request is answered, the ticket is marked resolved. The customer can still reply, which reopens it if they need more help.
5. Closure. After a request is settled and quiet, the ticket is closed. The full record stays searchable, so the next person who hears from that customer can see what happened.

A ticket does not always travel in a straight line. A resolved ticket can reopen when a customer replies, a simple query can escalate, and a low priority can rise if a deadline approaches. The lifecycle is a guide to the normal path, not a one-way street.

New / Open	The request needs attention from your team. It has arrived and is not yet resolved, so it belongs in the active queue.
Pending / Waiting	The ball is in someone else's court: usually the customer, sometimes a supplier or another department. The clock for your next action is effectively paused.
Resolved	You have answered the request. It is treated as done, but the customer can reply and reopen it if they are not satisfied.
Closed	The request is finished and settled. The record is kept for history and reporting, but it is out of the working queue.

Keeping states honest matters more than the exact wording. A ticket marked resolved while the customer is still waiting hides a problem, and a queue full of open tickets that are really waiting on customers makes a team look busier than it is. The discipline is to set the state that reflects reality, every time.

States are also what make response and resolution targets possible. If a tool knows a ticket is open and waiting on you, it can measure how long it has waited and warn you before a promised response time is missed.

Ownership is the quiet engine of good support. A ticket should have one assigned agent who is responsible for the next reply, even when colleagues add notes, suggest wording or pick up overflow on a busy day. Without that single point of accountability, the two classic shared-inbox failures creep back in: two people answer the same customer with slightly different answers, or a request sits untouched because everyone assumes someone else has it.

Ownership is not the same as doing all the work alone. A good ticket separates the public reply, which the customer sees, from private notes, which stay internal, so a teammate can hand over context, flag a gotcha or draft an answer without that note ever reaching the customer. The owner stays accountable for what is sent, while the team helps behind the scenes.

Assignment, reassignment and escalation

Tickets move between people. A triager may assign a billing query to the finance lead, an overloaded agent may hand a ticket on, and a tricky case may escalate to someone more senior. Each handover should be visible in the ticket history, so the new owner can see what has already been tried and the customer never has to repeat themselves.

For a small team, the value of tickets is not bureaucracy, it is calm. A shared inbox works until two or three people are answering at once, at which point messages get double-handled, important requests get buried under newsletters, and nobody can answer the simple question, what still needs a reply today. Tickets turn that anxiety into a list.

Tickets also create memory. Because every request and reply is kept against a contact, the next person who hears from that customer can see the whole story: the order they asked about last month, the refund that was promised, the workaround that was suggested. That history is what lets a small team sound like it remembers every customer, because it does.

• Nothing is dropped, because every request has an owner and a state.
• No customer is answered twice, because the ticket shows who has it.
• Response and resolution times can be measured, because the clock is built in.
• Patterns become visible, because tags and reports group similar requests.

Ticket lifecycle	The journey a ticket takes from creation to closure, through its various states. The lifecycle is the verb to the ticket's noun.
Help desk	The system or team that receives, tracks and resolves support tickets. The desk is the place; the ticket is the unit of work.
Shared inbox	A mailbox like support@ that several people read. Ticketing is what turns a shared inbox into owned, tracked work.
SLA	A service level agreement, the promised response or resolution time a ticket is measured against, often within set business hours.