The Knowledge Base as a Training Tool for New Technicians

Monday, 09:40, at Bluewater Bank. Ines started an hour ago, and Gareth, who is meant to be training her, has been pulled into a branch outage. Before he left he sent her a link and said "have a read of the knowledge base, it's all in there". It is all in there. There are three hundred and forty articles, listed alphabetically, and Ines, who is conscientious, has started at the top. By ten she knows a great deal about accessibility settings for the branch tablets. By eleven she has reached the letter B and read four articles about the backup agent, none of which she will touch for a year. At lunch Gareth comes back and asks what she has learned. She says, truthfully, "the alphabet". He laughs, and then stops, because she is right and it is his fault.

Using the knowledge base as a training tool means treating the desk's written knowledge as the new technician's syllabus. The knowledge base is read in a deliberate order on the first days and searched before every ticket. It is added to in the third week, and corrected the first time the technician finds it wrong. The knowledge base is the desk's memory written down. And a new technician who reads it in the right order borrows a year of other people's patterns in a week. One who reads it alphabetically borrows the alphabet. This article is part of our Training & Developing Technicians series, and it is about the order, the habit and the first contribution.

It covers why the knowledge base is the syllabus, then the reading order for the first days. Next come the known-error list as the desk's memory, the category tour, and reading with the queue open. We cover writing the first article in week three, then the article the new technician finds wrong. We finish with keeping the reading list current, a short war story, and the reading list for a new starter to copy.

Why the Knowledge Base Is the Syllabus

Every fix the desk has written down is a pattern the new technician does not have to pay for. And the knowledge base is where those patterns are kept. A technician who has read the article on stale share credentials before the ticket arrives recognises the ticket. One who has not spends forty minutes earning the recognition. Reading is the cheapest training the desk has, by a distance, because the writing was done already and the reader can go at their own pace. The only thing the desk has to supply is the order, and the order is what Gareth forgot.

Order matters because knowledge bases are organised for finding, not for learning. An alphabetical list, or a list by category, or a search box, all serve a technician who knows what they are looking for, and a new technician does not. They need the articles that explain how the desk works before the articles that explain how to fix things. They need the fixes for the tickets that arrive daily before the fixes for the ones that arrive yearly. That is a syllabus, and no knowledge base I have seen comes with one built in. The desk writes it, once, as an article in the knowledge base itself, and the next new starter gets it on day one.

The syllabus also tells the new technician what the desk thinks is important, which is a lesson in itself. A reading list that starts with the scope document and the escalation routes says "we know what we support and where things go". One that starts with the twenty most common fixes says "most of your week will be these". A desk that has no list says "you'll pick it up". And the technician will, in roughly the order the queue chooses, which is to say no order at all.

The Reading Order for the First Days

The order has five layers, and the first layer is how the desk works. It includes the scope, which says what the desk supports and does not. It includes the categories the desk uses to sort tickets and what each one means. It also includes the escalation routes, which say where a ticket goes when the desk cannot finish it. Finally, it includes the desk's own tone guide, if it has one. None of these fix anything. All of them are needed to understand every other article. A technician who reads a fix without knowing which category it lives in or who to escalate to when it fails has read a recipe without knowing where the kitchen is.

The second layer is the fixes for the twenty most common tickets. And the desk finds them by looking at last quarter's ticket counts by category and taking the articles that match. These are the patterns the technician will use in their first week alone. Reading them on day two means that by day eight the symptoms are familiar before the requester has finished describing them. The third layer is the known-error list, described below, which is the desk's memory of what is broken right now. The fourth is the runbooks for the categories the technician will work alone in week three, read properly, with the steps understood and not skimmed. The fifth is everything else, by category, read over the following month in the gaps between tickets and never all at once.

Each layer has a stopping point, and the technician should stop there rather than reading on. Reading the backup agent articles on day one is not thoroughness. It is a sign that nobody said when to stop. Three hundred and forty articles read in a week are three hundred and forty articles forgotten in a fortnight. Twenty read on day two, with the queue open beside them, are twenty remembered for a career.

The Known-Error List as the Desk's Memory

