Ownership: Every Article Has a Name on It

Tuesday, 10:40, at Stonebridge Insurance. Ben, in his second year on the desk, picks up ticket 7731 from a claims handler: "Followed the knowledge base article for exporting the monthly claims report. The menu it tells me to use isn't there. Screenshot attached." Ben opens the article. It is the top result for "claims report", and it has a tidy numbered list and three screenshots. Every one of the screenshots is of the old claims system, which was replaced two springs ago. The last-updated name on it is Fiona, who left eighteen months back. Ben walks the handler through the new export by phone, then looks at the article again. Should he fix it? Delete it? Is someone else already doing that? He has no idea who to ask, so he adds "claims report article out of date" to his to-do list. It goes under the other four articles he has found the same way.

Ownership of a knowledge base means two things, and a knowledge base needs both. One named person is responsible for each article being right. One named person is responsible for the whole collection being navigable, reviewed, and free of articles that nobody owns. The first is the owner; the second is the editor. Without owners, wrong articles stay wrong because fixing them is nobody's job. Without an editor, articles stay orphaned because reassigning them is nobody's job either. This article is part of our Knowledge Base Fundamentals series, and it is about putting a name on everything.

It covers what ownership means and why one name beats a team, then the owner's three duties and the editor's job. Next come review dates and what they are for. Then it covers what happens when nobody owns an article: the article that outlives the system it describes. Choosing owners and the handover when the owner leaves follow. A short war story and the ownership register to copy finish the article.

One Name per Article, One Editor for the Whole

An owner is a single named person, and the word "single" is doing the work. An article owned by "IT Team" is owned by nobody. When Ben finds it wrong, he has to decide whether fixing it is his job. The honest answer in a team of five is that it is one fifth his job, which rounds to not today. An article owned by Fiona was owned by someone, until Fiona left and nobody noticed that the name on forty articles had stopped coming to work. An article owned by Ben is an article Ben will fix on Tuesday at 10:45. It has his name on it and the claims handler just told him it was wrong. The name is not a credit. It is the answer to the question "whose Tuesday does this belong to?"

The editor is the one person who holds the list. They know how many articles there are, which have no owner, and which are past their review date. They know which two answer the same question, and which have not been opened by anyone in a year. The editor does not write all the articles, or even most of them, and they do not approve every change. They keep the whole in order so that the owners can keep their parts right. On a desk of three the editor is the lead, and the job takes half an hour a week. On a desk of ten it might be a technician who likes tidiness, which is a real skill and should be treated as one. Whoever it is, their name goes on the purpose card, and the Monday question "was an article opened from a ticket this week?" is theirs to ask.

The two roles together close a gap that neither closes alone. Owners fix what they are told about; the editor finds the things nobody has told anyone about. Owners leave; the editor reassigns what they leave behind. Owners write new articles that duplicate old ones; the editor merges them. A knowledge base with owners and no editor decays at the edges, one orphan at a time. A knowledge base with an editor and no owners is one exhausted person apologising for forty articles. Think of a noticeboard: each notice has a name at the bottom, and one person has the key to the glass.

The Owner's Three Duties

The first duty is to keep the article right, and "right" means that a reader following it today gets the result it promises. The owner may learn the article is wrong from a ticket, a colleague, or their own reading. They fix it that day if the fix is small. If it is not, they put a stale notice at the top of it that day. A stale notice is one line: "This article is being updated; the export menu has moved, ask the desk for now". It turns a wrong article into an honest one in thirty seconds. The owner does not need permission to do either. The whole point of a name on the article is that the person with the name can act without asking.

The second duty is to look at the article on its review date and record that they did. The review is not a rewrite; it is a check, with three questions. Is this still how it is done? Has anyone opened it since the last review? Is the title still the words a reader would type? Most reviews end with "no change", and "reviewed, no change" is recorded with a new date, because a date is the only evidence that anyone has looked. An article with no review date is an article that will be checked when it fails, by the reader, at the worst moment. The mechanics of fitting those reviews into real weeks are in Maintenance Without a Documentation Day; the owner's duty is to turn up when the date arrives.

