Search That Answers Before the Ticket Is Raised

Monday, 10:05, at Ashgrove Housing. Tom, a housing officer, opens the portal, types "wifi not working" into the search box, and gets a page that says "No results". He raises ticket 7718 with the same four words in the subject line. Leah on the desk reads it, pastes a link, and closes it within a minute, because there is an article. It is called "Wireless Network Connectivity Troubleshooting (Corporate SSID)". It is thorough and has screenshots. It contains neither the word "wifi" nor the word "working". Tom replies, a little stiffly, "I did search."

He did. The search did not fail, either. It did exactly what it was asked, which was to find the words "wifi not working", and those words appear nowhere in the knowledge base. The article was written in the desk's language and searched in the user's. And the two languages do not overlap enough for a search box to bridge them. The ticket was raised. The technician spent a minute. And the article's view counter went up by one, after the fact, which is the wrong order for everything.

Search that answers is a search box which, for the words a user actually types, puts an article the user can follow in the first three results. The knowledge base is the collection of those articles; the portal is the page where users search it and raise tickets. The search box is the single most-used thing on the portal. And the quality of what it returns is set almost entirely by how the articles are titled and worded, not by the search engine behind it. This article is part of our Ticket Deflection Strategy series. And it is about tuning the words so that the search answers before the ticket.

It covers why the search box is the front door and what a "no results" page teaches. Next come titles as questions, with a table of rewrites, then the words users actually use and where to collect them for free. It explains the failed-search log: what it is, where it comes from and how to read it weekly. Then comes the top-ten box for the user who does not know what to type, and reading the results page as a user would. It covers the weekly tuning habit, with a worked example from one fictional desk. A short war story follows, then the search tuning sheet to copy.

The Search Box Is the Front Door

Most users who come to the portal with a question search before they do anything else. What the search returns decides whether they will ever search again. A user whose first search returns a followable article learns that the portal answers things. A user whose first search returns "No results" learns the opposite, and that lesson lasts. They will raise tickets from then on without looking. And no later improvement to the knowledge base will reach them, because they have stopped asking it. A search box that returns nothing is a sign on the door saying "closed", printed in a font only the user can read.

The search engine is rarely the problem. Nearly every portal's search does the same simple thing. It looks for the typed words in the title and the body of each article and ranks the ones with the most matches first. Some add a little cleverness about word endings, so "printing" finds "print". Most do not understand that "wifi" and "wireless" are the same thing, and none understand that "the finance thing" means the expense system. The search is a word matcher. It can only find words that are there. And that puts the whole job on the person who writes the article, which is the desk.

Structure matters less than people expect. A knowledge base with a deep tree of categories and a search that cannot find "wifi" is a filing system nobody uses. A flat list of forty articles with good titles and a search that finds them is a knowledge base. The structure question, and why flat with good titles beats deep, is in A Structure That Stays Navigable. This article assumes the search-first user and tunes for them, because that is who Tom was and who most users are.

Titles as Questions

The title is the one part of an article that search reads reliably and that the results page shows. It is what the user reads before deciding to click, so it carries most of the weight. Write it the way the question is asked, by the person asking it, at the moment they ask. "Wi-Fi not working on my laptop" is a title. "Wireless Network Connectivity Troubleshooting (Corporate SSID)" is a filename. Both describe the same article, and only one of them will ever be typed into a search box by a housing officer.

Title the symptom, not the cause, because the user knows the symptom and the desk knows the cause. The user sees "sync failed"; the desk knows it is a cache problem. The user sees "the screen is black"; the desk knows the cable is loose. A title containing "cache" is invisible to everybody who has not already solved the problem. The symptom goes in the title, in the user's words, and the cause goes in the body for the technician who wants it.

Two further rules for the title. Put the system's everyday name in it, the name people say in the corridor, not the name on the licence. For example, use "the housing system", not the product's official title. If there is a product name in common use, use both. And put the exact words of any on-screen message in quotes. A user with an error on their screen will type it in verbatim. A title that contains the same string is a match the search cannot miss. The anatomy of the article beneath the title, the steps and the "what you should see" lines, is in the writing series. Here, the title is the deflection, and the body is what it deflects to.

The Words Users Actually Use

Users have their own vocabulary for every system and every fault, and the desk has to learn it rather than teach them the desk's. Nobody outside IT says "wireless"; they say "wifi", with or without the hyphen, and sometimes "the internet". Nobody says "remote access gateway"; they say "the VPN", "working from home", or "getting in from the house". The expense system is "expenses". The housing system is "the housing system" or the name of the supplier. And the shared drive is "the S drive" or "the drive". And every one of those words needs to be somewhere the search can see it.