A known error is a fault the desk understands, has not yet permanently fixed, and has a workaround for. And the known-error list is where those live. It holds the symptom a requester will report, the way to confirm it is that fault and not a similar one, and the workaround to apply. The list is the desk's short-term memory. And it is the single most valuable thing a new technician can read on day two. It stops them diagnosing from scratch a problem the desk solved last month and decided to live with. How the list is kept, and how a known error becomes a permanent fix, are the subject of Known Errors and Workarounds. Here the point is how the new technician uses it.

The technician reads the list on day two and then reads it every morning, because it changes, and the morning read takes three minutes. When a ticket arrives whose symptom matches an entry, the technician confirms the match using the entry's confirmation step. Once the match is confirmed, they apply the workaround and reply with the known-error wording the desk has agreed. That wording usually says that this is a known fault, that a permanent fix is in hand, and what to do in the meantime. The ticket is linked to the known error so that the count of affected people grows. And that count is what eventually gets the permanent fix funded. A new technician who does this on day nine has done problem management without knowing the phrase.

The list also teaches the new technician what the desk tolerates, which is useful knowledge about the organisation. A list with thirty entries, half of them older than a year, says the desk has learned to live with a great deal. A list with four entries, each with a fix date, says something else. Either way the technician should read it as a description of the place they have joined. The trainer should be ready for the question "why has this one been open so long?", which is a good question and deserves a straight answer. (The straight answer is usually "the vendor", and sometimes "us".)

The Category Tour

The category tour is an hour in the first week in which the trainer walks the new technician through the knowledge base by category. For each one, the trainer says what it holds, what is good in it, what is missing, and what the desk means by the category name. A category here is the label a desk puts on a ticket to say what kind of thing it is about, such as passwords, printing, or access requests. And the knowledge base is usually organised by the same labels, which is why the tour is possible. The tour is not reading; it is orientation. The technician comes out of it knowing where things are, which is different from knowing what they say.

The gaps found on the tour are a lesson of their own. Every knowledge base has a category with two articles where there should be twenty, usually because the person who knew that area never wrote anything down. And the trainer should say so plainly: "hardware is thin; most of what we know about the loan laptops is in Dev's head, and that is a problem we are working on". The new technician now knows where to be careful and where asking a colleague is faster than searching. A tour that pretends the knowledge base is complete teaches the technician to trust a thing that will let them down in week three.

The tour also shows the technician how the knowledge base is meant to be navigated, which matters because they will search it fifty times a day for a year. The structure that makes that possible, the naming, the categories, the one place for each thing, is laid out in A Structure That Stays Navigable. The trainer should point at the structure on the tour rather than describing it, because a structure seen once is remembered and one described is not. If the structure is poor, say so too. The technician will find out anyway, and it is better they hear it from the desk than conclude it alone.

Reading With the Queue Open

From day two, every ticket the technician works starts with a search of the knowledge base, before anything is tried. The trainer enforces the habit by asking "what does the knowledge base say?" before answering any question. The habit is called search first and it has its own article, Search First Before Solving, which this one borrows rather than repeats. For training the point is specific. A technician who searches first on every ticket in their first month reads the knowledge base in the order the queue presents it. That is the order of real need, and it is the best syllabus of all after the first five layers are done.

Reading with the queue open also means reading an article while looking at a ticket it applies to, and the pairing is what makes the article stick. An article about stale share credentials read on day two is a page of text. The same article read on day nine with a ticket that says "can't get to the shared drive, changed my password" beside it is a pattern that will never need reading again. The trainer can arrange this on purpose in the first fortnight by choosing the technician's tickets to match the layer-two articles. That way, the twenty common fixes are each read, then applied, within a few days of each other. It is the closest thing to a controlled lesson a help desk can offer.

When the search finds nothing, that is information too, and the technician should write it down: the ticket number, what they searched for, and that nothing came back. By the end of the month that list is the set of articles the desk is missing, found by the one person who did not already know the answers. It is the raw material for week three.

Writing the First Article in Week Three

