The repeat ticket is the support team's silent tax. A customer submits one because they couldn't find the answer on their own. An agent resolves it, closes it, moves on. The next day, a different customer asks the same question. Same answer. Same close. The cycle repeats, and nobody stops to look at the pattern because every single ticket feels quick to handle.
At a company I support, I pulled three months of ticket data and found that roughly a third of all incoming volume was asking questions we had already answered, often dozens of times each. Average handle time was fine on a per-ticket basis. But stacked across a week, those repeats were consuming close to 30% of total agent capacity. That is not a ticket problem. That is a knowledge problem, and automation is exactly the right tool for it.
Here is the three-stage n8n workflow I built to address it, what each stage does, and what the numbers looked like two months in.
Why Repeat Tickets Survive Even Good Teams
The honest answer is that great agents are very good at resolving tickets fast. That speed is an asset, but it creates a blind spot: the faster you close something, the less pressure you feel to prevent the next one. Institutional knowledge lives in individual agents' heads and in closed-ticket history that nobody searches before responding.
The knowledge base is supposed to fix this, but KB articles are only useful if agents check them before replying, and if the articles exist in the first place. Both are friction-heavy in a busy queue. An agent with fifteen open tickets is not running a search before each response. And the KB team only writes new articles when someone formally flags a gap, which rarely happens in the flow of daily support work.
The workflow I built removes both friction points. It searches for you. It surfaces the resolution before the agent needs to go looking. And it flags gaps automatically, so the KB team sees a prioritised list of what to write next, ranked by how many tickets it would deflect.
Stage One: Classify and Search
Every incoming ticket triggers a webhook in n8n. The workflow takes the ticket subject line and the first 300 characters of the body, passes them to the Claude API with a short classification prompt, and gets back a structured topic label, something like "billing inquiry," "login issue," "feature request," or "account configuration." I keep the taxonomy to around fifteen categories because anything broader starts producing categories that are too narrow to find patterns in.
With that label in hand, n8n makes an API call to our ticket platform to search for closed tickets tagged with the same category from the past 60 days. I filter for tickets that were resolved, not just closed, and that received a CSAT response above a set threshold. The idea is to surface resolutions that actually worked, not just answers that were given.
If the search returns at least two matching resolved tickets, the workflow moves to stage two. If it returns nothing, it moves to stage three and logs the topic as a potential KB gap.
Stage Two: Push the Resolution Back into the Inbox
This is the part agents notice immediately. When the search returns prior resolutions, n8n posts an internal note directly into the ticket, before the agent opens it, with a heading like "Similar resolved tickets" and a brief summary of what worked, pulled from the top two or three matches. The note includes a link to each source ticket so the agent can read the full thread if they want more context.
The critical design choice here is that the note is advisory, not prescriptive. The agent still writes their own reply. They are not copy-pasting the automated note into the customer response. The workflow gives them a head start, not a script. That distinction matters for quality and for customer experience.
In practice, agents started using these notes to cut their research time sharply. For straightforward repeat queries, a ticket that previously took four or five minutes to handle started closing in under two. For more complex issues where the resolution required reading a few prior threads, the note at least pointed them at the right starting place rather than requiring them to search from scratch.
Stage Three: Flag the KB Gap
When a topic comes in without matching prior resolutions, n8n logs it to a shared tracking sheet along with the ticket ID, the topic label, and the timestamp. A second n8n workflow runs every evening and looks for any topic that has appeared three or more times in the last 24 hours without a KB article covering it.
When it finds one, it creates a task in the team's project board, titled with the topic and pre-populated with example ticket IDs so the KB writer can read the actual customer language rather than guessing at it. Tasks are automatically tagged by volume, so the KB team can see which gap is generating the most tickets and prioritise accordingly.
Before this workflow, KB gap reporting was entirely manual. Someone had to notice a pattern, remember to flag it, and find the right person to assign it to. In practice, most gaps never got reported. They just kept generating tickets. The workflow made the invisible visible, and it did it without adding a single task to anyone's daily routine.
What Changed After Two Months
Two months in, the repeat ticket share of total volume had dropped from roughly a third to closer to a fifth. That is not zero, and it was never going to be. Some repeat volume is structural, new customers will always ask the same onboarding questions, regardless of how good the KB is. But the reduction was meaningful enough to shift how the team spent its time.
The KB team, which had previously been working from a vague sense of "what seems to come up a lot," shifted to working entirely from the automated gap queue. Within six weeks they had published articles covering the twelve highest-volume gaps the workflow had surfaced. Seven of those topics had never had dedicated articles before.
Agent feedback was positive, but for a reason I didn't fully anticipate: the internal notes made new agents more confident. When someone joined the team and opened their first queue, they weren't starting cold. They had prior context surfaced automatically. Onboarding ramp time shortened noticeably.
What to Get Right Before You Build This
A few things I would do differently if I were starting from scratch:
- Use a narrow taxonomy from day one. I started with too many categories and had to consolidate after a month. Fifteen or fewer works well. More than that, and the search starts returning false matches.
- Filter by resolution quality, not just closure. Closed tickets include tickets where the customer never replied. Those are not confirmed resolutions and they pollute the suggested notes with dead ends. Filter for CSAT responses or explicit resolution tags.
- Set a minimum confidence threshold on the Claude classification. If the model isn't confident about the category (you can ask it to return a confidence score alongside the label), skip the search and move straight to logging. A misclassification that surfaces the wrong prior resolution is worse than no suggestion at all.
- Keep agents informed about what the workflow does. When agents understand why the notes appear and that they're advisory, they engage with them. When the notes appear with no context, they get ignored or, worse, pasted verbatim into customer replies.
The workflow took about three hours to build and test in n8n. The classification prompt took the most iteration. Everything else was plumbing: webhooks, API calls, a few conditional branches, and a sheet to log the gaps. No custom code, no infrastructure to maintain. The hardest part was deciding what "a good resolution" looked like, and that was a product question, not a technical one.
If your team is handling more than fifty tickets a day, the repeat ticket tax is real whether you've measured it or not. The measurement is a good first step. Building the workflow is a better one.
If you're looking at your own ticket data and want to talk through how a setup like this would work for your stack, reach out. Happy to look at the specifics with you.
Comments