Suggesting Knowledge Articles Instead of Generating Answers

Wednesday, 10:20, at Ashgrove Housing. Owen is five weeks into the desk. He opens ticket 6190 from Priya, a housing officer: "The tenancy app on my tablet keeps saying my session has expired. Every few minutes. Started yesterday." The assistant offers him two things. The first is a generated answer, four tidy steps: close the app, clear its cache, check the tablet's date and time, reinstall if the problem persists. The second is a suggestion: an existing article in the agents-only part of the knowledge base. Its title is "Tenancy app: session expires every few minutes on tablets". Farah wrote it four months ago. Owen opens the article. It says the app checks the tablet's clock against the server's. A tablet whose time zone has been changed to the wrong region will drift by an hour and fail every check. The article says the fix is to set the time zone back and restart the app, with a screenshot of the exact setting. There is a user-facing version linked at the bottom. Owen sends Priya that version, and the ticket is closed in four minutes. The generated answer had the right step in it, third of four, with no explanation and two steps that would have wasted her morning first.

A suggestion is the assistant pointing at something that already exists, an article, a past ticket, a template, because the new ticket resembles it. Generation is the assistant composing a fresh answer from what it knows in general. Both are text tasks, both arrive in seconds, and they are not the same kind of thing. A suggested article was written by a person, tested by a person, has a name on it and can be opened. A generated answer has none of those properties and is usually more confident. This article is part of our AI Assistants in Support series. It is about why suggestion is the quiet use of an assistant that reliably pays, what it depends on, and how to measure it.

It covers why suggesting beats generating, what a suggestion looks like at the desk, and the dependency on knowledge base quality. Then come the four kinds of wrong suggestion and what each teaches, and the technician's habit of opening the article before sending it. Next is measuring whether suggestions get used, with a worked month, and feeding the results back into the knowledge base. A short war story and the suggestion scorecard to copy come last. The case where the assistant answers the requester directly from the knowledge base, with no technician in between, is A Knowledge Base Chatbot Without a Vendor Cloud.

Suggest, Don't Generate

Three properties make a suggested article better than a generated answer. All three are about where the words came from rather than how good they are. The first is provenance. An article has an author and a date. When it is wrong there is someone to ask and something to fix. A generated answer has no author. Nobody has ever been able to ask a generated answer what it was thinking. The principle that every article carries a name, and why that name is the whole maintenance system, is in Every Article Has a Name on It.

The second is checkability. A suggestion can be verified by opening it and reading whether the symptom at the top matches the ticket. This takes a minute and needs no expertise. A generated answer can only be verified by knowing the answer already, or by trying each step on the requester's device. That is the work the answer was supposed to save. The reviewer of a generated fix is doing diagnosis; the reviewer of a suggestion is doing matching. Matching is what a junior technician can do well in their first week.

The third is compounding. Every time a suggestion is used, the article's usage count rises, its last-used date moves, and the desk learns which articles earn their place. Every time a suggestion is wrong, the desk learns which article is stale, which pair are duplicates, and which gap has no article at all. Generation teaches the desk nothing; the answer vanishes into the ticket and the next identical ticket gets a fresh, equally anonymous one. A desk that suggests gets a better knowledge base every month. A desk that generates gets faster at being generic.

None of this makes generation useless. Drafting a courteous reply around a suggested article is generation, and a good use of it, covered earlier in this series. The rule is about the fix, not the wrapping. When the question is "what should the requester do", prefer the answer somebody on your desk already wrote and tested. Let the assistant find it rather than invent it.

What a Suggestion Looks Like at the Desk

Suggestions arrive in three places. The first is beside the technician while they work the ticket: "this ticket resembles article 41 and tickets 5118 and 5902". That is the case in Owen's story and the most common one. The second is in front of the requester before they submit, when the form or the portal shows articles that match what they have typed so far. That is deflection, the answer arriving before the ticket. It has its own series beginning at Deflection at the Point of Submission. The third is the list of similar past tickets. That is a suggestion of a different kind. It is not an answer but evidence that this has happened before, and to whom, and what was done.

All three work by comparing text with text. The assistant reads the new ticket's words and finds the articles and tickets whose words are closest. This has a consequence that is easy to miss. The quality of the suggestion depends on the quality of the ticket's wording as much as on the knowledge base. "Tablet thing broken" matches nothing useful. "Tenancy app says session expired every few minutes" matches Farah's article directly. The desk's work on getting better tickets from users turns out to be work on suggestion quality too. That is a pleasant surprise for something that was already worth doing.

The suggestion is offered, never applied. The technician opens it, decides it fits, and sends it or does not. Suppose a tool attaches the suggested article to the reply without a person reading it. It has turned a suggestion into a generated answer with a name on it. That is the worst of both. Now the article's author appears to have said something about a ticket they never saw.

The Dependency on Knowledge Base Quality

