Refine on Reuse: Improve the Article Every Time It Is Used

Saturday, 09:15, at Northgate Retail. Malik is on the weekend desk when store 14 phones. There was a power cut overnight and the till now says "Receipt printer offline" in red, with a queue forming. He searches for "printer offline" and finds an agents-only draft that Jo wrote three weeks ago from the same symptom at store 6. It has four steps, the third of which is "hold the feed button until the light flashes twice". Leanne, the store manager, holds the feed button. Nothing flashes. Store 14 was refitted in the spring and has the newer printer. On that printer, the trick turns out to be the power button for five seconds. Malik and Leanne work that out between them in about two minutes. A test receipt prints. The queue moves.

Malik now has a choice that will take him under a minute either way. He can close the ticket and go to the next call, leaving the draft exactly as wrong as he found it. Then the next technician at a refitted store holds the feed button and gets nothing. Or he can open the draft and add one line under step three, "on the newer printers, hold the power button for five seconds instead". He can then write the article's number in his resolution note. He does the second. It takes fifty seconds, and the draft is now right for both kinds of printer. Jo could not have known that when she wrote it.

Refining on reuse is the rule that every time an article is used, the person who used it leaves it slightly better than they found it. They fix the one thing that was wrong, or flag it if they cannot, and they link the ticket to the article. It is the second half of the loop whose first half, writing the two-minute draft, is in The Capture Habit. Refining on reuse is how a draft written by one person from one ticket becomes an article a whole desk trusts. This article is part of our Capture Knowledge While Solving series, and it is about the fifty seconds.

It covers why every use is a review and the scheduled review is not, and fixing the one thing that was wrong. Next come why small edits beat rewrites, and flagging what you cannot fix. Then it covers linking the ticket to the article and why the count matters. It then covers how an article matures in five uses, with the receipt printer as the worked example. Next come the article that is wrong enough to hurt, and how articles rot when they are used and not refined. It finishes with a short war story and the reuse checklist to copy, in that order.

Every Use Is a Review

The only person who ever tests an article against reality is the person following it to fix a real ticket. That makes them the only reviewer whose opinion is evidence. A scheduled review reads the article and asks whether it looks right. A technician at store 14 with a queue forming holds the feed button and finds out. The difference is the difference between proofreading a recipe and cooking it, and nobody has ever found the missing teaspoon of salt by proofreading.

This is why the knowledge-centred way of working puts the maintenance of an article into the moment of its use rather than into a calendar. An article that is used weekly is tested weekly, by people with the real symptom in front of them. If each of them fixes what they hit, the article is never more than a week wrong. An article that is used weekly and reviewed yearly is tested weekly and fixed yearly. For fifty-one weeks each user works round the same wrong step and says nothing. The review on the calendar is not useless. It catches the articles nobody uses, which is a different job and belongs to Maintenance Without a Documentation Day. The articles people use are reviewed by the people using them, or not at all.

The habit asks the technician to notice two things while following the article. One is where the words on the page and the thing on the screen disagreed. The other is what they had to do that the page did not say. Both are noticed anyway, because they are what makes the fix take longer than the article promised. The habit only asks that the noticing be written down before it is forgotten. That means at the moment the fix is proved, in the same two-minute gap the capture habit uses. Malik noticed that step three did not match the printer in front of him because the printer told him so. All he added was the writing down.

Fix the One Thing That Was Wrong

Fix the thing you hit, and only that. Malik hit a step that did not match the newer printer; he added one line for the newer printer and touched nothing else. He did not rewrite the title, reorder the steps, add a screenshot, or improve Jo's phrasing, although he could have found fault with all of them. The one thing takes under a minute and gets done. Everything would take twenty minutes and would not. An article that is improved by one line on every use is better in a month than an article that waits for someone with twenty minutes.

