The Capture Habit: Draft the Article Inside the Ticket

Tuesday, 10:52, at Harbourview Clinic. Nadia has ticket 4417 open: "The records system keeps logging us out in room 4, every few minutes, both computers." The nurses have been signing in eleven times a morning. She has spent half an hour on it and found the cause, which is not in the records system at all. The two PCs in treatment room 4 were set up by an outside installer and point at a time server that no longer exists. Their clocks have drifted eight minutes. The records system refuses a session whose time is that far from its own. She has pointed both PCs at the clinic's own time source, forced a resync, signed in, and watched the clock for twenty minutes without an expiry. Her working note in the ticket has four timestamped lines. The error text is still on the second screen. Her hand is moving towards the status field to close the ticket.

This is the moment. In about ninety seconds the ticket will be closed. The screen in room 4 will be showing a patient record, and the nurses will be grateful and will have stopped caring why. In three weeks, when the PC in the dispensary does the same thing, Nadia will be on leave. Whoever picks it up will start from "keeps logging me out". That is the opening line of about a dozen different problems.

The capture habit is the two minutes spent at this moment, before the ticket closes, turning the working note into the first draft of a knowledge base article. It is titled in the requester's words, built from the text already on the screen, and saved where only the desk can see it. The capture habit is the producing half of the loop described in Why Documentation Day Never Comes. The capture habit is the habit everything else in this series depends on. This article is part of our Capture Knowledge While Solving series, and it is about the two minutes.

It covers why the moment is the check that proved the fix, and not any later. Next come the difference between the working note and the draft, and titling in the requester's words. Then it covers the four parts of a two-minute draft, with the clinic's ticket as the worked example, and saving it where only agents see it. Next come what to leave out and why two minutes is enough, and the tickets that should not produce a draft. It finishes with making the public reply do double duty, a short war story, and the in-ticket draft block to copy, in that order.

The Moment Is the Check That Proved the Fix

The draft is written in the gap between proving the fix and closing the ticket. That gap is the only time all of the article's raw material is on the screen at once. The error text is visible. The steps are in the working note, in order, with the time against each. The check has just been done, so the technician knows what "fixed" looked like. Thirty seconds after the close, the next ticket is open and the material starts to evaporate. By the next morning the exact wording has gone, and by the following week so has the order of the steps. The gap is about two minutes wide and it does not come back.

Before the check is too early, which is the less obvious mistake. A technician who drafts while the fix is still a theory writes down the theory. The article then says "point the PCs at the right time server" when the actual fix turned out to need a resync as well. Or the theory was wrong and the article describes a fix that did not work. Harbourview's ticket is draftable at 10:52 because the twenty minutes without an expiry have passed. At 10:30, with the clocks changed but nothing proved, the right thing to write is a working note saying "changed time source at 10:30, watching". At that point, the right thing to draft is nothing yet.

The habit therefore has a trigger, and the trigger is a thought rather than a time: "that worked". Technicians have that thought on every ticket they close, usually with some relief, and the habit attaches itself to it. That worked; would a second person ever meet this; if so, two minutes. On a desk where the thought is followed by closing the ticket and reaching for the next one, the knowledge base grows at the speed of documentation day. That is to say it does not. Hanging the habit on an existing moment is what makes it survive. And "that worked" is a moment that arrives a dozen times a day without anyone scheduling it.

The Note Is a Diary; the Draft Is a Recipe

The working note and the draft are made of the same words and are not the same thing. The note is written for the ticket. It records what happened, in the order it happened, including the twenty minutes spent in the records system's settings before Nadia thought to look at the clock. It is a diary. How to write it, with a time against every line and before you walk away, is the subject of The Working Note: Write While You Work, Not After. Nothing here replaces it. The draft is written for the next technician. It says how to recognise the symptom, what causes it, what to do and how to tell it worked. It is a recipe. Nobody cooking from a recipe wants to read about the dish the cook burnt first.

