Making Knowledge Capture Stick on a Team

Monday, 09:05, at Larkspur Dental, a group of six practices with a desk of four. Three weeks ago Imogen, the desk lead, stood up in this same meeting and said: "From now on we capture knowledge. When you fix something, draft it in the ticket before you close. Two minutes. Desk-only. Any questions?" There were none. Everyone nodded, and she wrote "KB capture: started" in her notebook. This morning she has counted. There are five drafts in the knowledge base. She wrote four of them. Ravi wrote the fifth, on his second day back from leave, and has not written another. Ben, asked gently, says: "I meant to, honestly, it's just been a lot." Chloe says: "I wasn't sure mine were good enough to save." Nobody disagreed with the idea. Nobody is doing it.

This is the normal result of an announcement, and it is nobody's fault, least of all Ben's or Chloe's. An announcement is a wish said out loud. A habit on a team is a trigger everyone recognises and an action small enough to do when the queue is busy. It is also a result people can see, and a lead who is visibly doing it too. Imogen supplied the wish and one of the four parts, and three weeks later she has the drafts to show for it: hers.

Making capture stick is the work of turning the loop described in this series into a desk habit. The loop is searching first, drafting inside the ticket, refining on reuse, and the light review. The work turns something the lead believes in into something the desk does without being asked, including in the week the lead is away. It is a question of expectations, measurement, recognition, a very small amount of ritual and a great deal of example. It is the part of the method that the frameworks spend the least time on and that decides whether any of the rest happens. This article is part of our Capture Knowledge While Solving series, and it is the last one for a reason. Everything before it is what to do, and this is how to get four people to keep doing it.

It covers why the announcement did nothing, then stating the expectation in one sentence, including what is not expected. Next come the measures that tell the team whether it is working without turning into quotas, and recognition that is specific and about the saving. Then it covers the ten minutes on Friday, which is the only scheduled thing, and the lead who does it visibly. After that come bringing new starters into the habit from their first ticket and the dip in month two and what to do about it. It finishes with a short war story and the team agreement to copy.

Why the Announcement Did Nothing

An announcement fails for three reasons, and all three were present at Larkspur. The expectation was not specific enough to act on. "When you fix something" covers every ticket, and a technician closing a password reset does not know whether that counts. So they decide it probably does not, and then the licence server does not count either. The fear of judgement was not addressed. Chloe heard "draft an article" and pictured the finished articles she has read, with screenshots and headings. She concluded that her two rough lines would embarrass her. And there was no feedback. Nobody saw their draft being used or heard that it had saved anyone anything. A habit that produces no visible result for three weeks is a habit the queue will quietly remove.

The deeper problem is that an announcement treats a habit as a decision, and habits are not decisions. Ben decided to draft his tickets on the Monday and meant it. On the Tuesday he closed a ticket at 16:50 with three more waiting and the decision was not present in the room. What was present was the next ticket. A habit is what happens when the decision is no longer needed. The trigger is obvious, the action is tiny, and doing it feels better than not doing it. Building that on a team is slower than an announcement and much faster than a second announcement, which is what most leads try next.

The method in this series was designed for this. The trigger is "that worked", which every technician already experiences a dozen times a day. The action is two minutes inside a ticket that is already open. The result is a draft the author will see used, if the desk searches first and says so when it finds something. What the lead has to add is not motivation but structure. That means a clear expectation, a few honest measures, a minute of recognition a week, and the sight of the lead doing it.

State the Expectation in One Sentence

The expectation is one sentence that says what, when and how long, and it is written down where the desk can see it. "When you close a ticket you had to work something out on, spend two minutes turning your note into a desk-only draft before you close it." Every word is doing a job. "Had to work something out on" excludes the routine tickets, so nobody has to wonder about password resets. "Two minutes" says how much effort is wanted and, by implication, how much is not. "Desk-only" says who will read it, which is the answer to Chloe's worry. "Before you close it" is the trigger. A technician who has read that sentence once knows exactly what is expected on every ticket they will ever close. That is more than Imogen's announcement managed in a paragraph.

The second half of the expectation is what is not expected, and leaving it out is the commonest mistake. Not expected: polish, screenshots, headings, or anything that takes longer than copying. Not expected: a number of drafts per week. A technician who closes twenty routine tickets and drafts nothing has done exactly what was asked. Not expected: writing up old fixes from memory, or a documentation day, or a list of articles to write later. The argument against all three is in Why Documentation Day Never Comes. The lead should make it once so the desk stops feeling guilty about the whiteboard. Saying what is not expected is what makes the expectation feel possible. It tells Chloe that her two rough lines are the whole of the job and not a poor attempt at a bigger one.

