The First Twenty Articles: Start From the Ticket Queue

Wednesday, 16:30, at Harbourview Clinic. The practice manager has noticed that the new help desk tool has a knowledge base, and has asked Rosa, who runs the three-person desk, whether the team "could populate it". Rosa has the knowledge base open. It is empty, and it is very tidy. Jonah thinks they should start with a style guide and an article template so that everything matches. Kwame thinks they should document the new phone system end to end while it is fresh. Rosa opens the ticket report for the last ninety days instead. Eleven hundred and forty tickets. The top line says "password reset or locked out", two hundred and twelve of them. The second says "printer", ninety-six. Nobody has proposed writing about either. Everybody has answered both, by hand, about once a day, for as long as they have worked there.

The first twenty articles are the top twenty ticket types by volume over the last quarter. Each is written as the answer the desk actually gives, by the person who gives it most often, in one week. That is the whole method, and the rest of this article is the detail. It is part of our Knowledge Base Fundamentals series. It exists because the question "what should we write first?" has a precise answer that almost nobody uses, preferring to write a style guide.

It covers why you start from the queue and not from a plan, then pulling the top twenty, with a worked tally. Next come which twenty make the cut and writing them in a week with the whole team, day by day. Then it covers what to skip for now and getting the articles used from the first day. A short war story and the seed list worksheet to copy finish the article.

Start From the Queue, Not From a Plan

The queue is a list of questions people actually asked, ranked by how often. Nothing you could write on a whiteboard will be a better guide to what the knowledge base should contain. Every other way of choosing the first articles is a guess. The vendor manual guesses that people want to know how the system works. The ops manager guesses that people want "proper documentation". The keen technician guesses that people want the thing they personally find interesting. The queue does not guess. It says two hundred and twelve people wanted their password reset, and that is the first article, however dull it is to write.

Plans come first because they feel like progress and cost nothing. A style guide can be written without knowing anything about the tickets. An article template with nine headings can be designed in an afternoon by someone who has never written an article. It will make every article that follows nine headings long. I once wrote exactly that template, and the first article produced under it had nine headings and no steps, because the author had run out of afternoon by heading six. Write the twenty articles first. Then write the style guide from the twenty, which will take an hour, because you will be describing what the desk already does rather than legislating what it might.

A shop stocks what sells. A knowledge base that opens with the twenty things people ask for every week is in use from the first day. Those twenty things get asked for next week too. Each article is opened within days of being written, by the technician who answers that ticket, who links it in the reply, where the requester sees it. The knowledge base earns its readership one common ticket at a time. The phone system documentation, however good, is opened when the phone system breaks, which is a different and much rarer day.

Pulling the Top Twenty

If the desk's ticket categories are any good, the top twenty is a report, and it takes five minutes. Run the volume report by category for the last ninety days, sort it, and read down. A ninety-day window is long enough to smooth out one bad month and short enough that the systems it describes still exist. Most help desk tools can produce this list from the standard reports. If you run QuerySolv, the volume report by department and the ticket search between them give the tally in an afternoon at most. What makes the report useful is what makes any category report useful. The categories describe what the desk did, not the org chart. The argument for that is in Categories That Make Reports Worth Reading.

If the categories are poor, or half the tickets are "Other", read the tickets instead. Export the last ninety days of closed tickets with their subject lines and first lines, or simply scroll them in the tool. Sort them into piles by what the desk did about each: "reset password", "fixed printer", "gave access to folder", "set up new starter". Name each pile in the words the requester used. Three hundred tickets take about an hour to tally this way, and the result is better than a bad category report, because the piles are already titled by the question. A spreadsheet with a column of pile names and a count beside each is the whole apparatus. If the tally and the category list disagree, the tally is right, and the category list has just told you something about itself.

Expect a steep curve. At Harbourview the top twenty types accounted for seven hundred and ten of the eleven hundred and forty tickets. That is the usual shape: a handful of types that arrive every day, a longer run that arrive weekly. Then there is a tail of hundreds of things that happened once. The table below is Harbourview's tally, cut to the top twelve for space, with the two columns that decide what gets written. "Who can follow it" says whether the article is for the requester, the desk, or both. "Write now?" is the decision. The reasons for the three that were skipped are in the section after next.

Two things in the table are worth noticing before moving on. The password line is a single ticket type that needs two articles. One is for requesters about enrolling in whatever self-service reset the organisation has. One is for the desk about doing the manual reset safely. The two readers need different things and must not see each other's. Why that one line is at the top of nearly every desk's tally, and what to do about it beyond an article, is the subject of Why Password Resets Dominate the Queue. The phone line is the opposite: five small questions that each arrived a handful of times and belong in one article with five short sections. A reader with a handset question will search "phone" and should find one answer, not five.

Which Twenty Make the Cut

A ticket type earns an article when four things are true: it repeats, the answer is stable, somebody can follow the answer, and the thing it describes is not about to change. Repeats means at least three times a quarter, and in practice the top twenty are all well past that. A stable answer means the desk does the same thing each time. A ticket type where every instance needs a different investigation is a problem to be investigated, not an article to be written. Followable means that either the requester or a technician in their first month could do it from the written steps. And "not about to change" is the test that removed two lines from Harbourview's table.