The one thing is usually one of a short list. A step that did not match what was on the screen, because a label has been renamed or a button has moved. A variant the author did not know about: a second printer model, a second site, a different version of the application. A step the author did without noticing and so left out, usually a confirmation dialogue or a sign-in. A check that was missing, so the next person did not know whether the fix had worked. A "looks similar but is not this" case the author had not met. Each of these is a one-line edit. Each is exactly the kind of thing the author could not have known from a single ticket and the user cannot help knowing from the second.

Resist the urge to improve things that were not wrong. An article that worked is an article that worked, and the fact that you would have phrased step two differently is not a defect. Editing on taste makes the article churn, so that regular users find it changed every time they open it and stop trusting it. Editing on taste also spends the one minute the habit allows on something with no value to the next reader. The test for an edit on reuse is simple: did this cost me time, or would it cost the next person time? If yes, fix it. If it merely offended you, leave it.

Small Edits Beat Rewrites

A rewrite needs the one thing the desk never has, which is an uninterrupted half hour. So a rule that says "rewrite it when it gets bad" is a rule that says "leave it bad". The small edit needs fifty seconds, which the technician has, standing at the ticket they have just closed. That is the practical argument and it would be enough on its own. There are two others.

A rewrite loses the parts that were right. Jo's draft had a good title, a correct "looks similar" line (printer actually unplugged after the cleaners moved the till) and three correct steps. Only step three was incomplete. A technician rewriting the article from their own understanding would keep what they remembered and drop what they did not. Jo learned the "looks similar" line from an awkward phone call. It is exactly the kind of thing a rewriter drops because it did not come up for them. Small edits preserve everything the previous users learned. Rewrites preserve what the rewriter happens to know.

A rewrite also breaks the article for the people who use it most. The store managers at Northgate who have fixed their own printer twice from this article know it by shape. There are four steps, and the third is the button. Change the shape and they are reading it fresh. That is slower and teaches them that the knowledge base cannot be relied on to stay still. Small edits keep the shape. The article grows by accretion, like a well-used recipe card with notes in the margin, and the notes are the valuable part. An article that has been rewritten three times is three articles that happen to share a title, and nobody can say which of them was tested.

The exception is the article whose shape is itself the problem. Examples include the steps in the wrong order, the cause muddled with the fix, and a title nobody searches for. That is a rewrite, and it is the job of the review before publishing, described in From Draft to Published: The Light Review. Or it is the job of the article's owner at a time they choose. It is not the job of the technician at 09:15 on a Saturday with the next call waiting. Their job is the one line.

Flag It When You Cannot Fix It

Sometimes the one thing is more than a line. The technician found that the fix in the article no longer works at all. The fix that does work took them forty minutes and they are not sure why. Or the article is public and the correction involves a step requesters should not take. Or they are not confident enough in what they found to change an article other people rely on. In each case the right move is to flag rather than fix. That means one line at the top of the article saying what was wrong, who found it, and on which ticket. That way, the next reader is warned and the owner knows there is work to do.

The flag is not a complaint; it is a message to a named person. Every article that has been promoted beyond a draft has an owner, for exactly this reason. The article Ownership: Every Article Has a Name on It explains how to make that true on a small desk. A flag that says "Step 3 did not work on the refitted stores; the power button did, but I am not sure why. Malik, ticket 8812" gives the owner everything they need to decide whether to edit, investigate or ask Malik. The flag protects the next reader in the meantime. A flag that says "this is wrong" gives them a mystery.

Never delete the step you think is wrong, and never silently work round it. Deleting removes what might be right for the older printers and leaves no trace of why. Working round it, which is the commonest response and feels like politeness, leaves the article exactly as wrong for the next person. It costs them the same forty minutes it cost you. Flagging takes thirty seconds and is the minimum the habit asks. The queue is not improved by technicians being gentle with articles.

Link the Ticket to the Article

Every ticket that used an article is linked to it. The link matters for two reasons that are easy to underrate when the queue is busy. The first is the count. An article that has been used fourteen times is an article the desk needs. The count is the only evidence of that which does not depend on anybody's memory. It is what tells the lead which drafts to promote, and which articles to put in front of requesters. When a manager asks what the knowledge base is for, it tells the lead what to answer. The second is the trail. The article says what to do. The linked tickets say what actually happened each time, including the variants and the cases where it did not work. Whoever investigates the cause later will want them.

