Notes for the Stranger Who Finds This Ticket Next Year

Wednesday, 11:30, at Ashgrove Housing. Sam, four months on the desk, has a housing officer on the phone whose laptop cannot open the shared drive. An error on her screen reads "0x80070035: The network path was not found." Sam types the code into the ticket search. Nothing. He types "network path was not found." Nothing. He types "shared drive" and gets three hundred results, most of them about permissions. There are, in fact, four earlier tickets about this exact fault on this exact model of laptop. Each was fixed in ten minutes by the same technician in the same way. One is called "the F drive thing," and one "can't see the shared folder." Another is called "drive letter gone again," and one, with a confidence Sam will come to admire, "docs folder missing." None of them contains the error code. Sam spends two hours.

Findability is whether a ticket can be found later by someone who does not know it exists, using only the words they have. The stranger is that person. It could be a technician not yet hired, a colleague on another shift, or you, next year, with a vague memory and a search box. This article is part of our Writing Ticket Notes That Survive You series. And it is about writing every note on the ticket, from the first to the last, so that the stranger's search lands on it. The resolution note at the end of a ticket has its own article in resolution notes worth reading later. This one is about getting the stranger to the ticket at all.

It covers why search is how tickets are read later and what that means for the words you choose. Next come the error text, verbatim, and the names of devices, applications, accounts and places. Then we cover the words the next requester will use, which are not your words. We move on to linking related tickets and naming the cause once it is known, even on closed tickets. Then come the subject line, the common holes that make a ticket unfindable, and a short war story. We finish with the searchable-note checklist to copy.

Search Is How Tickets Are Read Later

Nobody browses old tickets. There are thousands of them, sorted by date, and the one you need is somewhere in the middle. Every ticket that is read after it is closed is found by a search, and a search matches words, not meaning. It does not know that "the F drive thing" and "0x80070035" are the same fault. It knows whether the characters you typed appear in the text. A search box has no imagination. It finds what you typed, provided somebody else typed it too.

This turns findability into a prediction problem with an easy answer. The stranger will search for one of three kinds of word. These are the error text as the system shows it, the name of the thing that is broken, or the symptom in the plain words a requester uses. Those three are predictable, and a note that contains all three is found by whichever one the stranger reaches for. A note that contains none of them, such as "fixed the drive issue for Anna," is found by searching for Anna. The stranger does not know to do that.

Findability is a property of the whole ticket, not just its last note. The stranger's search reads the subject, the requester's description, every internal note and every reply. And it is often a working note from the middle of the investigation that holds the exact phrase they typed. So the habit is not "write a searchable resolution note," though you should. It is "write the words that will be searched for at the moment you have them in front of you." The error text is cheapest to capture when it is on the screen. The requester's phrase is cheapest when they have just said it. Wait until the close and both are gone.

The Error Text, Verbatim

Copy the error exactly, with its code, in quotes, into the first note where it appears. "0x80070035: The network path was not found" is findable by the code, by "network path," and by "not found." "Some kind of network error" is findable by nobody, including the person who wrote it. The exactness matters more than it seems. A search for "path was not found" does not match "path could not be found." And the system's phrasing is the one the next requester will read out over the phone.

Screenshots are invisible to search. A screenshot of the error is useful for context. And a ticket with only a screenshot is a ticket that search will never return, however many times the fault recurs. Type the text as well, every time. If the requester has paraphrased the message, ask them to read it out exactly or send a picture, and transcribe it into the note. The phrase "it said something about permissions" is a memory of an error, not an error. Writing the text exactly is also part of the repro, and the reasons it matters for diagnosis are in writing reproducible steps. Here the reason is simpler: the exact text is the single most reliable search term the stranger will ever have.

Where the same fault shows different text in different places, record each variant as you meet it. The error in the dialog box, the line in the application log and the entry in the system event log often describe one fault three ways. The stranger may have any of them. A working note that says "dialog shows 'The network path was not found'; event log shows 'Error 59 from the redirector'" has doubled the ways the ticket can be found. It has cost twelve seconds.

Names: The Device, the Application, the Account, the Place

Name things as the systems name them, and as the people name them, and put both in the note. The file server is FS-01 to the desk and "the shared drive" or "the F drive" to the housing officers. The ticket should contain "FS-01," the full network path, and "F: drive," because the stranger may search for any of them. The laptop is HSG-LT-112 in the inventory and "my laptop" to its owner. The inventory name is the one to write, with the model as the asset register records it, because "my laptop" is five hundred machines.

Applications have a vendor's name, a shortcut name and a nickname, and the three rarely match. The housing officers' case system is called one thing on the shortcut, another in its title bar, and "the housing system" in conversation. Write all three the first time the application appears in a ticket, and the shortcut name every time after. A ticket about "the system" is unfindable; a ticket about "the housing case system" finds every other ticket about it, which is the point.