Pair the sentence with the two companion habits, in the same plain form. "Before you touch a new ticket, spend up to ninety seconds searching the knowledge base and the closed tickets for the requester's words." "When you use an article, fix the one thing that was wrong or flag it, and write its number in the resolution note." Three sentences, printed on one page, stuck to the wall, and that is the whole policy. If the desk already keeps a one-page standard for ticket notes of the kind described in A One-Page Ticket Note Standard for the Whole Team, these three sentences belong on the same page. The draft is written from the note and the two habits support each other.

Metrics That Do Not Become Quotas

Measure whether the knowledge is being used, never how much of it is being written. Any count of articles produced will be met, and it will be met with articles. A desk told that five drafts a week is the goal will produce five drafts a week. These will be drafts of routine tickets, duplicates of existing articles, and drafts split into three to make the number. There will be drafts that say "restarted it" under a title. The count goes up. The knowledge base fills with things nobody will search for. The search starts returning thirty results for everything. At that point the desk stops searching and the loop breaks. Every measure that counts output does this eventually. The ones that count use do not, because use cannot be manufactured without someone actually finding the article helpful.

The table below gives the measures worth keeping and the one to avoid. All of them are for the team, read together once a month, and none of them is attached to a name. The moment a measure is per person it becomes a target. The moment it is a target the technician's attention moves from the ticket to the number. A desk of four does not need to know that Ben drafted three and Chloe drafted one. It needs to know that eleven tickets this month were closed using an article, up from six. It also needs to know that two of the failed searches repeated. Those are facts about the system, and the system is what the lead is trying to change.

Keep the measures cheap or they will not be kept. The reuse count is a search of closed tickets for the article-number convention. The first-reply count is a search for tickets resolved on their first public reply that contain a knowledge base link. The failed-search list is a search for "Searched:" in working notes. Each takes a few minutes a month and none needs a spreadsheet. If you run QuerySolv, the reports on ticket volume and resolution times give the before-and-after for a symptom once its article is published. In QuerySolv, the ticket history gives the reuse count from the number in the resolution note. The arithmetic that turns these counts into hours saved is in The Time Saved by Technicians. That is for the day a manager asks what the knowledge base is worth. The desk does not need to do it monthly. It needs the counts, read together, and the trend.

Recognition: Say Out Loud What the Article Saved

Recognition is the feedback the announcement lacked, and it works when it is specific, public, and about the saving rather than the writing. "Ravi's draft on the imaging software's licence error saved Chloe forty minutes on Tuesday; she had it fixed before the practice manager had finished explaining the problem." That sentence, said in the Monday meeting, tells Ravi that his two minutes mattered. It tells Chloe that searching paid, and tells Ben what a draft is for. "Thanks to everyone who's been drafting" tells nobody anything, and is what most leads say instead. It is easier and does not require them to have noticed.

Noticing is the lead's job, and the reuse convention makes it possible. The article number in the resolution note tells the lead which tickets used which article. A glance through the week's closed tickets on Friday afternoon finds the saves. There is the ticket that was closed in six minutes because the draft existed. There is the triage reply that sent a published article and heard back "that worked, thanks". The lead writes down two of them, with names and the time saved, and says them on Monday. It takes ten minutes to find and one minute to say. It is worth more than any metric, because it is the metric with a face.

Recognise the whole loop, not just the authors. Think of the technician who fixed the wrong step in someone else's article. Or consider the one who flagged a draft as unsafe before it was sent. Or consider the one who searched first and found the closed ticket from last year. Or consider the one whose "Searched: ... Nothing." line turned into the article the desk needed. Each of them did the method, and each should hear it. If only authorship is praised, the desk learns that writing is the valued act. Writing is the smallest part of the loop. Reuse, refinement and the honest flag are where the knowledge base gets its quality. And Refine on Reuse is the argument for why they deserve the louder thanks.

The Ten Minutes on Friday

The one scheduled thing in the whole method is ten minutes on Friday afternoon, standing, with the desk together. It is not for writing. It is for looking at what the week produced and deciding one thing. The lead puts up the week's drafts sorted by how many tickets used them, and the failed searches. The desk spends ten minutes on five items. First is which draft has earned the light review this week, and who will do it. Next is whether any failed search repeated and who will draft it from their last ticket. Then comes whether any article was flagged and its owner knows. Last are one save to be said aloud on Monday, and anything anyone noticed that was wrong with the method itself. Then everyone goes back to the queue.