The vocabulary is free, and the desk already has it. The subject lines of the last hundred tickets are a thesaurus written by the users themselves. Export them, read them in one sitting, and list every word users use for each system and each fault. "Wifi" will appear in three spellings. "Scanner" will turn out to mean three different devices. "The portal" will mean the help desk, the HR system and a supplier's site, which is a finding in itself. Twenty minutes with the subject lines teaches more about search than a year with the search engine's settings.

Where the synonyms go depends on the tool. Some knowledge bases have a keywords or tags field that the search reads but the user does not see. That is the right place for mis-spellings and slang. Some do not have that field. Then the synonyms go into the first line of the article as a plain sentence: "This covers Wi-Fi (wifi, wireless) on laptops and phones." Check yours by putting a made-up word in each field and searching for it. The title still gets the best word, the one most users type, because the title is what they see on the results page. A title stuffed with every synonym is unreadable. One word in the title, the rest in the body or the keywords, and the search finds all of them.

The Failed-Search Log

A failed search is a search that did not lead to an answer. It comes in two kinds: the one that returned nothing, and the one that returned something the user did not click. The second is the larger and quieter kind. The search for "scanner" returned four articles about the document scanner on the third floor. The user wanted the barcode scanner in the warehouse. So they read the titles, clicked none, and raised a ticket. From the search engine's side that was a success. From the user's it was a "no results" page with more text on it.

The failed-search log is a list of the terms users searched for that did not end in an article being opened. It is the single most useful document for tuning search. It lists the questions the knowledge base cannot currently answer, written in the exact words the search needs. Some portals log every search and whether a result was clicked, and then the log is a report. Many do not, and then the desk collects it by hand. The first reply on any ticket that could have been an article asks "what did you search for?". And the answer goes on a tally sheet. Three technicians asking that question for a month build a log worth having. The question itself, asked kindly, tells the user the desk wants the search to work for them.

Read the log weekly and sort each term into one of four outcomes. New article: the question is real, common, and nothing answers it. Add synonym: an article answers it, but under a different word, so the word goes into the keywords or the first line. Retitle: an article answers it and the title is the problem. Ignore: the search was for a person's name, a ticket number, or something the knowledge base will never hold. Every number from here to the end of the section is a worked example from the fictional desk at Ashgrove Housing. Leah's first month of tallies produced about sixty failed searches a week. They came down to fifteen distinct terms, of which eleven were spellings of five things. Four fixes, two retitles, one synonym and one new article, covered forty of the sixty. The search did not get better. The words did.

The Top-Ten Box

Some users do not know what to type, and the search box cannot help them, because a search box needs words. One user knows something is wrong with "the thing where I book rooms" but cannot name it. A new starter does not know the system has a name. A manager has been told to "sort out the access thing". For these users, the portal's front page shows the ten most-asked questions as a list, each a title in the user's words. The user recognises their question rather than typing it. The top-ten box is search for people who are not searching.

The ten come from the queue, by count, in the same way the first articles did. And they change with the season: start of term, year-end, the week a new system goes live. A box that has shown the same ten questions for two years is a box nobody reads any more. The regulars have learned it and the newcomers assume it is decoration. Refresh it quarterly from the counts. Drop anything that has stopped being asked, and keep it to ten. Eleven is a list and twenty is the FAQ page coming back under another name. The layout of the front page around it, and what else belongs there, is in Designing a Portal People Return To.

Reading the Results Page as a User

A search that answers is not finished at the results page; it is finished when the user has followed the article and the thing works. So read the results page the way a user does, with a problem and no patience. They see three titles, possibly five. They choose by title alone. The first line under it, if the portal shows one, is usually the article's opening sentence. That was written to be an introduction rather than a reason to click. Make the title decide the click. And make the first line say who the article is for: "For laptops on the office Wi-Fi; phones are covered separately."

Then the article has to deliver on its first screen. The user who clicked "Wi-Fi not working on my laptop" wants the first thing to try within one scroll. A page that opens with two paragraphs on how the wireless network is designed loses them before step one. The craft of writing for that reader, in that mood, is in Writing for the Frustrated Reader. The search side of it is only this. If the right article is in the results and the user still raises the ticket, the article failed after the search succeeded. In that case, the log should say so. "Found, clicked, not followed" is a failed search by any honest definition, and it is a writing problem wearing a search problem's coat.

Test the results page from the outside. Once a month, open the portal as a user would, from a browser that is not logged in as a technician. Type the top ten failed-search terms from the log. For each, note what came back and whether the first result would have answered it. Ten searches take ten minutes and show the portal as users see it. That is not how the desk sees it, because the desk already knows the titles.

The Weekly Tuning Habit

Search tuning is twenty minutes a week, owned by one person, done on the same day, and recorded on one sheet. The twenty minutes go on three things. First comes reading the failed-search log and sorting each term into its outcome. Next comes making the two or three fixes that outcome calls for. These are mostly retitles and synonyms and take minutes each. Last comes noting what was done so that next week's read can see whether the term disappeared from the log. A term that disappears was fixed. A term that persists after a retitle needed a different retitle, or a new article, and the sheet says which was tried.