Places and accounts follow the same rule. "The second floor," "the Harbour Road office," "the warehouse mezzanine" are how the organisation names its places. Tickets that use those names can be grouped by place later. That is how you discover that every wireless complaint comes from one corner of one floor. Account names are written as the directory shows them, not as a first name, because there are three people called Sam. Nicknames, initials and private abbreviations are the enemy of findability. I spent a year writing "PRN2" for a printer that everyone else called "the big one by the kitchen," and neither of us could find the other's tickets.

The Words the Next Requester Will Use

A ticket has two vocabularies, and it needs both. The desk says "the shared drive is unreachable over the network from the laptop's wireless profile." The housing officer says "the F drive has gone again." Both are true. Only one of them will be typed into the search box by the next technician. That technician is working from what the next requester has just said, and the next requester says "gone." Write the technical description because it is precise, and write the requester's phrase because it is the one that comes back. No requester has ever reported "intermittent connectivity degradation to a file share." They report that the drive has vanished, and they are right.

The simplest way to carry both vocabularies is an "also described as" line in the first note. It holds the requester's own words in quotes and any phrases you know other requesters use for the same thing. "Also described as: 'the F drive thing,' 'drive letter gone,' 'docs folder missing,' 'can't see the shared folder.'" It takes ten seconds and makes the ticket findable by every phrase on the list. Sam, after his two hours, added that line to all four earlier tickets and to his own. The next technician who searched for "F drive" found five tickets in a row, with the fix in each.

Symptom words are a small set and worth learning: slow, frozen, stuck, spinning, hung, gone, missing, blank, kicked out, won't open, keeps asking, keeps closing. Requesters reach for these because they describe what the screen looks like, and the stranger searches for them because the next requester did too. When the requester uses one, keep it in the ticket, in their words, alongside your own. The two vocabularies are not redundant. They are two doors into the same room, and the stranger will come through whichever one they are standing nearest.

Linking Related Tickets

When you find an earlier ticket about the same fault, write its number into yours and yours into it, in both directions. A search that lands on the old ticket should lead forward as surely as one that lands on the new ticket leads back. Use a fixed form of words, such as "Related: 4471," the same way every time. That way, a search for "4471" finds every ticket that refers to it and a search for "Related:" finds every ticket that refers to anything. A reference written as "see the earlier one" or "same as last month's" is a link only to a person who already knows the answer.

Linking is not merging, and the difference matters for the record. Take two tickets about the same single occurrence, raised by two people because the drive vanished for both of them on the same morning. They are duplicates and can be merged into one. Two tickets about the same fault on different days are not duplicates. They are evidence that the fault recurs. They should stay separate and linked, because the count of linked tickets is what turns a nuisance into a problem worth fixing for good. Merging them destroys the count. Linking, merging and splitting tickets are ordinary operations in QuerySolv and in many other tools. Where yours cannot link tickets directly, the number written the same way every time does the same job.

Once a fault has three or more linked tickets it has stopped being a series of incidents and become a repeat worth investigating. The linked set is exactly what that investigation starts from. How to find the repeats you did not notice, and what to do with them, is the subject of finding the repeat tickets. The record that holds the workaround while the real fix waits is in known errors and workarounds. Neither is possible on a desk where related tickets cannot find each other, which is why the link belongs in the note and not in anyone's memory.

Naming the Cause Once It Is Known

When the cause is found, write it on the ticket in one line that begins "Cause:". The word "cause" is one the stranger will search for. And a ticket that describes a symptom and a fix but no cause is a ticket the stranger has to re-diagnose. "Cause: the laptop's wireless profile connects before the sign-in finishes, and the drive mapping runs before the network is up; the mapping script needs a delay." One sentence, and the next five tickets about vanished drives are ten-minute tickets instead of two-hour ones.

The cause is often found later than the ticket, sometimes months later, in a different ticket worked by a different person. Go back. Open the earlier tickets, closed as they are. And add the one-line cause to each with the number of the ticket where it was found. Most tools allow a note to be added to a closed ticket; some do not. Check yours. If it does not, the knowledge base is where the cause goes, with the ticket numbers listed in it. Either way the stranger's search for the error text lands on the earliest ticket because that is where the error text was first written. The search should find the cause waiting there and not a trail of three tickets that each say "restarted it, working now."

A cause that has recurred deserves a knowledge article of its own. And the article and the tickets should point at each other: the article carries the ticket numbers, and the tickets carry the article's title. Whether the article is visible to requesters or only to the desk depends on whether the fix is something a requester can safely do themselves. QuerySolv's knowledge base, like most, lets you choose per article. The article is the answer the stranger reads. The tickets are the evidence that it is the right answer, and the count that says how much it was worth finding.

Write what was ruled out as well, in the same findable way. "Not the server: FS-01 reachable from a wired desktop at the same moment" is a line the stranger can search for and a line that saves them an hour of checking the server. Ruling things out is half of diagnosis, and a ticket that records only the half that worked has thrown away the other half for whoever comes next.

The Subject Line Is Half the Battle

The subject line is what the stranger reads in the list of search results. Suppose a search returns twelve tickets called "Help!!," "Laptop," "URGENT drive" and "Re: Re: Fwd: issue." It has returned nothing the stranger can use without opening each one. Rewrite the subject the moment you understand the fault, in the form "where: what, with the error". For example, use "Housing officers' laptops: shared F: drive unreachable after sign-in, error 0x80070035." The requester's original phrasing stays in the body, where search still finds it. The subject becomes the one line that tells a stranger whether this is their ticket.

