Most teams building AI support agents start with their documentation. That makes sense: the help center is structured, maintained, and written to explain the product. Documentation is necessary, but it is not sufficient. The gap between documentation and actual customer conversations is wider than most people realize until they watch a well-documented AI give a technically accurate but contextually useless answer to a customer who phrased their question in plain human language.
Closed support tickets fill that gap. They are messy, verbose, inconsistently formatted, and full of company-specific terminology. They are also the most accurate record you have of how real customers describe real problems, and how your best agents translate those descriptions into answers that actually resolved things. That combination of signal is hard to replicate from any other source.
What closed tickets contain that documentation does not
A help center article about exporting data explains how to export data. A closed ticket about exporting data shows you that a customer typed "I can't find the download button," that your agent replied "are you in the Settings tab or the main dashboard?" and that the resolution involved a specific sequence of clicks that is not explicitly documented anywhere. That exchange is full of information the AI needs: the natural language pattern for that class of problem, the clarifying question that narrows scope, and the procedural answer that actually worked.
Closed tickets also encode your team's judgment. When a customer described a billing issue in vague terms and your experienced agent recognized it as a specific edge case with a specific fix, that recognition is embedded in the resolution thread. The agent did not document that recognition anywhere. It lives in the ticket.
This is why we built Quack to ingest closed tickets as a primary training signal alongside documentation, not as a supplement. Documentation is canonical, but tickets are contextually rich. The combination produces an AI that can handle questions phrased the way customers actually phrase them.
The signal extraction problem
The challenge with closed tickets as training data is noise. A typical support queue has tickets that were resolved via phone call with no written answer, tickets where the resolution is "user error, explained verbally," tickets that took 14 exchanges to get anywhere, and tickets that were closed after the customer stopped responding. Not all of that is useful signal.
We process closed tickets through a quality filter before they enter the learning loop. The most important criterion is whether a clear, written answer exists in the ticket thread and whether that answer was followed by closure or a positive customer response. Tickets that meet those criteria are strong candidates. Tickets that were closed after a long unresolved exchange are filtered out rather than weighted equally.
We also strip PII from ticket content before ingestion, which is a requirement we built in from day one. What the AI learns from a ticket is the question pattern, the clarifying structure, and the answer logic. Not the customer's name, account ID, or any identifying details.
How recency affects ticket value
A ticket resolved three years ago about a feature that has since been significantly changed is not helpful training data. It is potentially harmful if the AI learns from the old answer pattern and applies it to current questions. Recency weighting matters as much as quality weighting.
Our approach is to apply a time decay curve to ticket signal, where recent resolutions contribute more weight to the learning model than older ones. We do not discard old tickets entirely, because some product behaviors are stable over years and the older tickets contain valuable natural language patterns even if the exact procedures have changed. But a ticket from two years ago contributes less than a ticket from last month, and significantly less than documentation that was updated in the last quarter.
This creates an ongoing feedback loop rather than a one-time training pass. As your team continues to close tickets, the AI's understanding of how customers describe problems and how to answer them continues to update. A team that has been running Quack for a year has a substantially more calibrated AI than they did on day one, without anyone having to manually update training data.
What you should do before connecting your ticket history
If your team uses internal-only notes, emoji-coded resolution tags, or abbreviations that only make sense to people who have been on the team for more than a year, some cleanup work will improve the quality of what the AI learns. The AI cannot distinguish between a helpful abbreviation and a meaningless one. An internal note that says "RFC user, see playbook 3b" is not trainable signal. An agent reply that says "it looks like your account is in read-only mode because of the subscription change from last week. Here is how to restore write access" is exactly what we want.
We are not saying every ticket needs to be reformatted before it can be used. We are saying that if you know you have a subset of tickets with rich written resolutions, prioritizing those for the initial ingestion pass will produce better early results than ingesting everything indiscriminately. Quality first, volume second.
The honest limitation
Closed tickets teach the AI how your team handled questions in the past. If your team has been handling certain question types suboptimally for years, the AI will learn that suboptimal pattern. Garbage in, garbage out remains true here. The value of closed tickets as training data depends on the quality of your previous resolutions.
We run a sample review during onboarding specifically to surface this. If we find a cluster of tickets in a particular category where the resolutions are thin or inconsistent, we flag that for the team before ingesting those tickets. That gives the team the option to review those resolutions and strengthen them before they become the AI's understanding of how to handle that topic.
The learning loop built on closed tickets is only as good as the tickets it learns from. That is a real constraint. It is also the reason that teams who invest in clear written resolutions consistently get better AI performance over time, independent of anything we do on the product side.