In week three the new technician writes an article. The article is about a fix they have now done three times and found nothing written for, which the list from the previous section supplies. Three is the number because one fix might be a fluke, two might be a coincidence, and three is a pattern the desk will see again. The habit of writing the fix while it is fresh, and the shape of a quick first draft, are in The Capture Habit. The training point is that the new technician does it in week three on purpose, with the trainer reviewing. That way, it becomes a thing they do rather than a thing they watched others do.

The new technician is, briefly, the best writer on the desk for this one article, because they still remember not knowing. A senior technician writing about stale credentials will skip the step that is obvious to them. And it will be the step the next new starter needs. The new technician skips nothing, because a fortnight ago every step was news. Tell them this. It is true, and it is encouraging. And it explains why the desk wants the article from them and not from Gareth, who would write it in four lines and three of them would be wrong for a beginner.

The draft is reviewed by the trainer before anyone else relies on it, and until then it should sit where colleagues can see it and requesters cannot. If you run QuerySolv, the knowledge base lets an article be visible to agents only or to everyone. So the draft sits in the agents-only view until the trainer has read it and either the trainer or the technician has fixed what needed fixing. Most tools have a similar split or a draft state, and a shared folder marked "drafts" does the job where they do not. The review is kind and specific, one pass. Then the article is published with the technician's name on it, which is a small event and should be treated as one. A technician who has published an article in week three will publish twenty in their first year. One who has not will wait to be asked, and nobody asks.

The Article the New Technician Finds Wrong

Somewhere in the first month the new technician will follow an article and find that it does not work. That is because a screen has changed, a server has been renamed, or the step that mattered was never written down. What they do next tells the desk what kind of technician it has hired and what kind of desk they have joined. The right thing is to fix the ticket by other means, then fix the article, then tell the person whose name is on it. The wrong thing is to work around the article silently and leave it for the next person. And the wrong thing is what new technicians do by default, because they assume the article is right and they are missing something. Say on day one that they are not missing something. The article is wrong. Fix it.

Fixing it is possible only if every article has an owner, so that the new technician knows who to tell and the owner knows it changed. That rule belongs to Every Article Has a Name on It. For training, the owner's name turns a correction into a conversation: "I followed your share credentials article and step four doesn't exist any more; I've updated it, can you check I got it right?" is a sentence that teaches the technician something about the fix and teaches the owner something about the article. It teaches both of them that the knowledge base is maintained by whoever notices rather than by a documentation day that never comes.

The first correction is also a culture signal, and the trainer should make sure it lands well. A new technician whose first fix to an article is thanked will correct articles for the rest of their career, and the knowledge base will be better for it. One whose first fix is questioned, or quietly reverted, or met with "that's how we've always written it", will never touch another. And the desk has just lost its best proofreader. I have seen both. The second desk had a knowledge base nobody trusted, and could not understand why.

Keeping the Reading List Current

The reading list is itself an article in the knowledge base, owned by the desk lead. It goes stale in the same way everything else does, so it gets reviewed once a quarter when the ticket counts are looked at. If the twenty common fixes have shifted, because a new system arrived or an old one left, layer two changes. If the known-error list has moved, its link is checked. If a new category has been added to the desk's sorting, layer one gains a line. The review takes twenty minutes, and the moment to do it is the week a new starter is announced. That is when someone will read the list and notice the article about a system that was retired last spring.

The simplest way to keep the list honest is to ask each new starter at the end of their first month. Ask what they wish had been on it and what they read that they did not need, and change the list accordingly. The new starter is the only person who has recently used it for its purpose. Everyone else is guessing at what a beginner needs, from a distance of years, which is exactly the problem the list was meant to solve.

A Short War Story: The Alphabet at Stonebridge Insurance