A suggestion is exactly as good as the article it points to, and no better. This is the single fact about suggestion that desks most often learn the expensive way. An assistant does not read your articles for truth. It reads them for resemblance to the ticket. An article might be stale, describe last year's procedure, duplicate a newer article, or have no owner. It will be suggested with the same confidence as the best article in the base, because it resembles the ticket just as well. The assistant amplifies the knowledge base. A good base becomes a good base that is found faster. A bad base becomes a bad base with a louder voice.

Visibility is the quality property that bites first. Most knowledge bases, QuerySolv's included, separate articles visible to agents only from articles visible to everyone. The two are written for different readers. The agents-only article has server names and the real cause. The public one has three steps and a screenshot. A suggestion to a requester must point only at the public kind. Sending a requester a link to an agents-only article gives them either an error page or a document that names your internal systems. Both are failures of the same check. The technician did not open the suggestion before sending it. The split between the two kinds of document, and what must never appear in the user-facing one, is in the Technician Docs vs User Docs series.

Before leaning on suggestions, run the knowledge base health check in A Knowledge Base Health Check, and take its findings as a forecast of your suggestion quality. Forty articles with owners and review dates will produce suggestions worth trusting. Four hundred articles, half of them untouched for years, two called "Printing" and one called "Printers", will produce suggestions that are confidently wrong about one time in four. That is often enough to teach technicians to ignore all of them. A knowledge article left alone does not stay still. It stays confident, and the assistant believes it.

Four Kinds of Wrong Suggestion

A wrong suggestion is one the technician opened and did not use. There are four kinds, each pointing at a different repair. The near miss is the right subject and the wrong case: the article about session expiry on laptops, suggested for a tablet. It teaches the desk that the article's title or recognition test is not specific enough. The fix is a sharper first paragraph saying what the article is not about. The stale article is the right case and the wrong procedure: the article was correct when written and the procedure has since changed. It teaches the desk that the article's owner did not hear about the change. The fix is the article's review date and a line in the change routine that asks "which articles does this change touch?"

The duplicate is two articles about the same thing, one newer. The assistant suggested the older because it matched the ticket's words slightly better. The duplicate teaches the desk that it has two articles where it should have one. The fix is merging them and leaving a pointer. The gap is the weakest kind of wrong: the assistant suggested something tangential because nothing closer existed. It teaches the desk that an article is missing. The fix is to write it from this ticket while the answer is fresh. That is the habit in The Capture Habit. A gap found by a wrong suggestion is the cheapest way a desk ever learns what to write next.

Log every wrong suggestion with its kind, in one line, as the technician closes the ticket. "Suggested 41, not used, stale: step 4 changed in the spring." Over a month the log becomes the maintenance list, which is the subject of a later section. A wrong suggestion is a knowledge base finding delivered by a tool that never gets tired of making them.

Open It Before You Send It

The technician's one habit is to open the suggested article and read it before anything is sent or applied. Read the first paragraph against the ticket: does the symptom match, on this device, for this kind of user? Read the date and the owner: is this current, and is the owner still here? Check the visibility: is this the public version or the agents-only one? Then read the steps, all of them, because the step that changed is never step one. Open the article. The whole article. Yes, even the one you wrote.

I say that from experience. I have sent an article I wrote myself to a requester without opening it, because I knew what it said. The article told them to click a button I had removed the previous spring. The requester was polite about it. The article had been wrong for nine weeks and had been suggested, and sent, eleven times in that period, by me and two colleagues. None of us had opened it either. The suggestion was right every time. The thing it pointed at was wrong, and the only check that catches that is a person reading.

The habit pairs with searching first before solving: look for the existing answer before building a new one. A suggestion is the search done for you, which removes the excuse that searching takes too long. It does not remove the reading. A technician who sends unread suggestions has not saved time. They have moved the reading to the requester, who is less qualified to do it and more inconvenienced when it fails.

Measuring Whether Suggestions Get Used

Four counts tell you whether suggestions are working, and they form a funnel. Shown: how many tickets had at least one suggestion. Opened: on how many the technician read a suggested article. Used: on how many a suggested article was sent to the requester or applied to the fix. Held: on how many of those the ticket was resolved and not reopened within the confirmation window. The ratio of used to shown is the acceptance rate. The ratio of held to used is the honest version of it. A suggestion that was sent and then reopened was a wrong suggestion that got past the reading.

Ashgrove's first full month, as a worked example and nothing more. Of 212 tickets, 140 showed a suggestion. Technicians opened one on 96 of those, used one on 61, and 54 of the 61 held through the confirmation window. The acceptance rate was therefore 61 of 140, a little under half, and the held rate 54 of 61. The 35 opened-but-not-used were logged by kind: fourteen near misses, nine stale, seven duplicates, five gaps. The 44 shown-but-never-opened were the number the lead cared most about. A suggestion nobody opens is either badly presented or no longer trusted. Either way it is costing the desk the one benefit suggestions have.

Read the funnel monthly, and read two other numbers beside it. Article usage, from the knowledge base itself, tells you whether suggestions are changing which articles get read. That is the measurement in Reading Knowledge Base Usage. And the reopen rate on tickets closed with a suggested article, compared with tickets closed without, tells you whether the articles are fixing things or merely closing them. If the first group reopens more, the knowledge base is being suggested faster than it is being maintained. In that case, the maintenance list is the fix.

