A support ticket is the record a help desk creates when a customer asks for help by email, website chat, contact form or message. It holds who asked, what about, the whole conversation, a status, a priority and an owner, so anyone on the team can pick it up. For an online store, the order behind it matters most.
What is a support ticket?
A support ticket is one record for one customer request, with one owner, one history and one status. Ticket support means help that runs through those records: whatever the channel, the request becomes a ticket, so the next person can see what was said and promised.
Zendesk’s API reference describes tickets as the means through which customers communicate with agents, and says they can originate from email, Help Center, chat, phone, X, Facebook or the API. So the ticket is the record, not the channel. Some tools now say conversation or chat instead of ticket. The record underneath is the same: a threaded record with a state.
For a store, almost every ticket hangs off an order, a product or a customer account. A ticket that lacks the order number starts with a question back to the customer. If you want the wider picture of a support team, the hub covers it, and the ticketing system guide covers the software that holds them.
What is a service ticket, and how does it differ from a case or an incident?
A service ticket is mostly a synonym for a support ticket. The differences are naming conventions per tool and per framework. ITIL splits requests into incidents (something broke) and service requests (something routine is asked for). Salesforce calls the record a case. Zendesk has a Type field with Question, Incident, Problem and Task.
| Term | Where you meet it | What it means | Online-store example |
|---|---|---|---|
| Support ticket | Most help desks | One record per customer request | ”Where is my order?” |
| Service ticket | IT service desks and general use | The same record, named for a service desk | A returns request logged by the service team |
| Case | Salesforce | ”A case is a customer’s question or feedback” (Salesforce) | A complaint about a late parcel |
| Incident (ITIL) | ITIL and IT service management | ”An unplanned interruption or reduction in quality of an IT service” (IT Process Maps); Atlassian adds that it requires an emergency response, such as “The website is down!” | The checkout stops working |
| Service request (ITIL) | ITIL and IT service management | ”A formal request from a user for something to be provided, as distinct from an incident” (Atlassian) | A customer asks for a size exchange |
| Problem (ITIL) | ITIL and IT service management | The underlying cause of recurring or preventable incidents (Atlassian) | The payment provider fails repeatedly |
One trap catches people who come from IT. In Zendesk, the ticket type Incident does not mean an ITIL incident. Zendesk defines it as a single occurrence of a larger problem that affects multiple users, and Problem is the parent ticket those incidents link to. Solving the problem solves the linked incidents. The same word means something different in your help desk.
Most store tickets are service requests in ITIL terms: where is my order, can I return this, does this come in a larger size. A true incident for a store is the checkout or the payment provider going down, which makes many customers write in at once. That is when linking incidents to one problem ticket earns its keep. IT tickets are a different world, with password resets and laptops.
What does a support ticket contain?
A support ticket holds who asked, what about, the conversation, where it stands, how urgent it is and who owns it, plus tags and the channel it came from. A store needs one more thing: the order. The help desk does not know it by itself unless the store is connected.
| Field | What it holds | Set by | Why a store cares |
|---|---|---|---|
| Requester | The customer who asked | The channel or the agent | Links the ticket to a customer history |
| Subject | A short title | The customer or the agent | Can be empty on email or API tickets: the first comment becomes the subject |
| Comments | Public replies and internal notes | Customer and agents | Notes keep context for colleagues without the customer seeing it |
| Status | Where the ticket stands | Agents or rules | Says who has to act next |
| Priority | Urgent, high, normal or low in Zendesk | Agents or rules | Decides what is answered first |
| Type | Problem, incident, question or task in Zendesk | Agents or rules | Separates one-off questions from outages |
| Assignee and group | The person and team responsible | Agents or rules | One owner, so nothing is answered twice |
| Tags | Labels for sorting and counting | Agents or rules | Lets you measure your own ticket mix |
| Channel | Where the request came in | The help desk | Email, chat and social behave differently |
| External ID | ”An id you can use to link Zendesk Support tickets to local records” | An integration | The hook that connects a ticket to an order |
| Order number and customer record | The store data behind the request | A store connection or the customer | Without it, the agent asks before answering |
Zendesk’s Tickets API is the source for the field list. Custom fields sit alongside them.
Here is an example. A chat says “my hoodie arrived in the wrong size, order 10482”. It becomes a ticket with the customer as requester, channel chat, type question, tags return and exchange, priority normal, status new, and the order number either in the text or in a custom field.
Which statuses and priorities does a support ticket move through?
Zendesk uses six standard statuses: New, Open, Pending, On-hold, Solved and Closed (On-hold is optional, and accounts created on or after 13 February 2024 may also see In Progress). Other help desks name and count statuses differently. The status says who must act next. Priority says how soon: Zendesk offers Low, Normal, High and Urgent, and Gorgias offers Low, Normal, High and Critical.
Zendesk’s ticket lifecycle defines the statuses like this:
- New: no action taken yet. Agents cannot set a ticket back to New; the exception is an AI agent ticket escalated to a human, which Zendesk resets to New.
- Open: assigned and waiting on the agent.
- Pending: waiting on the requester. It reopens when they reply.
- On-hold: waiting on someone other than the requester. The customer sees it as Open.
- Solved: the agent submitted a solution. If the requester replies, the ticket reopens and goes back to the agent who solved it.
- Closed: closed by the system. The requester can no longer reopen it.
Tickets cannot be closed by hand. Zendesk’s default automation closes a ticket four days after it is solved. If an admin deactivates the closing automations, the system closes it 28 days after solving, a rule that cannot be changed. The requester cannot reopen a closed ticket but can create a follow-up request that references it.
| Help desk | Levels | Default | Note |
|---|---|---|---|
| Zendesk | Low, Normal, High, Urgent | None required | Priority is optional and admins can limit it to Normal and High. SLA policies only apply when the system Priority field is set, and a standard trigger sets unset tickets to Normal (SLA policies) |
| Gorgias | Low, Normal, High, Critical | Normal | Set manually or by rules, and not mandatory (Gorgias) |
Set priority by what is at stake, not by who shouts. A cancel-before-it-ships request or an order going to the wrong address loses money by the hour. A sizing question does not. That is our view, not a rule of either tool.
What types of support tickets does an online store get?
Most store tickets fall into a handful of types: where is my order (WISMO), returns and refunds, product and sizing questions before purchase, damaged or missing items, order changes and cancellations, and checkout failures. Each needs different data to answer, and that decides which can be answered without a person.
| Ticket type | Typical message | Data needed to answer | ITIL class | Who should handle it |
|---|---|---|---|---|
| WISMO | ”Where is my parcel?” | Order and carrier tracking | Service request | Anyone with the tracking data |
| Returns and refunds | ”Can I send this back?” | Order, return policy, return status | Service request | A person for exceptions, since a refund is a decision |
| Pre-sale product question | ”Does this come in a larger size?” | Catalogue, stock, sizing | Service request | Anyone with the product data |
| Damaged or missing item | ”It arrived broken” | Order, photos, carrier proof | Service request with judgement | A person checks the evidence |
| Order change or cancellation | ”Change my address” | Order and fulfilment status | Service request, time-critical | Whoever can still stop the shipment |
| Checkout or payment failing | ”I cannot pay” | Reports from many customers | Incident | Link every report to one problem ticket |
No verified primary source gives the share of store tickets that are WISMO. The widely repeated 40% traces back to a second-hand figure, so we do not quote it. Measure your own mix from tags instead; ticket reporting shows how. The use cases for order status, refunds and product advice go deeper on the three biggest types.
How do you write and handle a good support ticket?
A good ticket is one an agent can answer without asking anything back. For the customer, that means the order number, what went wrong and a photo where it helps. For the team, it means one owner, an honest status, internal notes for context, and a reply that closes the loop.
Writing one. A customer to a store should include the order number, the email used at checkout, the item and size, what happened, photos for damage, and what they want: a refund, an exchange or a reshipment. Make your contact form ask for the order number, so the ticket arrives complete.
Handling one. Work through it in this order:
- Acknowledge it, so the customer knows it arrived.
- Find the order before replying.
- Set the status to show who acts next. Zendesk’s Agent Home guide tells agents to move handled tickets out of Open after replying.
- Use internal notes for context, not the public thread.
- During an outage, link duplicate tickets to one problem ticket.
- Escalate with the context attached, so nobody asks the customer twice.
- Solve with a clear final answer.
A ticket has a limit: it records what was said, not why an answer was given or which policy was applied. That is the gap the next section picks up. To judge how you are doing, count tickets by type and by outcome rather than by volume alone.
Where does Engaige fit?
Engaige (that’s us) isn’t a ticketing system: it is the e-commerce-native AI support agent that resolves tickets inside your help desk. Keep your helpdesk. Replace the AI. Engaige AI learns from your conversations and inputs, configures your support agent and shows which policies it used. At MR MARVIS, a Shopify Plus brand, Engaige handles over 120,000 questions a year and resolves over 60% of the conversations it’s involved in.
A normal ticket shows what was said. With Engaige, every answer and action also shows why, with the source: which systems it checked, and why it replied as it did. No black box, so you can see, trust and improve it.
Hi, where is my order? It's been eight days and the tracking hasn't moved.
Shopify
Order 48219 · fulfilled
Picqer
Still processing Contradicts Shopify
DHL
Returned to depot · 3 delivery attempts
Settles it: the parcel is not with the customer
Reasoning…
Not deliverable. Reship to a confirmed address, booked in Picqer.
Suggested reply
Your parcel went back to the depot after three delivery attempts, so it will not arrive. I have booked a reshipment to the address you confirmed, arriving Thursday.
The MR MARVIS team reads that reasoning to spot gaps.
Within the AI we can see the reasoning, and how it comes to a response. That shows us where information is missing or unclear, and helps us improve our workflow.
Engaige AI, the layer that configures and improves the agent, does the improving. Engaige goes live in Agent Assist in hours, drafting replies inside your help desk, and nothing closes without a human.
Every reply your team sends becomes training data: Engaige AI compares what your team said with what the agent suggested, learns from the difference, and improves itself under your supervision. You approve the changes. Ticket types go autonomous one at a time. On Shopify, it answers from live Admin API data on orders, customers and inventory.
The support team hub has the full overview, and the Zendesk integration and MR MARVIS show it in practice. Want to see it on your own tickets? Book demo.
Frequently asked questions
What is the difference between a support ticket and a service ticket?
Mostly the name. A service ticket is the same record as a support ticket, named for a service desk. A case is the Salesforce name for it. An incident is different: in ITIL it is an unplanned interruption to a service, while a routine request, such as a size exchange, is a service request.
Is a support ticket the same as an incident?
No. In ITIL an incident is an unplanned service interruption, and in Zendesk the Incident type is one occurrence of a larger problem. Most store tickets are service requests.
What happens when a customer replies to a solved ticket?
In Zendesk, the ticket reopens and goes back to the agent who solved it. Once it is closed, by default four days after solving, the requester can no longer reopen it but can create a follow-up request that references it.
Can an AI agent answer support tickets inside the help desk I already use?
Yes. Engaige works alongside your help desk and answers tickets inside the one you already run. Nothing closes without a human while it runs in Agent Assist.
How can I see why an AI agent answered a ticket the way it did?
With Engaige, every ticket it handles shows its reasoning and the source it used, and you approve the improvements Engaige AI proposes.
