What Never to Write in a Ticket, and Where It Goes Instead

Friday, 16:40, at Greywell Council. Dana, who runs the desk, gets a message from HR. The request is to export every ticket raised by Rob in the planning department over the last two years, for a grievance. It is a routine request. Dana opens the export to check it before sending and starts reading her own team's internal notes. "Rob again. Third time this month, he just doesn't listen." "Temp pw Welcome2go! Tell him to change it (he won't)." "Pretty sure the planning system is just broken, told him it's the vendor." The export is going to HR, to a union representative, and to Rob. Dana reads a hundred and forty tickets before lunch on Monday and finds eleven she would not want read aloud in a room with Rob in it. Rob is going to be in the room.

A ticket is a record. It is kept for years, backed up, exported, forwarded, and migrated to the next tool. Now and then, it is requested by the person it is about. This article is about the small set of things that must never be written into that record, whoever can see it today. It is about where each of them goes instead. Every one of them is a real thing the technician needed to do something with. This article is part of our Writing Ticket Notes That Survive You series, which is mostly about writing more. This is the article about writing less.

It covers why every note is a document someone else may read, then passwords, keys and secrets. Next come remarks about the requester, speculation stated as fact, blame, and jokes at anyone's expense. It covers personal details that are not secrets but still do not belong. Then comes the note the requester may one day read, as a single test. A short war story follows, then the do-not-write list with the replacement for each line.

Every Note Is a Document Someone Else May Read

Internal notes leave the desk in more ways than most technicians have counted. The requester can ask to see them. In many places a person has a legal right to see records held about them. In most organisations HR, legal or an auditor can ask to see them regardless. A grievance, a dispute, a disciplinary case or an insurance claim brings the tickets out as evidence. A security review reads them for passwords. A colleague forwards the ticket to another team with the notes attached, or replies to the requester from the wrong box. That happens on every desk about once a quarter. And the day the organisation moves to a new tool, every note is exported, and whoever does the import reads a sample.

The internal note is therefore not private, and it was never designed to be. It is private from the requester on an ordinary day, which is useful for hostnames, drafts and coordination between technicians, and that is all. Which notes the requester sees and which they do not, and what belongs in each, is set out in the working note habit. The rule in this article sits on top of that one: the internal note is a quieter room, not a locked one.

The test that covers everything below is a single question. Would I say this to the requester's face, with their manager in the room, and be comfortable? If yes, write it. If no, the thing you wanted to write is one of seven kinds, and each kind has a place it belongs that is not the ticket. The rest of this article is those seven and their places.

Passwords, Keys and Secrets

Never write a password into a ticket. Not a temporary one, not one the user "will change anyway," not one in a screenshot, not one the requester typed in themselves. A ticket is readable by everyone on the desk, by whoever has the export, by whoever restores the backup, and by search, forever. "Temp pw Welcome2go!" is findable by typing "pw" into the search box, and the person typing it may not be on your side. The same applies to licence keys, API keys, wireless keys, door codes, recovery codes, and the answers to security questions. Those answers are passwords wearing a hat.

Where it goes instead: the secret lives in the password manager or vault the desk already uses. The ticket records that it exists and where. The temporary password is told to the requester by phone, or by a channel that reaches only them. The note says "temporary password set at 10:12, given by phone, must be changed at first sign-in." That line answers every question an auditor will ask and gives away nothing. If the desk has no vault, that is the first ticket to raise with yourself. A desk without a vault keeps its secrets in tickets, chat messages and sticky notes. That is three vaults with no door.

Requesters will write passwords into tickets themselves, because they are trying to be helpful and nobody told them not to. "My password is Summer99 if you need to log in as me." When it happens, treat the password as exposed. Change it, tell the requester why, and remove the text from the ticket if your tool allows editing. If it does not, the ticket keeps the old password. In that case, the note beside it says the password was changed at 11:05 because it had been written in a ticket. That turns the exposed secret into a dead one. I have done this perhaps forty times. The requesters are always apologetic and the tickets are always, thereafter, read by someone.

Remarks About the Requester

Never write what you think of the requester. "Clueless." "Difficult." "Doesn't listen." "Again!!" "Typical sales." Each is an opinion about a person in a record about a computer, and each does three kinds of damage. It punches down at someone who came to the desk for help. It sets the next technician's attitude before they have read the problem, so Rob's fourth ticket is opened with a sigh instead of a question. And it is the first line a grievance panel reads. It is the only line in the pack that is about a person rather than a fault. It decides what the panel thinks of the desk before any fact has been considered.

Where it goes instead: the fact replaces the adjective, every time. "Third ticket on this subject in four weeks; see 5112 and 5190" says everything "again!!" was trying to say, with evidence instead of exasperation. It is a line the desk can act on. The pattern itself, that one requester keeps raising the same thing, goes to the desk lead as a conversation. From there it goes either to a training note for the requester or to the problem list. A requester who raises the same ticket four times usually has a fault that keeps coming back. What angry or repeated tickets tell the desk about itself is the subject of what angry tickets teach the desk. The point here is that the lesson goes in a conversation and the facts go in the ticket, and the adjective goes nowhere.

Genuinely bad behaviour is the one case where the requester's conduct belongs in the record, and it belongs there as fact. If a requester shouts, swears or threatens, write what was said, in quotes, with the time, who witnessed it, and what you did. "At 14:20 the requester said '...' and hung up; I informed Dana; the ticket remains open." No characterisation, no "abusive," no "as usual." Facts stated plainly are what protect the technician if the matter goes further, and adjectives are what undermine them. The record is strongest when it sounds like a camera.

Speculation Stated as Fact

Never write a guess in the grammar of a finding. "The server is faulty." "It's a bug in the vendor's software." "The network is dropping packets." Each may be true. Written flat, each is read by the next technician as something established. If it reaches the requester, they read it as the desk's verdict. The guess gets acted on. The server is rebuilt. The vendor is blamed in a meeting. The network team spends a day proving a negative. And the real cause, which was a full disk, sits unexamined because the ticket had already named a culprit. A guess written as a fact is the most expensive sentence on the desk, because it is believed.

Where it goes instead: in the ticket, labelled. Speculation is welcome in the note and is often the most useful part of it, provided it wears a sign. "Suspect the licence service is not releasing licences on disconnect; not confirmed." "Ruled out the server: reachable from a wired desktop at the same time." "Confirmed by the event log at 10:41." The four words that do the work are suspect, not confirmed, ruled out, and confirmed by. And a note that uses them can hold any theory the technician likes without misleading anyone. The habit of marking theories as theories is also what keeps a later cause investigation honest, which is why root cause analysis without a committee depends on it.

The same rule applies to the word "fixed." Written when you mean "it stopped happening while I was watching," it is a guess stated as a fact. It is the guess behind most reopened tickets. "Restarted the service at 11:20; working at 11:25; cause not yet known; will watch until tomorrow" is honest and is still good news for the requester. "Fixed" is a promise the ticket may not be able to keep.

Blame

Never write who is at fault. "Marcus broke it." "The network team's fault again." "Vendor incompetence." Blame turns a record into an accusation, and accusations have consequences the technician did not intend. The blamed person reads it. The blamed team stops cooperating. The next technician who makes a mistake writes a vaguer note so that no sentence can be pointed at them. A desk whose tickets carry blame ends up with tickets that carry nothing, because nobody writes an honest account of a mistake into a record that is used as a weapon. Blame is how a desk teaches itself to stop writing.

Where it goes instead: the event replaces the verdict. "Change made Tuesday at 14:00 by the network team under change record 88; symptom began 14:05; change reverted 14:50; raised with the network team as ticket 6610." Every fact that the blaming sentence was built on is present, in order, with times, and nothing in it is an opinion. If a person's error needs addressing, that is a conversation between that person and their manager, held in a room. The ticket is the evidence that conversation uses, not the place it happens. Writing the event and not the verdict also costs nothing when the technician was the person who made the mistake. That is the case more often than any of us writes down.

Jokes at Anyone's Expense

Never write a joke about a person into a ticket. "User tried turning it on, breakthrough." "Finance has discovered the spreadsheet." "Rob's weekly visit." They are funny in the kitchen. They are ordinary in the team chat. They are something else entirely when read aloud by a union representative in a grievance hearing fourteen months later. By then the joke has no context, no tone of voice and no friend in the room. The ticket does not know it was a joke. The record is permanent and literal, and it does not do irony.

Where it goes instead: nowhere written. The joke goes in the kitchen, said out loud, where it evaporates like the fix. The team chat is not the safe alternative it feels like, because chat logs are also records, also exported, also requested. The difference between a joke in a ticket and a joke in the chat is only how long it takes to find. This library makes jokes about queues, dashboards and the eleven-page policy, and none about the people who raise tickets. The same line holds on the desk. The systems can be laughed at in conversation. In the record, nothing is laughed at.

Things That Are Not Secrets but Still Do Not Belong

Never write personal detail the ticket does not need. The medical reason a requester is off work, mentioned while asking for remote access. The salary figure glimpsed in the payroll spreadsheet that would not open. Other examples are the reason someone is leaving and the family situation overheard on the call. There is the disciplinary case that explains why an account must be disabled by Friday. There are the contents of the e-mail you were asked to recover. None of these is a password, and none belongs in a ticket. The ticket is read by everyone on the desk and kept for years. The only question the ticket needs answered is what to do.

Where it goes instead: the fact the desk needs, stripped of the fact it does not. "User is off sick with a back injury and needs remote access" becomes "user is working from home for the next month. They need remote access. Their manager approved it on the 4th." "Disable Jo's account, she's being let go for the expenses thing" becomes "disable the account at 17:00 Friday on HR's instruction; HR reference 2231." The reason lives with HR. The medical note lives with the requester's manager. The ticket holds the action and who authorised it. If the organisation has rules about personal data, this is where they bite. The plain version of those rules is: write only what the ticket needs to be worked and to be understood later.

Screenshots carry personal data too, and nobody checks them. A screenshot of the payroll spreadsheet that would not open contains the payroll. A screenshot of the requester's inbox contains the inbox. Crop to the error, or blur what is not the error, or describe it in words. When a requester attaches something they should not have, say so kindly and remove it where the tool allows. The fault is the desk's to work; the data in the screenshot is somebody else's to keep.

The Note the Requester May One Day Read

All seven kinds reduce to one habit: write every internal note as though the requester will one day read it. The internal note is still part of the ticket, and the ticket goes wherever records go. The separation between internal notes and public replies is a convenience for working, not a privacy curtain. QuerySolv keeps them on the same ticket, as most tools do. An export or a records request brings both halves along. Written for a reader who might be the requester, a note loses nothing it needed. Facts, times, hostnames, settings, labelled suspicions, and next steps are all things you would happily say to the requester with their manager in the room. What drops out is only what should never have been there.

The reverse test is to read the note aloud, in a flat voice, to an imaginary panel. Most technicians can hear the problem sentence before they reach the end of it. Dana, on the Monday, read eleven such sentences aloud to the desk, without saying who wrote them, and then asked each person to rewrite one. The rewrites took about a minute each and said the same things. The originals had taken about the same minute and said one thing more, and the one thing more was the whole problem.

The practical payoff arrives on the day the records request lands. A desk whose notes pass the panel test sends the export within the hour and thinks no more about it. A desk whose notes do not spends a weekend reading two years of tickets and flags the ones that will hurt. It discovers that it cannot remove them, because the record is the record. The time to make a note safe to read is when it is written. Afterwards there is only reading it, slowly, with HR.

A Short War Story: The Grievance Pack at Bluewater Bank

Hana, a branch manager at Bluewater Bank, raised a formal grievance after a year of friction with the desk over a request it had repeatedly declined. HR asked for every ticket she had raised, which came to twenty-three. Twenty-two were unremarkable. The twenty-third carried an internal note from a technician called Dario that read "she's at it again, just tell her no." It was written on a Friday afternoon about a request that was, in fact, outside policy and had been properly declined each time. The grievance panel found for the desk on every substantive point and against it on tone, on the strength of that one line. The consequences were a formal apology from the desk lead and a note on Dario's record. The bank's compliance team required a manager to sample every desk's internal notes each quarter for the next two years. That cost the lead a day a quarter. It cost the desk the thing it had taken a year to earn: being left alone. The request had been declined correctly and the note had been true. It had also been written for the back room, and there is no back room.

The Do-Not-Write List and the Replacements

The table below is the seven kinds as a list. Beside each is the reason, the line to write instead, and the place the real thing goes. Print it, pin it where the desk writes, and use the replacement lines as written. The fixed phrasings, "suspect," "not confirmed," "ruled out," "confirmed by," "given by phone," are what make the notes consistent across the whole team. Every replacement in the right-hand columns carries all the information the forbidden line did. None of them would embarrass anyone read aloud. That is the entire standard, and it fits on one page.

Dana sent the export to HR on the Tuesday with the eleven notes in it. They were the record, and the record is not edited after the fact. She sent with it a short covering note saying that the desk had reviewed its own notes and changed its standard. The grievance went the way grievances go. The desk's notes have not needed a weekend's reading since. When the next records request arrived, a year later, it went out within the hour. Nobody read it aloud. There was nothing in it to hear.

Frequently Asked Questions