Volume is the first sort, not the only one. A ticket type with twenty-two tickets about a system being switched off next quarter is a wasted article. Consider a ticket type with thirty-one tickets about a known error with a permanent fix due next month. It already has its workaround written in the known-error record. It does not need a second copy that will be wrong in four weeks. Move down the list and take the next type instead. Conversely, a type with only eight tickets but a forty-minute answer that only one person knows jumps the queue. It is doing the third job of a knowledge base: remembering the fix after the person leaves. That job does not wait for volume.

Where a type is really two readers, write two articles or one article with a desk-only section, depending on what the tool allows. Where several small types are really one subject, as with the phone handset, write one. The count of twenty is a target, not a law; eighteen or twenty-three is fine. What is not fine is twenty articles that match twenty rows of a report and nothing a reader would recognise. Each article is titled by the question in the requester's words, exactly as the tally named the pile. The structure that keeps those titles findable is in A Knowledge Base Structure That Stays Navigable. The tally has already done most of that work, because the piles were named by the people who asked.

Writing Them in a Week With the Whole Team

The week has a shape, and the shape is what makes twenty articles possible without anyone being taken off the desk. Monday is the pick: thirty minutes with the whole team and the tally, deciding which twenty. Each is assigned to the person who closes that ticket type most, which the team will know without looking. On a desk of three that is six or seven articles each. Tuesday to Thursday are the writing days: two articles a day each, in a blocked ninety minutes that the rota protects, with triage and the queue carrying on around it. Friday is the swap: every article is followed, step by step, by someone who did not write it, and fixed on the spot. Published by Friday afternoon. The week is over.

Each article takes twenty to thirty minutes to draft. It takes so little because the draft already exists in the last three tickets of that type. Open them. The resolution notes say what was done; the requester's first message says how the question is asked; the back-and-forth says which step people get wrong. The article is those three tickets generalised. The title is the requester's words. The first line says who the article is for and what they will have at the end. The steps are numbered and say what the reader will see after each. The last line says what to do if it did not work. That shape, and the reasons for each part of it, are the subject of The Anatomy of a Followable Article. For the first twenty, the rule is simpler: a title, the steps, and what to do when it fails. Nothing else is required, and nothing else should delay publishing.

Friday's swap is the step everyone wants to skip, and it is the step that makes the articles true. The author knows what they meant; the reader has only what they wrote. Kwame follows Jonah's e-mail-on-a-phone article and discovers that step four says "enter the server name". It does not say what the server name is, because Jonah has typed it a hundred times and no longer sees it. That is a two-minute fix on Friday and a ticket every week if it is published as is. The swap takes about ten minutes per article, so two hours per person for the day. A five-minute stand-up each morning of the week ("which are done, which are stuck") keeps the stuck ones from becoming the silent ones. Twenty articles, three people, one week, inside working hours. It is not heroic. It is a rota.

What to Skip for Now

Skip the one-offs. A ticket that arrived once and was hard does not need an article; it needs a good resolution note, which the ticket already has. If it arrives again, it has started to repeat, and it goes on the list for the next twenty. The tail of a ticket tally is long, and every item on it looks worth writing up to the person who solved it, because solving it was memorable. Memorable and recurring are different properties. Write for recurring.

Skip the system that is being replaced, the full documentation of anything, and the policies. The archive system at Harbourview had twenty-two tickets and three months to live; an article about it would have been correct for ninety days and wrong forever after, with nobody to retire it. Full documentation of the phone system is a runbook. It lives with the system's build notes and is read on the day the phone system fails. It is not an answer to a question anybody asked this quarter. Policies are documents people are required to read, not answers people search for. Putting them in the knowledge base in week one teaches search to return the printing policy when someone types "printer".

Skip the style guide, the template, the review workflow and the launch announcement. All four are week-five work, and all four are better for being written by someone who has read twenty real articles. Do not write the style guide first. Not a short one. Not "just the headings". The twenty articles will have a style, because three people writing from the same tickets in the same week converge on one. The guide can describe it afterwards in an hour. The launch announcement is skipped for a different reason. The twenty articles announce themselves, one reply at a time, to exactly the people who need them. That is a better launch than any e-mail to all staff.

And skip perfection. A five-line article that is right beats a two-page article that is not finished, and the five-line article can grow the next time the ticket arrives. The first twenty will be rough. Some will have a step missing that Friday's swap did not catch. The technician who finds it the following Tuesday will fix it in a minute, because it has a name on it. The habit of fixing what you find is cheaper than the habit of noting it for later. The articles are not the finished knowledge base. They are the twenty seeds, and seeds are small.

Getting Them Used From the First Day

An article is used when it is linked in a reply. From the Monday after the writing week, every ticket of one of the twenty types gets a reply with the article's link in it. That is the rule, every time, even when the technician could have typed the answer faster. "Here are the steps: [link]. If you get stuck at any step, reply and tell me which one." The requester reads the article, which is job one of the knowledge base. The technician has opened it to check it still says the right thing, which is job two. And the article has had a reader this week, which is the test of a living knowledge base and the number the editor will ask about on Monday.

