When resolution accuracy is lower than expected, the first assumption is usually that the model is underperforming. That is almost always wrong. In our experience deploying Replixa across different support configurations, the model's ability to generate accurate responses is not the binding constraint. The binding constraint is whether the model has access to content that actually answers the customer's question.
We have seen resolution accuracy vary from 61% to 96% across deployments with comparable ticket volumes and similar Tier-1 ticket distributions. The biggest variable separating those outcomes is not the underlying model, the prompt structure, or the integration configuration. It is KB quality. Specifically: coverage gaps, outdated articles, and structural chunking problems that prevent the retrieval layer from surfacing the right content even when that content exists.
If you are preparing for an AI support deployment or trying to diagnose why your resolution rate is lower than expected, this is where to look first.
The three KB failure modes
Coverage gaps are the most obvious problem. Your KB simply does not have an article covering a question type that appears frequently in your ticket queue. The model retrieves the closest available content, which may be loosely related but not directly applicable, and either generates a response with low confidence (correctly triggering an escalation) or generates an imprecise response that technically answers the surface question but misses the nuance the customer needed.
Coverage gaps are easy to find once you know to look for them. Run a topic clustering analysis on your last 90 days of tickets. Group tickets by resolved intent. Then check: does your KB have an article that directly addresses each intent cluster? If you have 150 tickets asking about export file formats and your KB article on exports covers the export workflow but not the specific file format options and their compatibility, you have a coverage gap. The retrieval system will pull that export article, but it cannot answer the specific question from that content.
Outdated articles are more dangerous than gaps because they produce confident incorrect responses. An article that describes a feature interface from 18 months ago, before a major product redesign, will retrieve cleanly and the model will synthesize a response from it confidently. That response will describe navigation paths and settings screens that no longer exist. The customer will be confused, the agent will need to correct it, and if this happens enough your team will distrust the system entirely.
Most KB maintenance processes catch this for major releases but miss incremental UI changes, renamed settings, deprecated features, and new billing plan structures. These are exactly the ticket types that generate high-frustration customer interactions — the customer followed the instructions from the article and it did not match what they see in the product.
Chunking and structure problems are the most technical failure mode and the least intuitive. When KB articles are ingested for retrieval, they are split into chunks. The retrieval system finds the chunk most semantically similar to the ticket content and passes it to the model. If your articles are structured in a way that buries the specific answer deep in a long article, the relevant chunk may score lower in semantic similarity than a more superficially related chunk from a different article. The model ends up working from the wrong source.
How to run a KB audit before deployment
Before deploying Replixa — or any AI resolution layer — we walk through a structured KB audit with every customer. The process has four steps.
Step one: export your ticket data for the past 90 days and classify tickets by intent. You want the actual intents, not just categories. "Billing" is a category; "billing — invoice date mismatch for mid-cycle upgrade" is an intent. The intent classification should be fine-grained enough that you can check whether a specific KB article answers each one. For a typical SaaS product, you will find 30-60 distinct intents that appear with meaningful frequency.
Step two: for each intent, check whether a specific KB article directly addresses it. Not "loosely covers the topic" — directly answers the question a customer with that intent would ask. Mark intents with direct KB coverage, partial coverage, and no coverage. Partial coverage means the article exists but is missing the specific detail that makes the response actionable.
Step three: for each article that will be part of the resolution KB, check the last-modified date against your product changelog. Any article not updated since a major product release should be reviewed manually. Prioritize articles covering navigation, settings screens, billing plan structures, and any feature that has changed in the past year.
Step four: review article structure for retrieval optimization. Long articles with multiple sub-topics should be split into focused single-topic articles. Articles that answer "how do I do X" should have the actual steps near the top, not buried after three paragraphs of context. Each article should cover one primary question type. If an article answers both "how to export" and "what file formats are supported," consider splitting those into separate articles so each retrieves cleanly on its own.
The coverage gap fill is not a writing project
When teams discover they have 15-20 coverage gaps, the response is usually to schedule a KB writing sprint. That is the right instinct, but it often stalls because writing support documentation feels like slow work. There is a faster path: use your existing ticket resolution history.
Pull your closed tickets for each intent cluster that has a coverage gap. Find the tickets that were resolved with CSAT scores of 4 or 5. The agent's response in those tickets is already a draft KB article. Extract the resolution text, clean it up for a first-person customer voice, remove the ticket-specific context, and you have a functional article in about 20 minutes of editing work rather than 2 hours of writing from scratch.
This approach has a second benefit: the KB articles you produce are grounded in real customer language, not internal product terminology. When customers write tickets using their words ("why did you take money out twice") and the KB article uses product terminology ("billing duplication recovery process"), semantic retrieval may not surface the article correctly. Articles written from real ticket resolution text use the language customers actually use, which improves retrieval accuracy.
Maintaining KB quality as a continuous practice
The hardest part of KB quality is not the initial audit — it is the ongoing maintenance cadence. KB articles decay in accuracy every time the product ships a change, and most teams do not have a process to systematically catch that decay.
The practice we recommend is a monthly escalation-to-KB review. Pull the previous month's escalation tickets — tickets that were classified with high confidence but routed to humans because the resolution logic required it, or tickets where the automated response received a low CSAT rating. Review the ones where the issue was a KB failure rather than a logic or integration failure. Those are your maintenance candidates.
We are not saying you need a dedicated KB writer on staff to do this well. We are saying the practice needs to be someone's explicit responsibility. Even 90 minutes per month reviewing escalation patterns and updating or adding articles makes a material difference in resolution accuracy over time. KB quality is not a one-time pre-launch effort — it is a continuous maintenance task in the same way that keeping your product documentation accurate is a continuous task.
What good KB quality looks like in practice
A support operation with a well-maintained KB looks like this: 90%+ coverage across your top 40 intents, no article with a last-modified date more than one product release cycle old, single-topic articles averaging 200-400 words each, and a monthly review cycle tied to the escalation log.
When the KB is at this quality level, resolution accuracy on Tier-1 tickets typically runs 88-95%. When there are significant gaps or outdated articles, the same model on the same ticket types runs 60-75%. That 15-30 point accuracy gap is entirely attributable to the KB, not the model. The model can only generate correct responses from correct content. Give it stale or absent content and it will hallucinate or escalate. Give it accurate, current, well-structured content and it performs.
The implication is practical: before you spend time optimizing model prompts, confidence thresholds, or escalation logic, do the KB audit. It is less exciting work than model tuning, but it will move your resolution accuracy more than almost anything else you can do.