Turning the diary into the recipe is mostly deletion and one reordering. The dead ends go, with one exception. The dead end that looked right and was not goes into the draft as a warning, because the next technician will be tempted by it too. "This is not a records system fault; its session settings are fine" is one line in the draft and saves the next person Nadia's twenty minutes. The remaining steps are put in the order they should be done rather than the order they were discovered. For the clinic, that means "check the clock" moves from step four to step one. Everything else is copied as it stands, including the error text, which is pasted and not retyped.

The resolution note is a third thing and stays on the ticket. It tells this requester, and anyone reviewing this ticket, what was done and why. The standard for it is in Resolution Notes Worth Reading Later. On a desk with the capture habit, the resolution note and the draft are written in the same two minutes and share most of their sentences. That is why the habit costs so little. The resolution note is about ticket 4417. The draft is about every ticket that will ever look like it.

Title It in the Requester's Words

The title is the symptom as the requester described it, not the cause as the technician understood it. The title is how the article gets found and the next requester will describe the symptom, not the cause. Nadia's ticket came in as "keeps logging us out". The cause is clock drift. An article titled "Clock drift on PCs with a stale time source" is accurate, tidy, and invisible to every nurse, receptionist and triager who will ever search for this problem. None of them knows the clock is involved. That is the whole reason they raised a ticket. "Records system keeps logging you out every few minutes" is the title, and the cause goes in the body where it belongs.

Add the exact wording from the screen in the first line of the body, in quotation marks, exactly as shown. That way, a search for the error text finds the article as well. "Your session has expired. Please sign in again." Searches match words, and the words a requester has in front of them are the words they will type or read out. That is the argument made at length in Notes for the Stranger Who Finds This Ticket Next Year and applied here to the article. Between the requester's phrase in the title and the screen's phrase in the first line, the article is findable by anyone who has the problem. That is the only kind of findable that counts.

Generalise the title gently, and only as far as the technician actually knows. Nadia knows the problem affects both PCs in room 4; she does not yet know whether it affects anything else. "Records system keeps logging you out every few minutes" is as far as the evidence goes, and the body says "seen on both PCs in treatment room 4". When the dispensary PC does the same thing three weeks later, whoever handles it adds "and the dispensary". The article has grown by exactly the amount that was learned. A title that claims more than the ticket proved is a guess with a heading.

The Four Parts of a Two-Minute Draft

A draft has four parts under its title. Each is a line or a few lines copied from the ticket rather than composed. The first is where it happens: the device, application, place or group, and the exact wording seen. That lets the next technician tell this symptom from the ones that resemble it. Next is the cause, if known, or the words "not yet known". Those words are more useful than a plausible guess because they tell the next person where the work is. Then comes the fix, as numbered steps in the order they should be done. Include a note of who can do them: the requester, a technician remotely, or only someone at the device. And the check that proved it: what the technician looked at, and for how long, to decide that the fix had worked.

The table below is ticket 4417 drafted that way. It took Nadia a little over two minutes, most of which was moving the clock check to step one. Nothing in it was written from memory. The title is the nurse's phrase, and the wording is pasted from the screen. The steps are the working note with the dead end removed, and the check is what she had just done. It is not a finished article. It is a draft that would have saved the dispensary ticket an hour, which is the standard it was written to.

The "looks similar but is not this" line earns its place more often than any other, because symptoms share words. "Keeps logging me out" is also what a requester says when their password has expired, when two people share an account, and when a browser is clearing its cookies. One line that says what this article is not stops the next technician applying a clock fix to a password problem. The line costs the author ten seconds, because the author has just spent twenty minutes learning exactly what this problem is not.

Save It Where Only Agents See It First

The draft is saved where the desk can see it and requesters cannot. The reason is that a draft is allowed to be wrong. It was written in two minutes by one person from one ticket. It may describe a fix that works in room 4 and not in the dispensary. It may contain steps only a technician should take, such as changing a time source on a domain-joined PC. It may be titled in a nurse's words that a different nurse would not use. All of that is fine in front of colleagues, who will correct it on the next use. None of it is fine in front of a requester, who will follow it faithfully and raise a ticket when it fails.

