What Good Support Data Looks Like

Support is the only part of a business that hears from customers continuously, unprompted, about things that are not working. It is the richest source of product information any company has, and it is usually reduced to two numbers: how many tickets, and how fast were they answered.

Both numbers are real. Neither answers a question anyone would act on.

Why volume and speed mislead

Ticket volume is treated as a workload measure and read as a quality measure, which are not the same thing and often point in opposite directions.

A product with a confusing feature generates tickets. Fix the confusion and volume falls — good. But volume also falls when customers give up asking, when the help centre absorbs the question without resolving it, and when people simply use the product less. A falling ticket count is ambiguous, and it is usually reported as a win.

Response time has the opposite problem: it is unambiguous and only loosely connected to whether anyone was helped. A fast reply that does not resolve the issue produces a second ticket, which improves neither the customer's experience nor, in most reporting, the numbers — the second ticket is counted as a fresh, promptly-answered request.

Both metrics measure the support function. Neither measures the thing support is telling you about.

The three questions worth answering

What are people trying to do when they contact us? Not what they asked — what they were attempting. Someone asking how to export a report is trying to give a number to somebody else. That is a different problem from the one they described, and the useful response might be a sharing feature rather than a better export.

What did we have to explain that should have been obvious? Every explanation is a small piece of evidence about the interface. A support team explaining the same thing repeatedly is a design finding with a queue attached.

What did we not fix? Most support systems have no honest category for "resolved by telling the customer to work around it". These get closed as resolved, and the workaround becomes invisible institutional knowledge — until a new customer hits it and there is nobody who remembers.

The one field that changes everything

If you add nothing else, add a short, structured reason on close. Not free text — a small, fixed list, agreed by the team, of the actual causes: unclear interface, missing feature, defect, data problem, worked as intended but unexpected, external cause.

Six to ten options. No more, because a list nobody can hold in their head gets filled with whichever option is at the top.

That single field converts support from a queue into a source of evidence. It lets you ask which cause generates the most contact, which is the only version of the question that leads to a decision.

Note the discipline it requires. The temptation is to capture more — customer sentiment, effort scores, categories with sub-categories. The rule that keeps this usable is not collecting data speculatively "in case it is useful later" [1]. One field that is always filled in accurately beats six that are filled in approximately.

Support notes are personal data, and they are candid

Here is the part that is easy to overlook: support records are among the most sensitive data a business holds, and among the least governed.

They contain what a customer said when they were frustrated. They frequently contain what a colleague thought about that customer, written quickly, for internal eyes. They sometimes contain details a customer volunteered in explaining their situation — health, finances, family circumstances — that nobody asked for and nobody deliberately stored.

Two things follow, and neither is optional.

Those individuals have the right to receive the personal data concerning them "in a structured, commonly used and machine-readable format" and to transmit it elsewhere [3]. A support history is personal data. If somebody exercises that right, the internal note about them is in scope, and a note written on the assumption that nobody outside would ever read it is now a problem.

And retention needs to be a decision rather than a default. Ours is stated explicitly for deleted data — a 30-day recoverable window, then 60-day retention for legal and forensic needs, then hard-purge [2] — and the value of stating it is that it can be checked. Support archives that grow forever accumulate risk in proportion to their age, and their usefulness declines much faster than their sensitivity does.

The practical guidance for the team is simple and worth saying out loud: write internal notes you would be comfortable showing the customer. It costs nothing, and it is the only version of the rule that survives contact with reality.

What to do with the evidence once you have it

The failure that wastes all this effort is collecting good support data and routing it nowhere.

Support sees a problem forty times. Product hears about it once, secondhand, in a summary. The frequency — the single most valuable part of the signal — is lost in transmission.

The fix is structural rather than motivational. The close-reason data should go, unfiltered and regularly, to whoever decides what gets built, as counts rather than anecdotes. Forty instances of "unclear interface: billing screen" is an argument. One story about a frustrated customer is a mood.

The tickets that never existed

There is a category of support data that no support system captures, and it is often the most important: the problems people had and did not report.

Most customers who hit a difficulty do not contact you. They try once more, give up, work around it, or quietly use the product less. Only a small fraction convert their frustration into a ticket, and that fraction is not random — it skews heavily towards confident, technically comfortable people who expect to be helped.

The practical consequence is that your ticket data systematically over-represents one kind of customer and under-represents everyone else. Fixing the top ten reported issues can therefore leave the majority of actual friction untouched, while the reports keep confirming that you are fixing the right things.

Two cheap corrections help. Ask a handful of customers directly what they found awkward, in a conversation rather than a survey, and treat their answers as equal in weight to a ticket. And watch where people stop — a form abandoned halfway, a feature opened repeatedly and never completed — because the silent abandonment is the unreported ticket, and it is visible if anyone looks.

A reasonable first quarter

Add the close-reason field with fewer options than feel sufficient. Report the counts monthly to whoever prioritises work. Pick the largest cause and fix it. Then check whether that cause's count actually fell.

That last step is the one that gets skipped, and it is the only one that tells you whether any of this worked.