When an AI customer service agent gives a customer the wrong answer, the conversation that follows is nearly always about the AI. Was it the model? Should we have tuned it? Is the technology just not ready?

It is usually none of those. The AI answered accurately from a document that was wrong, or ambiguous, or one of three versions of the same policy written by different people in different years. The technology did exactly what it was asked to do with the material it was given.

This is an unglamorous conclusion, which is probably why it gets skipped. It is also the single biggest determinant of whether AI answering works, and it is entirely within your control.

This article covers what an AI knowledge base actually is, why self-service still fails so often, the four things that make content answerable, and how to find out which questions your content is not covering.

What an AI knowledge base actually is

There are two different products that get called the same thing, and the difference matters before you buy either.

A customer-facing help centre is a set of articles people browse. It has search, categories, and a URL customers visit. Zendesk, Intercom and Freshworks all sell one.

A knowledge source is content an AI answers from. Customers never see it directly. They ask a question in a conversation and get an answer composed from whatever the AI retrieved.

The same articles can serve both purposes, but they are not the same thing and they are not interchangeable. A help centre is a destination. A knowledge source is an input.

This article is about the second, which is what Cue does. Cue AI Agents answer from your indexed website pages and uploaded documents, in PDF, DOCX, PPTX and JSON. Cue does not provide a customer-facing help centre or self-service portal. If you need one of those, the full help desk platforms are where to look.

Why self-service still fails

Gartner found in 2024 that only 14% of customer service issues are fully resolved in self-service. For issues customers themselves rated as very simple, it rises to 36%.

Sit with the second figure for a moment. On problems the customer considered easy, self-service failed nearly two thirds of the time.

That is not a technology ceiling. Simple questions are the ones a well-written answer resolves completely. The gap between 14% and 36%, and between 36% and something respectable, is mostly writing, structure and maintenance.

Which means the interesting question is not whether to add AI to your self-service. It is whether the content underneath would survive contact with a customer.

What the AI is actually doing with your content

Worth understanding, because it explains the failure modes.

When a customer asks something, the AI searches your indexed content, retrieves the passages that look relevant, and composes an answer from them. If the request is ambiguous it can ask a clarifying question. If it cannot resolve the query it hands back with a reason.

Three consequences follow from that description.

It answers from what it retrieves, not from what it knows. There is no general understanding of your business filling gaps. If the answer is not in the content, it is not in the answer.

Contradictions do not resolve themselves. If two documents disagree about your returns window, retrieval will surface one of them. Which one is not something you control paragraph by paragraph.

Currency depends on you. Answers are only as current as the maintained knowledge source. Cue's documentation does not confirm how or how often website sources re-index, so do not assume a page edit propagates immediately. If a policy changes, treat updating the source and confirming the AI reflects it as two separate tasks.

The four things that make content answerable

Content written for humans to browse is not automatically content an AI can answer from. Four differences do most of the work.

One answer per question, in one place

A recurring problem in real knowledge bases is not missing content. It is three partial answers in three places, none complete and none marked authoritative. Consolidate to one, and delete rather than archive the others where you can.

Written as an answer, not as a policy

Policy language describes rules from the organisation's point of view. Answers address the customer's question in their words. "Refunds are processed within 14 days of receipt of the returned item" is a policy. "You will get your refund about two weeks after we receive the item back" is an answer. The AI can work with either; only one produces a reply a customer understands.

Current, with someone accountable

Every document needs a name attached and a review date. Not a process, a name. Content decays silently and the only reliable defence is a person who notices.

Explicit about what it does not cover

Content that states its own limits helps the AI recognise when to hand over. A document saying "this applies to standard UK orders; for international returns see the separate policy" gives retrieval something to work with. A document that simply omits international orders invites a confident wrong answer.

Start with the questions customers actually ask

The usual approach to a content audit is to review what you have. That tells you about your content and nothing about your customers.

The better starting point is the list of questions coming in. In Cue, Insights reports the questions arriving most often. Take that list, and check it against what your content covers.

This tends to surface three things. Questions with no content at all, which are the easy wins. Questions with content that is technically present but unusable, which is the biggest category. And questions being asked far more often than anyone expected, which often points at something upstream in the product or the buying journey.

Doing this comparison is manual work. It is also the highest-value hour available to anyone deploying AI answering, and few teams do it before going live.

What good source content looks like

A worked example. Here is a returns policy as most organisations write it:

Returns Policy. In accordance with our terms of sale, customers may initiate a return within the applicable returns window. Returns are subject to inspection. Refunds will be processed in accordance with the original payment method. Certain exclusions apply as set out in Section 4.2.

An AI can retrieve that and will produce an answer that is accurate, vague and useless. Now the same policy written to be answerable:

Returning something you bought from us. You have 30 days from delivery to start a return. Contact us and we will send a returns label. Once we receive the item we will check it is in resalable condition, and your refund goes back to the card you paid with, usually within 5 working days of us receiving it. Custom orders and personalised items cannot be returned. Sale items can. This covers UK orders only; international returns work differently and are covered separately.

Same policy. Specific numbers, no cross-references, plain language, explicit about exclusions and scope. The second version can answer a customer's question. The first can only describe the existence of a rule.

There is more on structuring this well in our guide to building a knowledge base for support.

Where this stops working

Content quality solves a specific class of problem. It does not solve everything.

AI answering works on questions whose answers are written down. It does not work on questions requiring live data, because Cue AI Agents cannot look up an order status or check a record. Those need an explicit step in the surrounding flow.

It also does not help with judgement, exceptions or upset customers. No amount of content quality automates a decision. We cover the boundary in what to automate and what to escalate.

And it does not remove the maintenance burden. It relocates it. You are no longer maintaining bot paths, you are maintaining content, and content that nobody owns degrades just as reliably as a flow nobody edits.

If you are about to deploy AI answering, the highest-value preparation is not configuration. It is taking your most frequent customer questions and honestly assessing whether your existing content answers them well enough to be read aloud to a customer.

Often the answer is no, and that is a fixable problem rather than a technology one.