Resist turning the acceptance rate into a target. A desk told to raise it will raise it, by sending suggestions unread. The held rate will fall while the acceptance rate climbs. Report the pair or report neither. When the knowledge base is healthy and technicians trust the suggestions, the held rate goes up on its own. It goes up slowly, which is the correct speed for a number that means something.

Feeding It Back Into the Knowledge Base

The wrong-suggestion log is the knowledge base's maintenance list. It is a better one than any documentation day ever produced, because it is sorted by what actually came up. Nine stale entries in a month name the nine articles whose owners need a nudge. Seven duplicates name seven merges. Five gaps name five articles to write, with the ticket that proves each is needed attached. Fourteen near misses name fourteen first paragraphs to sharpen. Each is a twenty-minute job. The routine for fitting those jobs into ordinary weeks without a dedicated day is in Maintenance Without a Documentation Day.

Work the list in the order stale, duplicate, gap, near miss. Stale first because a stale article actively misleads and is being suggested with full confidence. Duplicates second because they split usage counts and confuse the matching. Gaps third because each one is a ticket type with no answer, and the next technician will generate one. Near misses last because they waste a minute rather than a morning. A desk that works this list for three months will find that the fourth month's log is shorter. It will also find that the acceptance rate rose without anyone asking it to.

A Short War Story: The Stale Article at Bluewater Bank

At Bluewater Bank, the desk's most-suggested article for a month was "Setting up the sign-in token app on a new phone". A technician called Sam wrote it. It was correct in every detail until the security team added an approval step. In that step, a branch manager had to confirm the enrolment before the token would activate. The security team told the desk by e-mail on a Friday afternoon. Nobody updated the article. Over the following three weeks the assistant suggested it on thirty-one tickets. Technicians sent it unread on all thirty-one. Thirty-one users completed steps one to four and then waited for a token that never arrived. Each raised a second ticket or reopened the first. The cost was thirty-one reopened tickets. A branch could not take payments for most of a morning because two cashiers were locked out together. There was also a conversation between the desk lead and the security lead about whose job the article had been. The review found that the suggestion had been correct every time. The article had been wrong for twenty-one days, which the review described as "a lag". Not one of the thirty-one sends had been preceded by anyone opening it. Bluewater added two lines to its routine. Every change notice asks "which articles does this touch?" No suggested article is sent unread. The assistant had pointed where the desk had always pointed, and the desk had stopped looking where it pointed.

The Suggestion Scorecard

The scorecard is filled in once a month by the desk lead from the ticket system and the wrong-suggestion log. It takes about half an hour. The first block is the funnel. The second is the log by kind, which becomes the maintenance list. The third is the pair of comparison numbers that keep the acceptance rate honest. Keep the completed sheets. The trend over three months is what tells you whether the knowledge base is catching up with the suggestions or falling behind them.

SUGGESTION SCORECARD — ONE MONTH
Desk: ______________________   Month: ____________   Completed by: ______________

1. THE FUNNEL
   Tickets in the month:                         ______
   Shown a suggestion:                           ______
   Suggestion opened by the technician:          ______
   Suggestion used (sent or applied):            ______   acceptance rate: used / shown = ______
   Held (resolved, not reopened in the window):  ______   held rate: held / used = ______
   Shown but never opened:                       ______   (if rising: presentation or trust problem)

2. WRONG SUGGESTIONS, BY KIND (from the log)
   Near miss (right subject, wrong case):        ______   -> sharpen first paragraphs: ____________
   Stale (procedure changed):                    ______   -> owners to nudge: ____________________
   Duplicate (older of two suggested):           ______   -> merges to do: ______________________
   Gap (nothing close existed):                  ______   -> articles to write, with ticket numbers:
                                                           ______________________________________
   Sent to a requester but agents-only:          ______   (must be zero)

3. THE HONEST PAIR
   Reopen rate, tickets closed with a suggested article:     ______
   Reopen rate, tickets closed without one:                  ______
   Articles whose usage rose this month because of suggestions: ____________________
   Articles suggested most often:                 1. ________  2. ________  3. ________
   Of those, last reviewed:                       1. ________  2. ________  3. ________

4. ACTIONS FOR NEXT MONTH (in order: stale, duplicate, gap, near miss)
   [ ] ______________________________   owner: __________   by: ________
   [ ] ______________________________   owner: __________   by: ________
   [ ] ______________________________   owner: __________   by: ________

Owen logged nothing for ticket 6190, because the suggestion was right and the article was current. That is what a good month looks like: most suggestions used, most of them held, and a short log. Farah's article had a name on it, a date, a recognition test in the first paragraph and a public version linked at the bottom. That is why a technician five weeks into the job could match it to a ticket in a minute and send the right thing. The assistant found it. Farah had written it. Owen read it. Of the three, the reading is the one a desk forgets first, and the only one that nobody else can do.

Frequently Asked Questions