The third duty is to hand the article over before leaving it, whether leaving means another job, another team, or three months away. The owner lists their articles, agrees a new name for each with the editor, and spends twenty minutes with the new owner on the two or three that have history in them. That is all. An owner who does the first two duties and skips the third has done the knowledge base a favour that expires on their last day. What the owner is not responsible for is just as important. They do not have to approve edits by colleagues, defend the article against improvement, or write everything in their category. Anyone may fix a typo or a wrong menu name. The owner is simply told, and thanks them.

The Editor's Job

The editor keeps the register, which is the list of every article with its owner, audience, last check and next review, and reads it once a week. From the register come four routine jobs. Articles with no owner get one, by asking the person who most recently closed that ticket type. Articles past their review date get a reminder to the owner, and a second reminder a week later. After that, the editor reviews the article themselves and has a quiet word. Two articles answering the same question get merged, by the owner of whichever survives. And articles nobody has opened in a year get a question: "does anyone still need this?" It is asked out loud, with retirement as the default answer when nobody speaks.

The editor also owns the structure, which means saying no. When a technician wants a new category, the editor asks which ticket category it mirrors. When a department wants its own section, the editor explains why audience is a property and not a folder. When someone proposes writing forty articles over the summer from the vendor manuals, the editor asks which forty tickets they answer. None of this needs a committee or a form. It needs one person whose job it is to ask the question. The desk lead can overrule them if the answer is genuinely yes. A knowledge base without that person acquires an "Other" category by autumn and a second one, "Other (new)", by the following spring.

Half an hour a week is enough for a desk of up to about ten people and a few hundred articles. Most of it is reading the register sorted by review date. The editor's own measure is the one from the first article in this series: was an article opened from a ticket this week? If the answer is no for two weeks running, the editor's half hour becomes a conversation with the desk about why. Usually, the articles that would be opened do not exist yet, or exist under titles nobody would type. The editor cannot write their way out of that alone, and should not try. The editor's job is to notice, name it, and get the right owners writing.

Review Dates and What They Are For

A review date is the date on which someone has agreed to look at an article again. Its purpose is to replace "someone will notice if this goes wrong" with "Ben will look on the fourteenth". Set it when the article is published, by how quickly the subject changes. An article about a system that is upgraded twice a year is checked every six months. An article about how to request a loan laptop, a process that has not changed in living memory, is checked once a year. A known-error workaround is checked when the permanent fix is due, because that is the day it stops being true. There is no right interval; there is only an interval you have thought about, and the table below is where to start.

Record the review even when nothing changes. "Last checked" is a field, not a feeling. A reader who sees "last checked three weeks ago" on an article about the claims report trusts it. They will not trust an article whose only date is "created, by Fiona, long ago" in the same way. Some tools show the last-updated date automatically and nothing else, which punishes the owner who checked and found no change. In that case, the owner adds a one-line note at the bottom, "Checked on the fourteenth, no change", or the register carries the date. Either way the date exists and a reader can find it. An article nobody will admit to having looked at is an article nobody should follow.

The review date is also what makes the quarterly sweep possible, because a sweep is just the register sorted by the next-review column with everything due this quarter at the top. Without dates the sweep is "look at everything", which is the documentation day, which never comes. With dates it is twelve articles for Ben this quarter, at five minutes each, which is an hour, which he can find. The brief is to check, not to rewrite. Most of Ben's hour will be spent typing "no change" and a date, and that is the hour doing exactly what it is for.

What Happens When Nobody Owns: The Article That Outlives the System

An orphaned article does not know it is wrong. It says the same thing every day, with the same numbered steps and the same three screenshots. Because it is well written and has been there for years, search ranks it first and readers trust it. The claims report article at Stonebridge was a good article about a system that no longer existed. Every new claims handler since the replacement had read it, followed it, failed, and raised a ticket. The desk closed the tickets by phone without connecting any of them to the others. The article cost the desk a ticket a fortnight for two years, and nobody had decided to keep it. They had simply not decided to remove it, which is not the same thing and has the same result.

