Support Ticket: What It Is, How to Write One, and Why It Exists

A support ticket is a record of one customer request or problem, with a unique reference number, that a support team uses to track the issue from the moment it is reported until it is resolved. It holds who asked, what it is about, the full conversation, a priority and a current status.

This guide covers the ticket itself: its fields, its statuses, how to write and triage one, and how to measure tickets against orders. If you are choosing software instead, start with our guide to the automated ticketing system.

As CEO at SurfStitch and then P.E. Nation I had customer service report straight to me, and here is my view: in a store, the ticket is usually the last step of something that started days earlier. A payment sat in review, a stock count was wrong, a parcel stopped scanning. The shopper noticed and wrote in. So I treat a support ticket as evidence first and as work second. Every order is a promise. Keeyu keeps it.

What is a support ticket?

A support ticket, also called a case, an incident or a request depending on the tool, is a running record of a single customer issue, its status and the data needed to resolve it. Wikipedia traces the name to the small cards support staff once filled out and slotted into a wall-mounted planning board, one card per request.

An "open ticket" has been logged and not yet resolved. "Raising" a ticket means reporting an issue through a form, email, chat or portal so it gets a reference number and lands in a queue. The software that issues the numbers and holds the queue is a support ticket system, which in most stores is a helpdesk such as Gorgias or Zendesk.

Here is what most definitions leave out. Some tickets are genuine questions: does this run small, can I change my delivery address. Many others exist only because something went wrong that the business could have seen first. Both deserve a good answer, but only the second kind can be removed at the source, and you cannot remove what you never label. That is the line on our about page: "Helpdesk manages complaints. Keeyu prevents them."

What goes into a support ticket

A support ticket contains a ticket ID, the requester's contact details, the order number, an issue category or tag, a description, a priority level and a status, which is Shopify's baseline list for ecommerce. Together they let anyone pick the ticket up cold without asking the shopper to repeat themselves.

The last row is the one I would add to every helpdesk tomorrow. The category tag records what the shopper said ("where is my order"). The root cause records why they had to say it: the order failed to sync to the warehouse, the item was oversold, the tracking number never reached the storefront, a return was never processed. Tag every where-is-my-order ticket with its root cause first.

At P.E. Nation I kept this field in my head: a 7:00 a.m. read of yesterday's customer service problems with Tracy, then a walk to the team that caused each one (the full routine). A required six-value dropdown, set by the agent who closes the ticket, records the same thing on every ticket and makes it countable.

The support ticket lifecycle

The support ticket lifecycle is the sequence of statuses a ticket moves through from creation to close, and each status tells the team who acts next. Names vary by tool; most helpdesks use some version of these.

The status I watch first is on hold. In ecommerce, "on hold" usually means the answer lives in someone else's system, a warehouse that has not picked or a carrier that has not scanned, so it is a direct count of operations problems sitting in the support queue.

The second thing I check is where the clocks start. Every one of them starts when the shopper reports the problem, not when the problem happened. A stuck order can sit for days before its ticket is created, and none of that time shows up in first response time. See first response time vs first detection time.

To see whether tickets are being ended or only closed, group reopen rate by root cause rather than by agent, and count orders that generate more than one ticket. If "carrier stalled" tickets reopen far more often than sizing questions, no agent coaching will move the number.

How to write a support ticket

A good support ticket states the order, what happened, what was expected, the evidence and what the person wants, so it can be resolved without a second message. Shoppers and support leads building a contact form can use this structure:

• Order number and the email used at checkout
• What happened, in one or two sentences ("Tracking has not updated since March 3")
• What you expected ("Delivery by March 6, as shown at checkout")
• Evidence: tracking link, photo of the damage, payment confirmation
• What you want: replacement, refund, exchange or an update by a date

Make the order number a required field on the contact form and you save a round trip on every ticket.

The promised date, tracking number, last scan and amount charged already sit in Shopify, the carrier feed and the payment provider. I keep the shopper's required fields to what only they know, photos and what they want, and have the agent pull the rest.

Agents write tickets too, as internal notes. A good internal note records what the systems showed, what was done and the root cause tag, for example: "Order paid, not sent to the warehouse, sync error at 2:14 p.m. Pushed manually, ships today. Root cause: fulfillment sync."

How to reply to a support ticket

Answer from the order record, not from the message. Check the order in Shopify, the warehouse and the carrier feed before writing, then say what you found, what you have done and the date the shopper will see a result. For a stalled parcel: "The carrier has not scanned your order since March 3. I have opened a trace and a replacement ships today, so you will have it by March 9 either way."

How to triage and prioritize support tickets

Ticket triage is reading each new ticket, classifying it, setting its priority and routing it to the right owner. The standard rule is impact multiplied by urgency: how many shoppers or how much revenue is affected, against how soon harm happens if nobody acts. A polite shopper whose parcel is lost outranks an angry one asking about sizing, which is why sentiment-led routing goes wrong.

Merge tickets that share one cause

When one cause produces many tickets, treat it as one issue with many tickets attached. Wikipedia's support ticket entry describes the practice: each issue is unique, and duplicate reports are in most cases amalgamated into a single active issue. If forty shoppers write in because one warehouse batch missed its cutoff, fix the batch once, send one message to all forty and close them together.

Triage before the queue