Ten minutes is the whole budget, and the lead guards it. The temptation on a quiet Friday is to extend it into a writing session or a tidy-up of the knowledge base. Both turn the ten minutes into a meeting that gets cancelled the following week when the Friday is not quiet. The ten minutes survives because it is too short to be worth cancelling. It happens in the week the switch stack reboots, because ten minutes at four o'clock can be found in any week. Those ten minutes are the only reason the review in From Draft to Published: The Light Review happens on a schedule anyone keeps. That schedule is one draft per week, chosen on Friday, reviewed by the following Friday.

The Friday ten minutes is also where the method gets repaired. A technician who has stopped searching because the searches never find anything will say so there. The answer is usually that the drafts are being titled in technician words and the search is being done in requester words. That is a fifteen-second fix to the expectation. A technician who feels the drafts are judged will say so there, if the lead has made it safe. The answer is to read one of the lead's own rough drafts aloud. These conversations do not happen by e-mail and do not happen in a monthly meeting with an agenda. They happen standing up, briefly, among people who have all just done the thing.

The Lead Who Does It Visibly

The desk does what the lead does, not what the lead says. A lead who announces the capture habit and then closes their own tickets without a draft has announced that the habit is for other people. Imogen's four drafts were the one thing she got right in the first three weeks. The desk could see that she was doing it, and that her drafts were rough. They were two or three lines under a title with no screenshot. That told Chloe more about what was acceptable than any reassurance could have. A lead's rough draft is permission. A lead's polished one is a standard nobody else has time to meet.

Visibility means doing the habits where the desk can see them, and narrating a little. Searching first out loud: "Hang on, let me see if we've had this; what did she say, 'won't print the appointment letter'." Flagging an article in the team chat: "The scanner article's third step is out of date on the new units, I've flagged it, Ben, it's yours when you have a minute." Writing the "Searched: ... Nothing." line and mentioning that the draft's title came from it. None of this is performance for its own sake. It is the lead showing the triggers in real time, so that the desk learns to recognise them in their own tickets. It costs the lead nothing beyond the habit itself.

The lead also reviews on time, which is the visible act that matters most in month two. A draft chosen for review on Friday and still unreviewed three Fridays later tells the desk that the lead's part of the loop is optional. If the lead's part is optional, so is theirs. One draft a week is a small commitment and the lead keeps it, in public, by saying on Friday which one they reviewed and what changed. I have watched this fail on a desk where the lead was genuinely too busy. The drafts stopped within a month, not because anyone decided to stop but because the loop had visibly stopped turning at the top.

New Starters: Capture From Day One

New starters are the easiest people to give the habit to and the best capturers a desk has. Everything is new to them and they have no memory to rely on instead. A technician in their first month cannot say "I'd know if we'd seen this", so they search. They cannot fix the licence server from memory, so they follow the draft and find where it is wrong. And the fix they have just worked out for the first time is, to them, plainly worth writing down. It was hard. The desk's job is to make sure the habit is installed in that first month, before the memory arrives and starts offering shortcuts.

The installation is concrete. In the first week the new starter gets the one-page agreement and the habit card. Someone reads those pages through with the new starter in ten minutes. Their first new ticket is searched with a colleague watching the clock, so they feel how short ninety seconds is and how often it finds something. Their first draft is read by a colleague the same day. The response is the one thing that would make it more useful and nothing else, said kindly. A first draft that is picked apart is the last draft. And their first found article is pointed out: "that draft you just used, Ravi wrote it in March; see the bit you fixed? That's how it works." After a month they will be teaching it to the next starter, which is how a habit becomes a culture without anyone using the word.

Treat the new starter's early drafts as a feature. They will draft things the old hands consider too obvious to write. Examples are where the practice managers' shared folder is or how the scanner at practice three is reset. Those are the articles the next new starter needs most, because the old hands never wrote them. Thank them for it. The desk will not know how much it was carrying in its heads until someone writes it down.

The Month-Two Dip

Expect the habit to fade in the second month, and plan for it. It fades on every desk and the leads who are surprised by it respond badly. The pattern is predictable. The first fortnight has the energy of a new thing and the drafts come in. The third and fourth weeks are busy. A couple of drafts are missed, and nobody says anything. Missing a draft becomes normal. By week six the searches are being skipped on the grounds that the knowledge base is still thin. The drafts stop because nobody is finding them. The loop has stalled with a dozen drafts in it and a lead wondering whether to make a second announcement.

Do not make a second announcement, and do not respond with a target. The announcement will be heard as nagging and the target will produce the junk described above. Respond with the two things that were probably skipped. One is the Friday ten minutes, which lapsed in the busy week and did not come back. The other is the recognition, which stopped when the lead stopped noticing. One Friday with the week's drafts on the screen, one save said aloud on Monday with names in it, and the loop restarts. The trigger and the action never went anywhere. What went was the feedback. The dip is a feedback failure, and the repair is feedback.