At Stonebridge Insurance, a new technician called Ruth was given the knowledge base link on her first morning and nothing else. She read it alphabetically for three days because that was the order it was in. She reached the known-error list, which was filed under "K", on the Thursday afternoon after she had already started taking tickets. In her first week alone she diagnosed from scratch, twelve separate times, a fault in which the claims application hung for two minutes at the first login on Monday mornings. That had been a known error with a one-line workaround for seven months. Each diagnosis took her about forty minutes. Two of the twelve she escalated to the vendor. The vendor, who had already explained the fault once, was not warm about explaining it again. The desk lead costed the week at roughly eight hours of Ruth's time, a morning of the vendor's goodwill and twelve claims handlers who waited three times longer than the workaround would have taken. Ruth had been diligent throughout. The knowledge base had held the answer the whole time, three hundred articles in, under a letter nobody had told her to turn to first. A knowledge base without a reading order is a library without a syllabus. And the desk had handed a new starter the whole library and gone to lunch.

The Reading List for a New Starter

The list below is filled in by the desk lead or the trainer before the new technician's first day and stored as an article in the knowledge base itself. That way, it is found the way everything else is. Each layer has its stopping point and its day. The twenty common fixes are listed by name, because "the common ones" is not a reading list; the solo categories in layer four match the week-three list in the thirty-day plan. The bottom section is filled in by the new starter at the end of the month. And it is how the list gets better for the next one.

KNOWLEDGE BASE READING LIST — NEW STARTER
Desk: ______________   List owner: ______________   Last reviewed: ________
New starter: ______________   Trainer: ______________   Start date: ________

LAYER 1 — HOW THE DESK WORKS (day one, morning; stop when these are read)
  [ ] What we support and what we do not: ______________________ (article)
  [ ] The category list and what each category means: ______________________
  [ ] Escalation routes: where a ticket goes when we cannot finish it: ______________
  [ ] How we write to requesters (tone guide): ______________________

LAYER 2 — THE TWENTY COMMON FIXES (day one afternoon and day two)
  From last quarter's ticket counts by category. Read each with a ticket beside it.
   1. ____________________________    11. ____________________________
   2. ____________________________    12. ____________________________
   3. ____________________________    13. ____________________________
   4. ____________________________    14. ____________________________
   5. ____________________________    15. ____________________________
   6. ____________________________    16. ____________________________
   7. ____________________________    17. ____________________________
   8. ____________________________    18. ____________________________
   9. ____________________________    19. ____________________________
  10. ____________________________    20. ____________________________

LAYER 3 — THE KNOWN-ERROR LIST (day two, then three minutes every morning)
  Where it lives: ______________________   Entries at last count: ______
  The agreed known-error reply wording is in: ______________________

LAYER 4 — RUNBOOKS FOR THE CATEGORIES WORKED ALONE IN WEEK THREE (days 3-5)
  Category: ______________  Runbook: ______________________  Read closely: [ ]
  Category: ______________  Runbook: ______________________  Read closely: [ ]
  Category: ______________  Runbook: ______________________  Read closely: [ ]
  Category: ______________  Runbook: ______________________  Read closely: [ ]

LAYER 5 — EVERYTHING ELSE (weeks two to four, in the gaps, by category)
  Category tour with the trainer on: ________   Thin areas named on the tour:
  ______________________________________________________________

WHILE READING
  Every ticket starts with a search.  Searches that found nothing (ticket, terms):
  ______________________________________________________________
  ______________________________________________________________

WEEK THREE — FIRST ARTICLE
  Fix done three times with nothing written: ______________________
  Draft reviewed by: ______________  on ________   Published on: ________

FIRST ARTICLE FOUND WRONG
  Article: ______________________  Owner told: ______________  Fixed on: ________

END OF MONTH — FROM THE NEW STARTER
  What should have been on this list: ______________________________________
  What was on it and was not needed: ______________________________________

Gareth wrote the list for Ines on the Monday evening, late, by looking at the quarter's ticket counts and copying twenty article names into a draft. She read layer one on the Tuesday morning and the twenty fixes by Wednesday lunch, with Gareth choosing her tickets to match. On day sixteen she wrote an article about a branch tablet fault she had now fixed three times. On day twenty-two she found that the share credentials article still referred to a server that had been renamed. She fixed the article and told Gareth, who had written it and had not looked at it in two years. He thanked her. Then he went back and read the backup agent articles himself, alphabetically, for reasons he did not explain.

Frequently Asked Questions