Search First, Before Solving: The Ninety-Second Habit

Monday, 08:40, at Ashgrove Housing. Tomasz is in his third week on the desk. He has picked up a ticket from Bernadette, a housing officer: "The rent statement export opens with everything squashed into one column. Can't do my arrears calls until it's sorted." He opens the spreadsheet tool and exports a statement himself. He gets the same single column and starts working through the import settings. Twenty minutes later he is reading a forum about file encodings. At 09:15 Yusuf walks past with a coffee, glances at the screen, and says, "Did you search the tickets?" Tomasz had not. Ticket 7206 was closed two months ago. A different housing officer had raised it. Its resolution note reads: "Export is tab-separated. Open the spreadsheet tool first, use the import wizard, choose tab as the separator. Three steps. Sent her the steps." There is also an agents-only draft article titled "Rent export opens in one column", written from that ticket, four steps long. Thirty-five minutes, and the answer had been ninety seconds away the whole time.

Tomasz is not careless, and Yusuf did not think so. Tomasz did what a technician's instincts tell them to do when a problem arrives, which is to start solving it. The search is not an instinct. It is a habit, and habits have to be installed on purpose. That is what this article is for.

Searching first means that before touching anything on a new ticket, the technician spends up to ninety seconds searching the knowledge base and the closed tickets. They search for the words the requester used, then the words on the screen, then the name of the thing involved. It is the first step of the loop that this series describes. This step decides whether the ticket will reuse an article or produce one. And it is the step that makes the two-minute draft in The Capture Habit worth writing. A draft nobody searches for is a draft nobody finds. This article is part of our Capture Knowledge While Solving series, and it is about the ninety seconds.

It covers why technicians skip the search and what the skipping costs. Then come what to search with, in three passes, and where to look, in order. Next comes what to do when something is found, and what to do when nothing is. We cover why the failed search is the title of the draft. Then comes the failed search as a signal about what the knowledge base is missing. We cover the ninety-second limit and why it matters, then searching at triage, where the habit pays most. A short war story and the search-first routine to copy finish the article, in that order.

The Pull to Start Fixing

Technicians skip the search because solving feels like work and searching feels like delay. On a desk where the queue is visible that feeling is strong. A new ticket arrives, and the symptom is interesting. The technician has an idea about the cause, and the idea wants testing now. Searching first means setting the idea aside for ninety seconds to check whether someone has already had it. That is a small act of humility that nobody enjoys. It is also, on most desks, the single most valuable ninety seconds in the ticket.

Three beliefs keep the habit from forming, and all three are usually wrong. The first is "I would know if we had seen this before." On a desk of one, perhaps. On a desk of four, with leave, shifts and staff turnover, the ticket Yusuf closed two months ago is one Tomasz has never heard of. The desk's memory is not any one person's. The second is "searching takes too long." It takes ninety seconds when it is bounded, which is the subject of a later section. A technician who has never timed it is remembering the one occasion they searched for twenty minutes and found nothing. The third is "the knowledge base is empty anyway." That may be true of the knowledge base and is never true of the closed tickets.

That last point deserves its own paragraph, because it is what makes the habit possible on day one. Every desk that has used a ticketing tool for a year has a year of resolution notes. And those notes are a knowledge base that nobody organised. They are badly titled, inconsistent, and written for the ticket rather than the next reader. They still contain the fix for most of the symptoms the desk will see this month, because the desk saw them last month too. A desk with no knowledge base articles and five thousand closed tickets is not starting from nothing. It is starting from a knowledge base with a poor index, and the search is the index.

What to Search With: Their Words, the Screen's Words, the Thing's Name

Search with the requester's words first, because those are the words the last requester used too. They are the words a good draft is titled with. Bernadette wrote "everything squashed into one column". The last housing officer wrote "all in one column". A search for "one column" finds both the closed ticket and the draft. A search for Tomasz's diagnosis, "tab-separated export encoding", finds nothing. Nobody describing the symptom has ever used those words. The technician who fixed it used them only in the resolution note's body. Search for the problem as experienced, not as understood. The understanding is what you are trying to find.

The second pass is the exact wording on the screen, in quotation marks if the search tool honours them. Error text is the most reliable search string there is, because it is identical every time the problem occurs. Also, a technician who writes a working note to the standard in Notes for the Stranger Who Finds This Ticket Next Year will have pasted it verbatim. Ask the requester for it if the ticket does not include it: "What does it say exactly, word for word?" That question often ends the ticket on its own. Where there is no error text, the second pass is whatever is most specific and least variable about the symptom. That could be the name of the report, the field that is wrong, the time of day it happens.