Orphans stay because deletion feels like destruction and nobody wants to be the one who destroyed something. Ben, finding the article wrong, had every reason not to act. He did not write it, and he did not know whether someone was already fixing it. He did not know whether some other department still used the old export, and he did not know whether he was allowed. Each of those is a question with a quick answer, if there is someone to ask. With no owner and no editor there is no one to ask, so the question is deferred, and a deferred question about an article is the article staying up. Four other technicians had the same to-do list entry as Ben. None of them compared lists.

The fix is an orphan audit, done once by the editor and then never needed again if the register is kept. List every article whose owner has left, moved teams, or was never set, and whose last check is older than the oldest system it could describe. At Stonebridge that was sixty-three of a hundred and ninety. Each one gets a decision in under a minute. If it is still true and still needed, assign an owner and a date. If it is probably true but uncertain, mark stale and assign an owner to check. If it describes something that no longer exists, archive with a note. Sixty-three decisions is an hour. The claims report article took eight seconds, because the screenshots gave it away. It had taken two years to get eight seconds of someone's time, and that is what "nobody owns it" costs.

Choosing Owners

The owner of an article is the person who most often does the thing it describes. Usually, that is the person who most often closes that ticket type. The register is filled in by asking that question for each article. Not the most senior person, not the person who wrote it, and never the manager, who will not be in the article on a Tuesday at 10:45 when it is found wrong. For an article about a business system, the system's administrator owns it if they are on the desk, or the technician who handles that system's tickets if they are not. For a known-error workaround, the problem owner. For a request process, whoever fulfils the request. If two people qualify, the one with fewer articles already.

Owner and author are different jobs, and keeping them separate stops the register from fossilising. The author wrote the article; the owner keeps it right; the author is often the first owner and should not be the last. When Fiona wrote the claims report article she was the obvious owner. When Fiona moved to the infrastructure team, the article needed a new one and did not get it. "Last updated by" was being read as "owner", and the tool was keeping the name current while the person drifted away. The register separates the two columns, and the editor reads only one of them.

Distribute the load, and start small. On a desk of four with the first twenty articles, five each is about right, and nobody should own more than they could check in an hour a quarter. If the knowledge base already has two hundred articles and four people, do not assign fifty each; that is a register nobody will honour. Retire first, by the orphan audit, until what remains is what the desk actually uses, and then assign that. I once accepted ownership of ninety articles in one afternoon because it seemed rude to refuse. I reviewed eleven of them, ever. The tickets at a desk work the same way: one name claims each, as in QuerySolv's claim-based ownership, and a ticket owned by a group is a ticket on nobody's list. Articles are no different, and need the same rule.

The Handover When the Owner Leaves

When an owner leaves, their articles are reassigned by name before their last day, as a line on the leaver checklist beside returning the laptop and reassigning their open tickets. The editor pulls the register filtered by the leaver's name, which is the first use most registers get and the one that justifies keeping it. Each article gets a new owner, chosen by the same rule as before: who does this now? The leaver then spends half an hour with the new owners. They do not read every article aloud but point at the two or three with history in them: "that one, the export order matters and the article does not say why; that one, the supplier's number changed and I never updated it." Half an hour. It is the cheapest half hour in the whole leaving process, and the one most often skipped.

The same reasoning applies to tickets when someone leaves. Reassign everything on the last day so that nothing sits under a name that is no longer on the rota. The routine is in Vacation Coverage Without the Pile. Articles are quieter than tickets, which is why they are forgotten. An open ticket under a leaver's name is found by the requester within a week. An article under a leaver's name is found by a reader in two years, and the reader does not know they have found anything. Some tools show a leaver's deactivated account as "unknown user" on their articles, which at least announces the orphan; some keep the name forever, which hides it. Check which yours does, and do not rely on either. Rely on the register.