The mechanics are whatever the tool makes easiest, as long as it is the same every time. Some tools link a ticket to an article with a click and count the links for you. Some let tickets be linked to each other, so the first ticket about a symptom becomes the anchor the others link to. Many have neither, and then the link is a convention. It is the article's number written in the resolution note in a fixed form, "KB-118". A search for "KB-118" finds and counts it. If you run QuerySolv, every ticket keeps a complete event history. So, in QuerySolv, the number written in the resolution note stays searchable for as long as the ticket does. In that setup, the count of uses is a search rather than a spreadsheet. The convention that works in every tool is the number in the note. The only rule is that "KB-118" is never written "KB 118", "kb118" or "the printer article".

Link at the moment the fix is proved, with the article still open, because that is when it costs five seconds. Linking at the end of the week means opening fourteen closed tickets and remembering which article each one used. That is a documentation day in miniature and meets the same fate. The reuse checklist at the end of this article puts the link in the same breath as the edit. The two together are under a minute. A desk that does the edit and skips the link has improved the article and lost the evidence that anyone needed it.

How an Article Matures in Five Uses

A draft written in two minutes from one ticket is a guess with evidence. An article used five times with the habit applied is something a desk can trust. The table below shows the receipt printer article making that journey at Northgate. No single use did much. Jo wrote four steps. Malik added a line. Dev confirmed it on a third model and wrote down how long it takes. Jo, using her own draft a second time, discovered that a store manager could do it unaided, which changed what the article was for. Sunita, the lead, reviewed it once it had earned a review and opened it to the store managers. Five people, perhaps six minutes of writing in total, and an article that stops a queue forming at the till without a call to the desk.

Notice where the rewrite happened: at use five, by the reviewer, once the article had proved itself and once the facts had stopped changing. Rewriting at use two, when Malik had found one variant and nobody knew there would be a third, would have been premature and would have had to be done again. The uses in between did the cheap work of finding out what was true. The review did the expensive work of saying it well, once, when it was worth saying. That ordering, facts first by many hands and polish last by one, is the whole economy of the method.

When the Article Is Wrong Enough to Hurt

Most wrong steps cost time. A few cost more. One example is the step that tells a technician to restart a service that other people are using. Another is the step that was correct for one application and dangerous for the one that replaced it. Another is the step in a public article that tells a requester to change a setting they should not touch. When a technician following an article makes something worse, or realises partway through that the next step would, the habit changes from "fix the one thing" to "stop and say so, now".

Stopping means three things in the next five minutes. Flag the article at the top, in plain words: "Do not follow step 4; it restarted the shared print service at 09:20 and took every store offline for three minutes. Malik, ticket 8812." Tell the desk out loud or in the team chat, in one line, so nobody else opens the article in the next hour and does the same thing. And if the article is visible to requesters, take it back to desk-only until the owner has looked at it. A requester cannot read a flag at the top and judge it as a technician can. The owner then decides whether the step is fixed, removed or replaced, and the article goes back out once it is safe.

Do not quietly correct a dangerous step and move on, even if you know the right one. The next technician needs to know that the old step did damage. That way, they recognise the damage if they see it on a machine where someone followed the old version last week. The flag carries that history; a silent correction erases it. Dangerous mistakes are rare, which is why this paragraph is short. When they happen the article's history is the one place the desk can see what was believed, by whom, and when it changed.

Reuse Without Refinement: How Articles Rot

An article that is used and not refined rots in a particular way. It stays right for the people who already know the answer and becomes wrong for everyone else. The experienced technician opens it, sees that step three is out of date, remembers the real step, does that, and closes the ticket. The article has been used, the count has gone up, and it is still wrong. The next new starter follows it faithfully, fails at step three, and concludes either that they are bad at the job or that the knowledge base is. Both conclusions are bad for the desk, and the second is contagious.