The third pass is the name of the thing: the application, the device model, the site, the form. This pass is wide and finds too much, which is why it comes last. A search for "rent statement" returns every ticket about rent statements, including the twelve about the figures being wrong. It is still worth running. It catches the case where the previous requester described the symptom in words that share nothing with this one. Also, a quick scan of the subject lines in the results often finds the right ticket by recognition. There are three passes, each a short string, each taking about twenty seconds to run and scan. The whole thing is inside the ninety seconds with time to spare.

Keep each search string short. Three or four words from the requester, the error text alone, one proper noun. Long search strings fail quietly because they match nothing, and the technician concludes there is nothing to find. The truth is that the last person wrote "one column" and this search asked for "export squashed into one column spreadsheet". Searches match words, not meanings. Give them fewer words and they match more.

Where to Look, in Order

There are four places to look and they are searched in a fixed order. It runs from the place most likely to hold a ready answer to the place most likely to hold a warning. Search the knowledge base first, including the desk-only drafts. A hit there is a written fix with steps and a check. Search the closed tickets second, because a hit there is a fix that worked but was never drafted. The resolution note will have to do. Search the open tickets third, because a hit there means the symptom is happening to someone else right now. That changes what kind of ticket this is. Search the list of known errors last, if the desk keeps one. A hit there is a symptom with a workaround and a permanent fix still pending. The ticket should be linked to it rather than solved afresh.

The order is about what a hit means, not about where hits are commonest. On a desk new to the habit, the closed tickets will produce most of the hits for the first few months. That is because the knowledge base is still thin. That is expected. Each closed-ticket hit is an invitation to draft the article this time, so that the next search hits the knowledge base instead. Over a quarter the balance shifts, and the knowledge base starts answering first. A desk can watch that shift happen. And it is the most encouraging thing about the method, because it means the ninety seconds are getting shorter.

The closed-ticket search depends on all the desk's tickets being in one place. That is worth saying because on some desks they are not. If you run QuerySolv, requests from e-mail, the web form, live chat and the rest all arrive as ordinary tickets in one queue. In that case, one search over closed tickets covers every channel the desk has. On a desk where chat conversations live in the chat tool and walk-ups live in nobody's memory, the search covers only what was logged. In that case, the fix that was given over chat last month is as lost as if it had never happened. The case for logging everything as a ticket is made elsewhere in this library. Here it is enough to say that the search is only as good as the record it searches.

The known errors list is the desk's register of symptoms it recognises but has not permanently fixed. It is searched separately for a reason. A known error's ticket should be linked to the known error rather than closed as an ordinary fix. That way, the count of occurrences keeps rising and the permanent fix keeps its business case. How to keep that list is the subject of Known Errors and Workarounds. It also covers what to tell the requester when their ticket is on the list. On a small desk the list may be a dozen entries and the search is a glance.

Found: Apply, Link, Refine

When the search finds an article, the technician reads the title and the "looks similar but is not this" line before anything else. The commonest way a found article wastes time is by being the wrong article with the right words. "Keeps logging me out" matches a clock-drift article, a password-expiry article and a shared-account article. The one line that says what each is not is what tells them apart. Having confirmed the match, the technician follows the steps and proves the fix with the check the article describes. Then they do the three things that Refine on Reuse asks. They fix the one thing that was wrong and write the article's number in the resolution note. They tick anything on the draft's "not yet" list that this use confirmed.

When the search finds a closed ticket but no article, the resolution note is the recipe, and it is usually a worse one. It was written for that ticket, in the order things were discovered, without a check. Follow it with more care than an article, and note where it was unclear. When the fix is proved, write the draft from this ticket as if the search had found nothing, with one addition. Link the two tickets, so the draft has two cases behind it from the day it is written. A closed-ticket hit is the method catching up on its own past. The second time the symptom appears is the last time anyone should have to read the resolution note.

When the article found is one the requester could follow themselves, send it, and say so in the ticket. A found article that fixes the problem in the first reply is the cheapest outcome a ticket can have. And it is the outcome the whole loop exists to produce. Whether a particular article is safe to send is a question about the article's state, draft or published, and about what it contains. A desk-only draft is never sent to a requester, however helpful it looks. It has not been through the check described in From Draft to Published: The Light Review. Send published articles. Use drafts yourself.

Not Found: Solve, and Keep the Search String