Most knowledge base tools have a way to do this, and it should be the first thing the desk agrees. Some let each article be visible to agents only or to everyone. QuerySolv's knowledge base works that way. So a draft can start life visible to the desk alone and be opened up later when it has earned it. Some have a draft state that hides the article until it is published. Some have neither, and then the desk uses a folder, a tag or a title prefix such as "DRAFT:" by convention. In that case, the convention is written down and kept. What matters is that there is exactly one place drafts go, and that everyone on the desk searches it. Nothing in it should reach a requester until someone has chosen to let it.

Agents-only is also what makes the two minutes possible. A technician who knows the draft will be read by patients, or by the finance director, will polish it. Polishing takes twenty minutes and so does not happen. A technician who knows the draft will be read by Priya, who sits opposite and will fix anything daft, writes it in two minutes and gets back to the queue. The audience for a draft is the colleague at the next desk. The audience for a published article is everyone. The path from one to the other is a separate, deliberate step, described in From Draft to Published: The Light Review.

What to Leave Out, and Why Two Minutes Is Enough

The draft leaves out everything that takes longer than copying, and that is a rule rather than a shortcut. No screenshots: they take five minutes, they date, and the article may never be used. No introduction, no background on how the clinic's time servers are arranged, no explanation of why session tokens care about clocks. No careful wording for a nervous reader. No formatting beyond numbered steps. Each of those things makes an article better and each is worth doing when the article has proved it will be used. That is a thing the author cannot know at 10:52 on the day. Two minutes buys the part of the article whose value does not depend on knowing.

The missing parts are not forgotten. They are deferred to the people who will use the draft, which is how an article grows without anyone scheduling the growth. The next technician confirms the fix works on a second machine and says so. The third adds the step that Nadia did without noticing. Whoever promotes it to requesters rewrites the steps in words a receptionist can follow and adds the one screenshot that helps. That is the subject of Refine on Reuse, and it depends on the draft existing. A draft with a fifth of the finished article's polish and all of its facts is worth more than a finished article that was never started.

I used to write the whole article at the moment of the fix, with screenshots, because I was proud of the fix. It felt like the thorough thing to do. It took twenty-five minutes, which meant I did it perhaps one time in five, and the other four fixes got nothing. A desk of four doing two-minute drafts on every reusable fix produces more useful knowledge in a month than I produced in a year of thoroughness. Thorough, it turns out, is a quality of knowledge bases, not of individual articles, and it comes from coverage.

When Not to Draft

The test is one question: would a second person ever meet this? Consider a damaged cable, a single misdelivered monitor, or a request that only the finance director could make. Or consider a one-time data fix for a report that will never be run again. No second person will meet these, and the draft would be an article nobody reads. Close the ticket, with a good resolution note, and move on. The habit is for the ticket where the technician had to work something out that someone else might one day have to work out again.

Be careful with "rare", which is not the same as "one-off". The licence server that drops its licences twice a year is rare and is exactly the kind of problem that needs a draft. Twice a year is often enough to recur and seldom enough that nobody remembers the fix. The test is not how often the symptom appears. It is whether it can appear to someone who was not there the first time. For most non-routine fixes on a desk of more than one person the answer is yes. When in doubt, draft. The cost of a draft nobody uses is two minutes and a little clutter in an agents-only folder. The cost of the one that was needed and not written is the next forty minutes.

Routine work is the other exclusion, and it is a matter of judgement that settles quickly. Password resets, new-starter accounts, standard software installs: these are already documented, or should be in a procedure the desk follows rather than an article the desk discovers. Drafting them from a ticket adds nothing. The distinction is between knowledge the desk already has in writing and knowledge that was, until 10:52, only in Nadia's head. The habit is for the second kind. The first kind belongs to the runbooks, which are the subject of Writing the Runbook.

Making the Reply Do Double Duty

The public reply that closes the ticket is the first draft of the user-facing version of the article, if the technician writes it with that in mind. It costs nothing extra because the reply has to be written anyway. Nadia's reply to the nurses says what the problem was in plain words, what she did, and what to do if it comes back. Her reply is: "The two computers in room 4 had drifted eight minutes from the clinic's clock, and the records system signs you out when that happens. I have corrected them and they will stay in step from now on. If you see 'session expired' repeatedly on any other computer, let us know which one and we can fix it in a few minutes." That is three sentences a receptionist can understand, and it is most of the user-facing article.