Ownership matters more than the twenty minutes. Search tuning that is everyone's job is nobody's. The log fills up and is read by no one. In a year the portal has a hundred articles and the same "no results" page. Give one named person the sheet and the right to retitle any article without asking its author. A title is the search's property rather than the writer's. The author keeps the body. The tuner owns the words on the front.

Retitling serves two searches at once. The portal's search serves users. The technicians search the same knowledge base from the queue when a ticket arrives. A title in the user's words helps them too, because the ticket arrived in the user's words. If you run QuerySolv, an article can be visible to everyone or only to agents. Either way it is the same article with the same title. So a retitle made for the portal reaches the technician's search as well without a second edit. In any tool, keep one article per question and tune its title once, rather than keeping a public copy and an internal copy that drift apart. The measuring article in this series, Measuring What Got Deflected, uses the failed-search count as one of its inputs, which is a second reason to keep the log honest.

A Short War Story: The Handheld Terminals at Bellweather Logistics

At Bellweather Logistics, a technician called Ravi spent a fortnight writing forty knowledge base articles for the depot staff. Each was titled with the official name of the equipment it covered. They included six about the handheld barcode devices, all titled "Handheld Terminal: ..." because that was what the supplier's manual called them. Depot staff searched for "scanner", found nothing, and raised tickets. Over six weeks the desk closed about ninety scanner tickets by pasting links to articles that had been there the whole time. The review costed this at roughly fifteen hours of technician time. It cost a good deal more time for depot staff standing at a loading bay waiting for a reply. Nobody at the depot had ever said the words "handheld terminal" aloud. Ravi added "scanner" to the six titles in an afternoon. The scanner tickets fell by about two-thirds within a month, with no other change to the articles at all. A knowledge base speaks the user's language or it is not searched; the manual's name for a thing is the last word anyone will type.

The Search Tuning Sheet

The sheet below is the weekly twenty minutes on one page. The top section is the failed-search log for the week, one line per distinct term, with the count and the outcome chosen. The middle is the fixes made, so that next week's read can check whether each term vanished. The bottom is the monthly outside-in test, ten searches as a user, done on the first tuning session of the month. Fill it in by hand or as a spreadsheet. The point is that the terms, the outcomes and the fixes sit together. That way, the log is never just a list of things the search could not find.

THE SEARCH TUNING SHEET — ONE PAGE A WEEK
Desk: ______________________   Tuner: ______________   Week of: ________

1. FAILED-SEARCH LOG (one line per distinct term; group spellings together)
   Term as typed                       Count   Outcome
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   _________________________________   _____   [ ] new article  [ ] add synonym  [ ] retitle  [ ] ignore
   Source of the log:  [ ] portal search report   [ ] "what did you search for?" tally
   Found, clicked, not followed (writing problems) passed to the article owner: ____

2. FIXES MADE THIS WEEK
   Term                 Fix                        Article                       Check next week
   __________________   [ ] retitle  [ ] synonym   ___________________________   [ ] term gone  [ ] still there
   __________________   [ ] retitle  [ ] synonym   ___________________________   [ ] term gone  [ ] still there
   __________________   [ ] new article (draft by ________)   ________________   [ ] term gone  [ ] still there

3. TITLE RULES (check any new or retitled article against all four)
   [ ] Written as the question is asked, in the user's words
   [ ] Names the symptom, not the cause
   [ ] Uses the everyday name of the system, not the licence name
   [ ] Quotes any on-screen message exactly

4. MONTHLY OUTSIDE-IN TEST (first session of the month, as a user, not logged in as a technician)
   Term searched                 First result                          Would it have answered?
   ___________________________   ___________________________________   [ ] yes  [ ] no
   ___________________________   ___________________________________   [ ] yes  [ ] no
   ___________________________   ___________________________________   [ ] yes  [ ] no
   ___________________________   ___________________________________   [ ] yes  [ ] no
   ___________________________   ___________________________________   [ ] yes  [ ] no
   Terms still failing after a fix last month: ______________________________

5. TOP-TEN BOX (quarterly)
   Refreshed from ticket counts on: ________   Dropped: ________________   Added: ________________

Section two is the part that makes the sheet a loop rather than a list. A fix that is not checked the following week is a guess. And a term that keeps appearing after three different retitles is telling you the article does not answer the question, however it is named. Leah's sheet at Ashgrove has "wifi" on it from the first week, with "retitle" ticked. The following week's log does not have "wifi" on it at all. Tom searched again a month later, for something else. That is the result that matters: the front door opened once, so he tried it twice.

Frequently Asked Questions