Tell the desk what exists, once, in one line per article, in the team's chat: "Twenty articles are up; the list is pinned; search before you type." Then make searching first the habit, which is the subject of its own article in the capture series. It takes about a fortnight to stick when the articles are the ones the desk actually needs. Run the twenty-search test at the end of week two. Type the requester's words for each of the twenty types and check that the article comes first. Retitle any that do not. Then count: how many of the twenty were opened from a ticket in the fortnight? At Harbourview it was seventeen. The other three had titles in the desk's words rather than the requester's, which the test found in fifteen minutes.

The next twenty are not another writing week. They come from the tickets, one at a time. As the desk closes a ticket of a type that is starting to repeat, it drafts the article inside the ticket while the fix is fresh. That is the habit described in The Capture Habit. The writing week is a one-time seeding, to give the knowledge base enough articles that the desk opens it daily and the habit has somewhere to land. After that the knowledge base grows at the speed of the queue, which is the right speed, because the queue is the only reliable source of what to write.

A Short War Story: The Phone System Manual at Larkhill Academy

Larkhill Academy, a secondary school with twelve hundred pupils and a two-person IT desk, replaced its phone system over the summer. Tomasz, who ran the desk, spent four weeks of the holiday writing forty-eight knowledge base articles. They documented the new system end to end, from handset buttons to hunt-group configuration. The business manager had asked for "proper documentation this time", and the empty knowledge base was there. Term started. The top ticket type in the first month was "cannot log in to the learning platform from home", with seventy-one tickets from parents, pupils and staff. Each was answered by hand in about ten minutes, which is twelve hours of the two-person desk's September. The second was printer credit top-ups, forty tickets, the same. There was no article for either, because neither had been asked during the holidays. The forty-eight phone articles were opened four times in the term, three of them by Tomasz. In October, he ran a ninety-day tally and wrote the twenty articles the tally named in one week with his colleague. The learning platform ticket fell to a handful by half term as the article went out in every reply. The knowledge base had been populated; it had just been populated with answers to questions nobody was asking.

The Seed List Worksheet

The worksheet below is the tally, the cut, the assignment and the week on one page. Fill the tally from the category report or from reading the tickets; apply the four tests to each row; assign by who closes it most; and run the Friday swap before anything is published. The last block is the fortnight-after check, which is the moment you learn whether the twenty were the right twenty. Keep the sheet; the next time someone asks what the knowledge base should contain, the answer is to fill it in again.

KNOWLEDGE BASE SEED LIST — THE FIRST TWENTY
Desk: ______________________   Window: last 90 days   Total tickets: ______
Source:  [ ] category report   [ ] tally of closed tickets by what the desk did

THE TALLY (top rows, in the requester's words)
 #  Ticket type                          Count  Repeats 3+?  Stable fix?  Followable by  Changing soon?  Write?
 1  _________________________________    ____   [ ]          [ ]          [ ]req [ ]desk  [ ]            [ ]
 2  _________________________________    ____   [ ]          [ ]          [ ]req [ ]desk  [ ]            [ ]
 3  _________________________________    ____   [ ]          [ ]          [ ]req [ ]desk  [ ]            [ ]
 ...
 25 _________________________________    ____   [ ]          [ ]          [ ]req [ ]desk  [ ]            [ ]
Top twenty cover ____ of ____ tickets.   Skipped and why: ______________________

THE CUT
  Types needing two articles (requester and desk): ______________________
  Small types merged into one article: ______________________
  Jumped the queue (low volume, one person knows it): ______________________
  Final list: ____ articles

THE WEEK
  Monday (30 min, whole team): pick the list, assign each article by who closes it most
     Name: __________  articles: ____    Name: __________  articles: ____
     Name: __________  articles: ____
  Tue - Thu (90 min blocked per person per day): two articles a day each, drafted
     from the last three tickets of that type: title, steps, what to do if it fails
  Daily 5-min stand-up: done ____  stuck ____
  Friday: every article followed by someone who did not write it; fixed; published
     Articles published by Friday: ____ of ____

FROM THE FOLLOWING MONDAY
  [ ] every ticket of these types gets a reply with the article's link, every time
  [ ] one line in team chat listing what exists; list pinned
  [ ] owner and review date set on each article in the register

TWO WEEKS AFTER
  Twenty-search test (requester's words): found first ____ of 20   retitled: ____
  Articles opened from a ticket in the fortnight: ____ of 20
  Ticket types still arriving with no article offered: ______________________

Rosa ran the week at Harbourview in the fortnight after the practice manager asked. Twenty-one articles were published by the Friday, two of them about passwords and one covering five phone handset questions. Jonah's e-mail-on-a-phone article got its server name on the Friday afternoon from Kwame, who had followed it and stopped at step four. By the end of the following fortnight, seventeen of the twenty-one had been opened from a ticket. The style guide was written in the fifth week, in an hour, by Jonah, from what the three of them had already done. It is one page long and nobody has needed to read it.

Frequently Asked Questions