The best triage happens before the queue. At Budgy Smuggler, the operations lead logs in to see "what's my team missed", because Keeyu trims everything down to what is a problem. That is triage applied to orders instead of messages. The Budgy Smuggler case study has the detail.

Types of support tickets in ecommerce, and the failure behind each

Shopify groups ecommerce support tickets into nine types: order status and tracking, delivery and fulfillment, returns and exchanges, damaged or incorrect items, payment and checkout, account and login, technical support, product information, and subscriptions. The table covers the seven that matter most for a store's operations. Put the operations failure next to each type and you can see which ones a better reply solves and which ones only an upstream fix can.

In each of the first five rows the store's own systems knew before the shopper did: the warehouse that never received the order, the carrier feed showing a stalled parcel, the payment provider holding a charge. We cover the most common of these in the post-purchase issues behind most tickets, and the order-status class in depth in our guide to where is my order tickets.

None of this is a case against a helpdesk. The helpdesk is the right tool for the conversation, and Keeyu integrates with Gorgias and Zendesk rather than replacing them. The point is where the fix belongs: product questions stay in the helpdesk, and the top five rows get caught in operations before they turn into tickets. Every order is a promise. Keeyu keeps it.

How to measure support tickets: tickets per 100 orders

Tickets per 100 orders is the number of support tickets created in a period divided by the number of orders placed in the same period, multiplied by 100. It turns ticket volume, which rises with sales, into a comparable rate.

• Tickets per 100 orders = tickets created / orders placed x 100
• Cohort version, cleaner: tickets about orders placed in week W / orders placed in week W x 100, so a late spike is charged to the week that caused it
• By reason: tickets with root cause R / orders placed x 100. The reasons add up to the total
• Preventable share = tickets whose root cause is an operations failure / all tickets x 100

There is no single normal ticket-to-order ratio in ecommerce. For reference, Gorgias publishes vertical medians from its Ecom Lab data: apparel and accessories brands at $10M GMV saw 22 tickets per 100 orders in March 2026. Gorgias adds that a high ratio is not a problem to fix, because it reflects how complex the product is and how much shoppers need to ask. I agree for product questions. Order failures are different, which is why the total needs splitting.

Run a 100-ticket root-cause audit

Pull your last 100 closed tickets and set the root-cause field from the table above on each one: payment, fulfillment, shipping, delivery, returns or none. Then convert each count into a rate against orders. Here is a worked illustration with round numbers, not a customer's data, for a store with 8,000 orders and 1,600 tickets a month:

This store's headline rate is 20 per 100 orders, and 14.4 of those are orders where an operations step broke, a preventable share of 72%. Put that figure on the wall split by step, because each row names the team that owns the next fix, and a faster reply will not move any of them.

Read the rate as a floor. In my experience operational issues usually run at twice the number of tickets received; the shoppers behind the other half hit the same broken step and never wrote in. The root-cause field is the only part of the ticket that speaks for them, because fixing the step fixes their orders too.

How to prevent support tickets at the source

Ticket prevention means finding and fixing the operations failure behind a would-be ticket before the shopper sees it, so there is nothing to write in about. It is a different job from deflection, which answers the question faster after the shopper has already had to ask.

Helpdesk metrics grade how well a team handles a ticket once it exists, and that is worth grading. They cannot count the tickets that never had to exist, which is the number this guide has been building toward. On one discovery call, a prospect told us success was clearing the tickets every day. Our answer was to imagine those tickets just evaporated because you fixed the root cause of what could become a ticket. Early on, when we only showed retailers their problems, some told us it created more work for them, because businesses were incentivized to fix tickets rather than prevent them. That is why we built Keeyu to automate the resolution and not just surface the problem.

Waiting for complaints puts the brand on the back foot, always putting out fires. If you find the issue in real time, you can front-foot it with the shopper and still create a good experience when things go wrong. This is the job of proactive e-commerce operations, and it runs in three steps. Detect. Decide. Act.

• Detect. Spot the break in the store's own data when it happens: the order that never reached the warehouse, the parcel stuck at a depot, the refund that never triggered.
• Decide. Choose the fix the ticket would eventually have asked for, using the same priority rules as the triage table: reship, refund, correct the address or set a new date.
• Act. Carry it out where the order lives and make sure the shopper hears first, so the conversation that would have opened a ticket never starts. Product questions still go to your team.

Keeyu gets shoppers what they want, on time, as promised. Start with the root-cause audit above, then track tickets prevented by root cause alongside the rate. The product page shows how detection and resolution run. If you want to see it against your own ticket mix, book a demo. Every order is a promise. Keeyu keeps it.

• 1. Wikipedia, "Support ticket", https://en.wikipedia.org/wiki/Support_ticket. Definition of a support ticket as a running report on an issue and its status, the card-based origin of the name, the open, pending and reopened workflow, and the practice of amalgamating duplicate reports into a single active issue.
• 2. Shopify, "Support Ticket: What It Is and How It Works (2026)", https://www.shopify.com/blog/support-ticket. Fields an ecommerce ticket includes (ticket ID, order number, category or tag, priority, status), status stages, and the nine common ecommerce ticket types.
• 3. Gorgias, "14 Customer Service Metrics Every Support Team Should Be Tracking", https://www.gorgias.com/blog/customer-support-metrics. Median of 22 tickets per 100 orders for apparel and accessories brands at $10M GMV (Gorgias Ecom Lab, March 2026), and its view that a high ratio is not a problem to fix because it reflects product complexity.