When ninety seconds finds nothing, the technician stops searching and starts solving. Before they start solving, they write one line in the working note: "Searched: one column, rent export, import wizard. Nothing." That line costs ten seconds and does two jobs. It tells the next technician who opens this ticket, at shift change or on reopen, that the search was done and what it covered. That way, they do not repeat it. And it preserves the search strings, which matter, because the words that found nothing are the words the draft will be titled with.

This is the point at which the capture habit and the search habit meet. The requester's phrase that returned no results is, by definition, a phrase nobody has written an article under. And it is also the phrase the next requester will use. When the fix is proved and the two-minute draft is written, its title is the first search string, more or less exactly. Tomasz searched for "one column" and found a draft. That was because Yusuf, two months earlier, had searched for "one column", found nothing, fixed it, and titled the draft with his failed search. The loop is that short.

Do not conclude from a failed search that the problem is new. It may be new. It may also be the fourth time the desk has seen it. The previous three technicians may have written resolution notes that said "fixed" and nothing else, which no search can find. A failed search tells the technician that the desk has no findable record of this symptom. That is a fact about the record rather than about the symptom. The response to a failed search is the same either way: solve it, and this time leave a record that the next search will find.

The Failed Search as a Signal

A failed search is also information for the desk, not just for the ticket. What people search for and do not find is a list of the articles the knowledge base most needs. One failed search for "one column" is an event. Three in a quarter, by three technicians, is a symptom that recurs and has no article. That is true even if each of the three technicians fixed it in five minutes and judged it too routine to draft. The judgement about what is worth drafting is unreliable at the moment of the fix. The pattern of failed searches is reliable, and it is the correction.

Collecting the signal takes little. Some knowledge base tools keep a log of what was searched and whether anything was clicked. And the entries with no click are the list. Where the tool does not, the "Searched: ... Nothing." line in the working note is the log. In that case, a search of closed tickets for the word "Searched:" once a month turns it into a list in a few minutes. Either way the lead reads it monthly and looks for repeated strings. The lead asks whoever last fixed that symptom to draft it from their most recent ticket. That is the only scheduled piece of writing this series asks for. It is pointed at articles the evidence says are needed rather than at a list of things someone once meant to write.

The same signal, read from the requesters' side, is a different subject. When requesters search the self-service portal and find nothing, the failed searches say what the portal should answer before a ticket is raised. That is the territory of Search That Answers Before the Ticket. The desk-side signal described here is about what technicians could not find. It tends to be more technical and to point at desk-only drafts rather than public articles. Both signals are worth reading. They come from different people and they point at different gaps.

Ninety Seconds, Then Stop

The search is cheap only because it is bounded, and the bound is as much a part of the habit as the searching. Ninety seconds is enough for three short passes over two places, with a glance at the open tickets and the known errors. It is not enough to read the whole of a long article, follow a chain of linked tickets, or try every synonym for "squashed". A technician who searches for fifteen minutes has not been thorough. They have spent fifteen minutes and found nothing, and the queue has moved on without them. At ninety seconds, if nothing has matched, nobody has written it, and the right thing to do is to go and write it.

The bound also protects the habit from its own failures. Consider a technician who searches without a limit, on the day the search finds nothing after twenty minutes. They will decide that searching is a waste of time and stop doing it. The habit dies on the one occasion it did not pay. A technician who searches for ninety seconds and finds nothing has lost ninety seconds. That is less than the walk to ask a colleague. They will search again tomorrow. Habits survive on a low cost of failure. Set the clock, and when it runs out, stop with a clear conscience.

There is one case where the ninety seconds is extended: the outage. When the ticket is one of several arriving about the same thing in the same hour, the valuable search is the one over open tickets. In that case, it is worth two more minutes to find out who else has it, who owns it, and whether it has been declared an incident. Solving it alone would be solving the wrong ticket. That is a search for a different reason, with a different result, and Major Incident Management covers what happens after the hit.

Search at Triage

The habit pays most when it is done by the person who first reads the ticket, before it is assigned. A hit at triage can close the ticket in the first reply. The triager reads "everything squashed into one column", searches for "one column", finds the published article, and replies with the article and three sentences. And the ticket is resolved before any technician has opened it. On a desk where triage is a role or a rota, that is the triager's ninety seconds. On a desk where whoever picks up the ticket triages it, the search is the first thing they do. Either way the search belongs at the front of the ticket, not at the point where the technician has run out of ideas.