Keeping the two apart on the ticket is what makes this work. The internal note holds the technician's version: the time source name, the resync command, the dead end in the records system settings. The public reply holds the requester's version: what it was, that it is fixed, what to watch for. In QuerySolv the internal note and the public reply sit side by side on the same ticket. So the draft for agents is lifted from one and the seed of the article for everyone is lifted from the other. In any tool that keeps the two kinds of message distinct, the same split is available. In a tool that does not, the technician keeps the split in their head and writes the reply as if a stranger will read it. One will.

The user-facing version is a different document from the technician's draft, with different rules about what it may contain. It is not written at 10:52. Writing the User Guide From the Runbook covers how the one is made from the other. The point here is narrower. A reply written in the requester's language, saying what the problem was and what to watch for, is a reply the desk will want to reuse. A technician who notices that while writing it has done the first part of the later job for free.

A Short War Story: The Weight Mismatch at Bellweather Logistics

At Bellweather Logistics' main depot, the handheld scanners at the packing benches showed "WEIGHT MISMATCH" and refused the parcel whenever the bench scale's reading disagreed with the order. About once a month a scale would start reporting in pounds after a battery change, so that every parcel on that bench mismatched. Kwame, who had been on the depot desk for four years, knew that you held the unit button for three seconds and it went back to kilograms. He fixed it nine times in a year from memory, each in about a minute. He never drafted it because it was a minute. In the depot's busiest week he was on leave. Ines, three weeks into the job, took the ticket at 06:40 from a bench supervisor who said "the scanner won't accept anything". She checked the scanner, the order data, the network to the bench and the scanner's firmware. She phoned the scale's supplier at 08:00 and ordered a replacement scale by nine. By that time forty parcels had missed the morning collection. The depot paid for an afternoon re-collection and apologised to forty customers. Kwame came back the following Monday, heard the story, and wrote the draft in two minutes with the scale in front of him. The one-minute fix you know by heart is the one you never write down, and the next person's clock starts from zero.

The In-Ticket Draft Block

The block below is the draft's shape as plain text. That means it can be kept as a snippet and pasted into a new agents-only article, or into an internal note when the knowledge base is not to hand. The headings are the four parts in the order the next technician needs them. Every blank is filled from the ticket rather than from memory. The last section is the honest list of what the draft does not yet have, written for whoever uses it next. It is the part that turns a draft into something that can grow. Filling the block takes about two minutes when the working note is good and about five when it is not. That is one more reason to write the working note.

IN-TICKET DRAFT BLOCK — PASTE INTO AN AGENTS-ONLY ARTICLE BEFORE CLOSING
Draft from ticket: ________   Written by: __________   Status: DRAFT, desk only

TITLE (the symptom, in the requester's words)
  _______________________________________________________________

WHERE IT HAPPENS
  Device / application / site / group: __________________________
  Exact wording on the screen: "_________________________________"
  Looks similar but is NOT this: _________________________________

CAUSE (write "not yet known" rather than guessing)
  _______________________________________________________________

FIX, AS STEPS, IN THE ORDER TO DO THEM
  1. ____________________________________________________________
  2. ____________________________________________________________
  3. ____________________________________________________________
  4. ____________________________________________________________
  Who can do it:  [ ] requester   [ ] technician remotely   [ ] at the device

THE CHECK THAT PROVED IT
  Looked at: ___________________________   For how long: ___________

NOT YET IN THIS DRAFT (for whoever uses it next)
  [ ] confirmed on a second machine or site
  [ ] cause confirmed
  [ ] wording a requester could follow
  [ ] screenshot, if one would help
  [ ] other: _____________________________________________________

Nadia pasted the block into a new agents-only article at 10:53. She closed ticket 4417 at 10:56 with a resolution note that shared most of its words. The dispensary PC did the same thing nineteen days later, while she was on leave. The technician who picked it up searched for "logging out" and found the draft. They had the clock corrected in six minutes and ticked "confirmed on a second machine" on the way out. The article was still agents-only and still had no screenshot. It had done the one job a draft exists to do, which is to be there.

Frequently Asked Questions