Watch also for the quieter cause, which is a draft that was criticised. Consider a technician whose first rough draft was corrected at length or rewritten by a senior colleague without a word. Or that draft was described as "not really an article" in the Friday meeting. That technician has learned that drafting is risky and will stop, politely, without saying why. The lead usually finds out months later. The protection is the expectation that drafts are rough, restated whenever a rough one appears. There is also a rule that drafts are improved by the people who use them, one line at a time, and never rewritten at someone.

A Short War Story: Five Articles a Week at Pennant Media

Pennant Media, a trade publisher with a desk of three, hired an IT manager called Douglas who had read about knowledge-centred methods. On his first Monday, he set a target of five articles per technician per week. It was displayed as a bar chart in the weekly meeting with each technician's name under a bar. The desk met it. Within two months the knowledge base held three hundred and ten articles. Douglas's own later audit found about a hundred and ninety to be duplicates, near-duplicates or articles about restarting things. Those included eleven separate articles on restarting the advertising booking system. Two of those gave steps that locked the user's session rather than clearing it. Searches for anything returned twenty or thirty results. The technicians stopped searching because the results were useless. The one fix that genuinely mattered was the booking system's "session locked" workaround that the sales team hit daily. It existed in four versions, two of them wrong. So the technician who found the wrong one first made the sales director's lock worse during the quarterly booking deadline. Douglas removed the chart in month three and hired a contractor for two weeks to merge and delete. He replaced the target with a monthly count of tickets closed using an article. That started at nine. By then the desk had learned that the knowledge base was something you fed rather than something you used. It took most of a year for the technicians to trust a search again. A quota produces exactly what it counts, and it had counted articles.

The Team Agreement

The agreement below is the one page Imogen should have handed out instead of making a speech. It states the three habits in one sentence each and says what is not expected. It names the measures and promises they will never be per person. It says what the lead commits to, fixes the shape of the Friday ten minutes, and says how a new starter is brought in. It is signed by everyone, including the lead, and pinned up. It is read again at the three-month mark. By then, the desk will want to change a line or two in the light of what they have learned. The signing is not ceremony. It is the moment the expectation stops being the lead's and becomes the desk's.

THE CAPTURE TEAM AGREEMENT — ONE PAGE, SIGNED BY THE WHOLE DESK
Desk: ______________   Agreed on: ________   To be read again on: ________

WHAT WE DO ON EVERY TICKET
  Before touching anything: search the knowledge base and closed tickets
    for the requester's words. Ninety seconds, then stop.
  While working: note what we see and do, with the time.
  When the fix is proved and someone else could meet this: two minutes,
    draft it from the note, desk-only, titled in the requester's words.
  When we use an article: fix the one thing that was wrong, or flag it,
    and write its number in the resolution note.

WHAT IS NOT EXPECTED
  Polish, screenshots or finished prose in a draft.
  A number of drafts per person per week.
  A documentation day, or a list of articles to write later.
  Writing up old fixes from memory.

WHAT WE MEASURE — FOR THE TEAM, NEVER PER PERSON
  Tickets closed using an article.
  Articles used by someone other than their author.
  Tickets closed in the first reply with an article.
  Failed searches that repeat.

WHAT THE LEAD DOES
  Searches first, drafts their own tickets and flags articles, in view of the desk.
  Runs the ten minutes on Friday and reviews one draft each week.
  Says aloud on Monday, with names, what an article saved and who improved one.

THE TEN MINUTES ON FRIDAY
  The week's drafts by reuse.   The failed searches.   One draft chosen for review.
  Any flagged article and its owner.   One save for Monday.   Nothing else.

HOW A NEW STARTER JOINS THIS
  Gets this page and the habit card in week one.
  First search and first draft done with a colleague alongside, and thanked.

Signed: ______________   ______________   ______________   ______________

Imogen rewrote her announcement as this page the following week, read it through with the desk in ten minutes, and signed it first. The Friday ten minutes started that week with five drafts on the screen and one save to report, which was her own. Ravi's draft had saved her twenty minutes on a licence error on the Wednesday. She said so on Monday with his name in it. Ben drafted two tickets the following week and Chloe drafted one, three lines long, about the appointment letter printer. Her draft was used four days later by Ravi, who told her. By the three-month mark the desk had forty-one drafts and seven published articles. The reuse count had gone from four a month to nineteen. There was a second page of the agreement with two lines crossed out and one added, in Chloe's handwriting. The habit had stopped being Imogen's. That was the whole point.

Frequently Asked Questions