Support Ticket

When requests arrived in a shared inbox, handling one meant replying to it. Send the reply, the thread drops into read mail, done. The problem was that nothing about that arrangement could be counted.

What actually happened looked like this. Two people replied to the same message and the customer got two different answers. Hard questions were forwarded to whoever might know, and when that person came back from vacation four days had passed. Ask how many of Monday's requests were still unanswered and nobody could say, because they were scattered across individual inboxes.

Being uncountable was the expensive part. If you don't know how many requests arrive in a day, you can't tell short staffing from one broken feature, which leaves no basis for choosing between hiring and fixing the product. The support ticket exists to turn a single request into something you can count and hand to someone else. Attach a number and a status and the screen tells you how many are open right now.

A ticket carries six parts.

1. A number. Making the request countable is the whole job of this field, with the side benefit that nobody has to guess which request a conversation is about.
2. The requester and the account. Record only who wrote in, without linking the company, and later you can't tell whether this request came from a large contract or a free workspace. Pagedeck attaches the account at intake and uses it for prioritization, since a free workspace request and an enterprise one look identical in the queue otherwise.
3. Subject, description and reproduction detail: what the person was trying to do, what happened instead, on which screen, and at what time. Missing those, a second-line engineer asks the customer the same questions again while the clock runs.
4. Status — untouched, replied, waiting on customer, closed. Waiting on customer is its own state because mixing your delay with the customer's silence makes support speed unmeasurable. You need that split to read first response time — the gap between a request arriving and a human answering — correctly.
5. Owner and priority. Priority follows a rule rather than a feeling. Pagedeck reads plan tier and blast radius together: nobody at an enterprise account can log in is top, one person on a free plan seeing a broken layout is bottom. Everything between those two is decided by how many people are blocked, not by who asked loudest.
6. Category tags. A fixed set of buckets by feature or by cause, one of which the agent picks. Tags exist to be counted. Forty tickets on the same tag in a month is not a stack of requests, it's a product task, and it moves into voice of the customer (VOC) — the practice of gathering what customers say and feeding it into the product.

The conversation history travels attached to those six fields. That an owner can change while the entire thread follows is the point where a ticket parts ways with an email thread.

The customer writes the first line. What they send often isn't yet a workable ticket — requests that read simply "it's not working" are common — so the real authoring work is an agent asking back to fill in part 3. Pagedeck fixed those follow-up questions at three: what were you trying to do, what happened, and when did it last work.

One problem per ticket. If a customer's single email raises three things, it becomes three tickets. Left merged, two get solved and the remainder sits in a ticket that is neither closed nor open, and the statistics count it once. The customer loses track of which of their three questions is still live.

There are five readers. First-line agents intake and answer. Under tiered support — a structure splitting handling into first and second line by difficulty — second-line engineers read the reproduction detail before anything else. Theo reads what came over as a product defect. Mia reads the tag counts. Sofia reads the open count on accounts approaching renewal, and any account with more than five open clears before a renewal conversation starts. Those five readers each want a different field, which is why a ticket carries more than a conversation does.

The customer is a reader too. Expose the number and the status to them and the "any update?" requests drop away. While an answer is slow, what frustrates a customer most isn't the delay itself but not knowing whether anyone received the thing.

"Can you give me the ticket number? I want to check whether it's the same one we answered yesterday."

The number is what a conversation anchors to.

"Move this one to waiting on customer. We asked for logs and it's been two days."

Marking the clock as stopped on our side rather than running.

"Forty tickets on the permissions tag this month. Support isn't where this gets fixed."

Ticket counts producing a product task.

At Pagedeck the untouched queue gets read in priority order every morning, and every item in it gets a first reply inside 30 minutes. Items with no answer yet still get one saying it arrived and what is being checked.

Once a week the closed tickets get a second pass. When the same customer has opened three or more on the same tag, that reads as a signal to look at their configuration or their training rather than to keep answering individually. That review did more to bring down resolution time — how long a request takes to finish — than anything else.

The most common misreading is that fewer tickets is better. Fewer requests looks like a product with fewer problems, so the inference is easy. But this number falls if you simply narrow the intake. Bury the contact button at the end of a help article and ticket volume halves while the number of customers leaving without a word goes up. A complaint that never got filed hasn't disappeared, it has just stopped being visible. Reading volume next to the share of requests answered inside the target keeps that trap visible.

Treating tickets as an internal support record is the other frequent mistake. It's a work tool, so it seems like only the people doing the work need it. But a pile of tickets carrying tags and accounts is the cheapest input a product team has for deciding what to fix next quarter, and at renewal it is the record of how this account was treated all year. Kept internal, nobody has a reason to tag carefully, and six months later half of them read "other" and nothing can be counted at all.