Triage search uses the same three passes with one difference: the triager is looking for a published article the requester can follow. A desk-only draft is a reason to assign the ticket to the technician who wrote it rather than something to send. The first reply that includes an article should still answer the three questions every requester is asking: acknowledged, owned, and when they will hear. It should ask them to say if the steps do not work, so that the failure comes back as information. The discipline of that first touch is the subject of First-Touch Discipline; the search is the part of it this article adds.

A triage hit is also the clearest measure a desk has of whether the capture habit is paying. Count the tickets each month that were closed in the first reply with an article. And watch the count rise as the knowledge base fills from the loop. It will not rise quickly, and it will never reach the whole queue. Most tickets are requests for something to be done rather than problems to be understood. It will rise, and every one of them is a ticket that cost the desk two minutes instead of forty. It cost the requester a reply instead of a wait.

A Short War Story: The Chiller Tablets at Tollgate Foods

Tollgate Foods logged the temperature of every chiller and freezer in its warehouse with a tablet on each unit. After a battery change the tablet on chiller 3 showed "Sensor not paired" and stopped logging. Ade had been on the desk a year and had never seen the message. He spent the morning on it, reinstalling the logging app, restarting the sensor, reading the supplier's manual and finally phoning the supplier. The supplier told him at 12:20 to hold both buttons on the sensor for ten seconds until the light went green. Ticket 5590, closed four months earlier by a technician who had since left, was titled "chiller tablet thing not working". Its resolution note began: "Showed 'Sensor not paired' after battery swap. Hold both sensor buttons 10 sec until green. Took a minute." A search for "not paired" would have found it in under a minute. The chiller's temperature log had a gap of three hours and ten minutes. The next food safety audit recorded it as a non-conformance. The warehouse supervisor spent a morning writing the explanation and the corrective action, which was "search the ticket history before calling the supplier". Ade wrote the article that afternoon, titled "Chiller tablet says Sensor not paired after battery change". It has been found eleven times since by people who typed the words on the screen. The answer was ninety seconds away the whole morning, and the search was never run.

The Search-First Routine

The routine below is the ninety seconds as a card: three passes, two places each, and what to do with each outcome. It is meant to be followed literally for the first few weeks and then to become automatic. At that point the card can come down. The "Searched:" line in the working note is the one part of the routine that should never become optional. It is what turns a failed search into a signal and a title. New starters should be walked through it on their first ticket, with someone watching the clock.

THE SEARCH-FIRST ROUTINE — NINETY SECONDS BEFORE YOU TOUCH ANYTHING
Ticket: ________   Started: ____:____

PASS 1 — THEIR WORDS (three or four words from the requester's own description)
  Searched: "________________________"
  Knowledge base: [ ] hit  [ ] none      Closed tickets: [ ] hit  [ ] none

PASS 2 — THE SCREEN'S WORDS (the exact error text, in quotes)
  Searched: "________________________"
  Knowledge base: [ ] hit  [ ] none      Closed tickets: [ ] hit  [ ] none

PASS 3 — THE THING'S NAME (application, device model, site or form)
  Searched: "________________________"
  Knowledge base: [ ] hit  [ ] none      Closed tickets: [ ] hit  [ ] none

GLANCE — open tickets with the same words: [ ] none  [ ] yes, ticket ________
GLANCE — known errors list:                [ ] none  [ ] yes, KE ________

FOUND AN ARTICLE
  [ ] Title and "looks similar but is not this" line match this symptom
  [ ] Follow it; fix the one thing that is wrong; write its number in the note
  [ ] Published and requester-safe? Send it in the first reply and ask them to confirm

FOUND ONLY A CLOSED TICKET
  [ ] Follow the resolution note with care; link the two tickets
  [ ] Draft the article from this ticket before closing

FOUND NOTHING AT NINETY SECONDS
  [ ] Stop searching
  [ ] Working note: "Searched: ______, ______, ______. Nothing."
  [ ] Solve it, noting as you go
  [ ] Before closing: draft the article, titled with the words from pass 1

FOUND IT IN AN OPEN TICKET
  [ ] Link the tickets; agree one owner; ask whether this is an incident before starting

Yusuf sat with Tomasz for the next three new tickets and timed the routine on each. The results were seventy seconds, a hit on the second; fifty seconds, nothing, and a draft at the end. Then came eighty seconds, a closed ticket with a good note and a draft written from it. By the end of the week Tomasz was searching without the card and had stopped noticing he was doing it. That is what a habit is. Bernadette's export took four minutes once the draft was found. The draft had been written by Yusuf from his own failed search two months before. It got its second tick and a line saying the housing officers could do it themselves.

Frequently Asked Questions