Planned long absence is a lighter version of the same thing. An owner going away for three months names a stand-in for their articles in the register. The stand-in handles anything found wrong in the meantime and any review date that falls due. On return, the names go back. A desk where the only person who can fix the claims report article is on leave until spring is a desk with the hero problem described in The Seven Ways Support Quietly Fails, applied to writing. Knowledge that lives in one head is fragile. Knowledge that lives in an article with one name on it is slightly less fragile. Knowledge whose article has a name and a stand-in is a system.

A Short War Story: The Phantom Export at Wrenfield Pharmacy

Wrenfield Pharmacy ran nine branches, and its month-end stock reconciliation depended on an export that each branch manager ran from the dispensing system. They followed a knowledge base article written by Sanjay, a technician who had left for a hospital trust the previous year. In the summer, the dispensing system was upgraded. The supplier reused the menu item the article told managers to click for a different function. It marked the branch's stock as counted and reconciled without exporting anything. Three branch managers followed the article to the letter on the last Friday of the month, saw no error, and submitted nothing. On Monday, they discovered that head office had three branches showing a perfect reconciliation against stock that nobody had counted. Two days of recounting across three branches followed. A pharmacist was pulled off dispensing to supervise it. The finance director asked the desk, reasonably, who had approved the article. The answer was that Sanjay had written it and nobody had owned it since. So no one had been told the upgrade was coming and no one had looked. Priya, the desk lead, wrote the ownership register that week and assigned the forty-four orphaned articles in an afternoon. Priya put "notify article owners" on the change checklist for every system upgrade. An article with no owner is a promise with nobody behind it, and it will be kept until the day it is broken.

The Ownership Register

The register below is one table and two short blocks. It can live in a spreadsheet, a page at the top of the knowledge base, or the tool's own fields if it has them. One row per article; the owner is one name; the stand-in is for long absence; the status is one of four words. The editor reads it weekly, sorted by review due, and the leaver block is filled in on the day someone gives notice. Keep the audience column, because the desk-only articles are the ones most likely to be orphaned, since no user will ever report them wrong.

KNOWLEDGE BASE OWNERSHIP REGISTER
Editor (one name): ______________________   Reviewed weekly on: ________

ARTICLE                        CATEGORY      AUDIENCE   OWNER       STAND-IN    LAST CHECKED  REVIEW DUE  STATUS
_____________________________  ___________   [ ]all/[ ]desk  __________  __________  ________     ________    ______
_____________________________  ___________   [ ]all/[ ]desk  __________  __________  ________     ________    ______
_____________________________  ___________   [ ]all/[ ]desk  __________  __________  ________     ________    ______
Status is one of: current / stale (notice at top) / under review / archived

EDITOR'S WEEKLY CHECKS (half an hour)
  [ ] Any article with no owner?  Assign to whoever closes that ticket type.
  [ ] Any review date passed?  Remind the owner; second reminder in a week.
  [ ] Any owner who has left or moved?  Run the leaver block below.
  [ ] Two articles answering one question?  Merge; the owner of the survivor decides.
  [ ] Any article unopened for a year?  Ask the desk; retire by default.
  [ ] Monday question asked: was an article opened from a ticket this week? ______

LEAVER OR LONG-ABSENCE BLOCK
  Leaving / away: ______________   Last day / back on: ________
  Articles under their name (from the register): ____
  New owner agreed for each, by name:  [ ]
  Half-hour walkthrough of the articles with history in them:  [ ] date ________
  Open tickets under their name reassigned the same day:  [ ]

ORPHAN AUDIT (once, then never needed if the register is kept)
  Articles with no current owner or last check older than the system: ____
  Decided today:  keep and assign ____   mark stale and assign ____   archive ____

Ben took the claims report article to the desk lead on the Tuesday afternoon, who admitted there was no editor and became one on the spot. The orphan audit the following week found sixty-three articles with no living owner and archived twenty-eight of them in an hour. It gave Ben the claims report, which he rewrote in twenty minutes from the phone call he had already made. The ticket that had been arriving once a fortnight for two years stopped. The four other technicians' to-do lists turned out to contain nineteen articles between them, eleven of them the same ones, and all nineteen have a name on them now. The names are the whole trick.

Frequently Asked Questions