The rot is caused by the world changing underneath the article. Screens are redesigned, labels are renamed, the newer printer arrives, and a supplier changes the sign-in page. None of it is the author's fault and all of it is predictable. The question is only who corrects the article when the world moves. The choice is between the person who notices in the moment, for fifty seconds, or a review some months later that may or may not notice at all. The health of the whole knowledge base can be checked in half an hour by the method in A Knowledge Base Health Check in Thirty Minutes. On a desk with the reuse habit that check finds very little. That is because the articles people use have been fixed by the people using them. On a desk without it, the check finds the articles that have been worked round for a year.

Watch for the sentence that signals rot: "yes, the article says that, but what you actually do is". Whenever a technician says it to a colleague, the article is wrong and someone knows how. Then the fix is to open the article and type the second half of the sentence into it. I have said that sentence myself more times than I would like, usually while standing behind someone's chair. The knowledge base would have been better served if I had sat down.

A Short War Story: The Renamed Tick Box at Meridian Parts

Meridian Parts published a knowledge base article for its home workers on connecting to the company network. Step five said "tick the box marked Remember my credentials". After an update to the connection software the box was renamed "Save sign-in info" and moved to a different tab. The article was not changed. Over the following six weeks, fourteen home workers followed the article, could not find the box, and raised tickets saying the instructions were wrong. Each of the three technicians who handled them told the requester the new name and got them connected in about fifteen minutes. Each closed the ticket and left the article as it was. The fix had been so quick that editing it did not seem worth the trouble. Hana, who had joined the desk the week before, took the fifteenth ticket. She read the article before replying, saw the problem, and changed six words. The lead, Olu, added it up afterwards. There were three and a half hours of desk time on fourteen tickets. There were fourteen home workers who had learned that the knowledge base could not be trusted. And there was a line in the staff survey that said "the IT instructions online are usually out of date". The survey did not know that had been true for six words. An article that is used and not corrected gets corrected by the queue instead, one ticket at a time, at full price.

The Reuse Checklist

The checklist below is the habit as a card, for the technician who has just followed an article and is about to close the ticket. It has three parts: what to look at before following the article, what to notice while following it, and what to do in the minute after the fix is proved. The final section is the stop rule for the rare case that hurts. Print it, pin it beside the capture habit card, and expect it to become unnecessary within a month, which is what a checklist is for.

THE REUSE CHECKLIST — EVERY TIME YOU USE AN ARTICLE
Article: ________   Ticket: ________   Used by: __________

BEFORE YOU FOLLOW IT
  [ ] The title and the "looks similar but is not this" line match this symptom
  [ ] Read every step once before doing step one

WHILE YOU FOLLOW IT
  [ ] Note any step that did not match what was on the screen
  [ ] Note any step you had to do that the article does not mention
  [ ] Note anything wrong, out of date or unclear

AFTER THE FIX IS PROVED — UNDER ONE MINUTE
  [ ] Fix the one thing you hit: the step, the variant, the renamed label
  [ ] Could not fix it? Add one line at the top: what was wrong, your name, the ticket
  [ ] Tick anything on the draft's "not yet" list that this use confirmed
  [ ] If the requester did the steps themselves, say so in the article
  [ ] Write the article's number in the resolution note, the same way every time

STOP AND TELL THE DESK NOW IF
  [ ] A step made something worse
  [ ] The article is visible to requesters and a step could harm one
  Then: flag the article at the top, take it back to desk-only, tell the owner

Malik's fifty seconds on the Saturday were the second row of the table and three ticks on this card. By the time Sunita opened the article to review it, it had been through four stores and three printer models. It had a line for each, and had been done once by a store manager with nobody from the desk on the phone. Sunita had very little to do, which is how a review should feel. The article had been reviewed four times already, by the only reviewers who ever test anything. All she had to do was tidy up after them.

Frequently Asked Questions