Most tools let the desk edit the subject. Some do not, and in those the first line of your first internal note does the same job, written in the same form. Either way the subject should contain the name of the thing, the symptom in plain words, and the error text or code if there is one. Keep that order, because that is the order in which a stranger scans a list. "Shared drive" first, so they know it is about drives; "unreachable after sign-in," so they know which drive fault; the code, so they can match it to their screen. Twenty words, chosen once, read a hundred times.

Where Findability Fails: The Common Holes

The same handful of holes make most tickets unfindable, and each has a fix that takes seconds at the time and hours afterwards. The table collects them. Run a month of your own closed tickets against it and you will find the two or three your desk falls into most. That is where to start.

The last two holes are the expensive ones, because they hide the pattern rather than the ticket. A desk can find any single ticket eventually by trying enough words. What it cannot do, when subjects are "Help!!" and nothing is linked, is notice that it has fixed the same fault seven times. Seven first occurrences never get a cause. A pattern does.

A Short War Story: The Board That Froze Six Times at Bellweather Logistics

The dispatch board at Bellweather Logistics was the wall screen in the dispatch office that showed every lorry and its load. It froze on six mornings over nine months, and six tickets were raised. Each was raised by a different dispatcher and each in different words: "board frozen," "dispatch screen stuck," "the big screen has hung," "lorry display not updating," "wall display dead," and "it's broken again." Each was fixed inside ten minutes by restarting the board's service, by four different technicians. None searched for the others because none knew there were others. And none wrote the application's name, the service's name or the time of the freeze into the ticket. Kofi, taking the seventh, searched for the service name and found nothing. So he wrote it into his ticket together with the dispatchers' six phrases, which he collected by asking around the office. He also wrote the time, which was 06:10. A week later a colleague with an eighth freeze searched for "frozen," and found Kofi's list. The two of them found all six earlier tickets in an hour by searching each phrase in turn. Laid side by side, every freeze fell between 06:00 and 06:20 on a morning after a heavy day. The cause was the nightly backup, which usually finished by five but ran past six after heavy days. It held the board's database while the board's service tried to reconnect and gave up. The fix was a single reconnect setting that took the application team an afternoon. Nine months of lorries waiting in the yard for an hour at a time had cost the dispatch office somewhere around a working week. And the cause had been findable from the second freeze onward, if the first ticket had been written for the stranger.

The Searchable-Note Checklist

The checklist below is the findability test for a ticket, to be run at first touch and again before closing. It is deliberately short, because a checklist that is long is a checklist that is skipped. Everything on it is a word or a line that costs seconds to add and hours to do without. Use the "also described as" line and the "Cause:" line as written. The fixed wording is what makes them searchable across the whole desk and not just in one technician's tickets.

SEARCHABLE-NOTE CHECKLIST — run at first touch and again before close

ERROR TEXT
  [ ] Exact error text and code in quotes, typed, not only a screenshot
  [ ] Where it appeared: dialog, title bar, application log, event log
  [ ] Each variant of the text recorded where it differed

NAMES
  [ ] Device by inventory name and by common name: "HSG-LT-112, Anna's laptop"
  [ ] Application by shortcut name, title-bar name and nickname, first time
  [ ] Account as the directory shows it
  [ ] Place as the organisation names it: floor, office, site

THE REQUESTER'S WORDS
  [ ] Requester's own phrase kept in quotes
  [ ] Line reading: Also described as: "____", "____", "____"
  [ ] Symptom words kept as said: slow, frozen, gone, missing, kicked out

LINKS
  [ ] Earlier tickets about the same fault found by searching the three above
  [ ] Line reading: Related: ____, ____  on this ticket
  [ ] Same line added to each earlier ticket, pointing here
  [ ] Duplicates of this occurrence merged; recurrences linked, not merged

CAUSE
  [ ] Line reading: Cause: ____________________________________
  [ ] Line reading: Ruled out: ________________________________
  [ ] Cause added to earlier linked tickets with this ticket's number
  [ ] Knowledge article written or updated if this has recurred;
      article title here, ticket numbers in the article

SUBJECT
  [ ] Rewritten as "where: what, with the error" once understood
  [ ] Contains the thing's name, the plain symptom, and the code

FINAL TEST
  [ ] Searching for the error code finds this ticket
  [ ] Searching for the requester's phrase finds this ticket
  [ ] Searching for the device or application name finds this ticket

Sam ran the checklist on his own ticket at the end of the Wednesday and on the four earlier ones the following morning. That took him forty minutes in total and felt, he said later, like paperwork. Three weeks after that a technician on the evening shift took a call from a housing officer whose F drive had gone. The technician typed "F drive" into the search and had the fix on screen before the officer had finished describing the problem. The evening technician did not know Sam had done anything. That is what writing for the stranger looks like when it works: the stranger never finds out that anyone was thinking of them.

Frequently Asked Questions