Translating the Vague Ticket Into One You Can Work

Thursday, 14:05, at Bluewater Bank. Ticket 7741 arrives from Marcus in the mortgage team: "Keeps crashing. Lost my work twice now. Need this fixed today please." Lena reads it and sees three tickets in one. There is a fault, which is "crashing". That word covers everything from a frozen window to a machine that restarts itself. There is a loss, "lost my work", which is why the message is short and the "please" is doing a lot of work. And there is a deadline, "today", with no reason given. At a bank on a Thursday afternoon, that usually means a completion tomorrow. Lena could reply "Hi Marcus, what is crashing?" and begin a chain of four e-mails that ends on Friday lunchtime. Instead she writes one reply that starts with what she thinks is happening, asks three things, and offers to call. Marcus phones her two minutes later. The ticket is workable by 14:20.

The difference between those two replies is not politeness or effort. It is that the second one translates before it asks. Lena reads "keeps crashing" and forms a guess: a program, not the machine. A machine that restarted would have been described as "turned itself off". She reads "lost my work twice" and hears fear. That means the first sentence of the reply has to be about the work, not the fault. She reads "today" and hears a deadline the requester has not named. That means the reply asks what it is rather than arguing about priority. Each guess might be wrong. Each one turns a vague sentence into a precise question.

Translating a ticket is the act of reading what the requester wrote and forming a working theory. The theory covers what they mean, what they have tried and what they are worried about. Then you ask only for what the theory cannot supply, in one reply, in their words. This article is part of our Getting Better Tickets From Users series. It is the requester-facing craft. The triager's discipline of counting the five facts and asking once for the missing ones is in Gathering the Right Information Up Front. This article assumes that discipline and builds on it.

It covers translation as interpretation before interrogation, then reading between the lines for what they tried and what they fear. Next come the user-facing question set in order and the single reply that translates and then asks. Then it covers the phone call that saves four e-mails and writing the translation into the ticket. It finishes with what to do when the translation is wrong, a short war story and the translation questions reply to copy.

Interpretation Before Interrogation

A list of questions is an interrogation. A guess followed by questions is a conversation, and requesters answer conversations. "What is crashing? Which program? Since when? What does it say?" is four questions that each require the requester to stop and think. They will answer the first one and leave the rest, because that is how people read e-mail. "I think the mortgage system is closing on you while you are mid-application; is that right, and does anything appear on screen just before it goes?" is one question with a theory attached. The requester can confirm it, correct it or add to it in a single sentence. The theory does the heavy lifting. The requester only has to say yes, no or nearly.

The theory comes from the tells, which Why Tickets Arrive Saying 'It's Broken' catalogues at length. "Crashing" usually means one application closing or freezing. "Keeps" means more than once and probably more than today. "Lost my work" means unsaved changes in whatever was open, which narrows "crashing" further. It is the thing Marcus types into, not a background process. Three words, and the field of possible faults has shrunk from everything to one program closing during data entry. That is not certainty. It is enough to ask a sharp question instead of a blunt one.

Being wrong is cheap when the theory is stated, and expensive when it is hidden. If Lena guesses the mortgage system and it is actually the spreadsheet Marcus keeps his rate notes in, he will say so in his first reply. In that case, nothing has been lost but one sentence. If she had instead asked the open question "what is crashing?", the answer would have been "the system". Then the second round would have begun. A stated guess invites a correction. An open question invites a vague answer. (Requesters are not being difficult when they answer vaguely; they are answering the question they were asked, which was a vague one.)

Reading Between the Lines: What They Tried

Assume the requester has already restarted, and ask what else they tried before you suggest anything. Nearly everyone restarts first, because it is the one piece of technical advice the whole world has absorbed. A reply whose first suggestion is "have you tried restarting?" tells the requester that the desk has not read their ticket. If the ticket does not say what was tried, ask, with the reason: "What have you already tried, so I don't suggest it again?" That sentence does three things. It gets the list. It signals respect. And it saves the desk from the reply that begins "Yes. Twice. Before I wrote in."

"I've tried everything" means two things, and neither is "everything". It means the requester has done the things they know. That is usually restart, close and reopen, and log out and in. It also means they have run out of ideas and are now frustrated. The reply acknowledges both: "Thanks for trying the usual things first; that rules a few causes out." Then it asks for the one thing they probably have not tried: to read the message on the screen aloud, or photograph it. The dismissed message is where the cause usually is. Nobody who has "tried everything" has tried reading the error. It is not on anyone's list.

Watch for the attempt that made things worse, which the requester will mention sideways or not at all. "I think I clicked something" and "I may have changed a setting" are confessions wearing casual clothes. The correct response is instant absolution: "Nothing you can click is a problem we can't put right." A requester who is afraid they caused the fault will under-report what they did. The under-report will cost the technician an hour. The way to get the whole story is to make it clear, early and warmly, that the story has no consequences.

Reading Between the Lines: What They Are Afraid Of

Most vague tickets carry a fear. The fear is why the ticket is short. So the first sentence of the reply addresses the fear and the questions come after. Marcus is afraid his work is gone. A reply that leads with "what is crashing?" leaves the fear sitting there while he answers. A frightened person answers badly. A reply that leads with "first, about the lost work: most of what the mortgage system takes in is saved as you go, so I expect we can recover more than it looks like, and I will check that first" gives him something to hold. The three questions underneath get full answers because he is no longer bracing.

The fears repeat, and so do the sentences that answer them. The table below lists the ones a desk meets most and how each one shows up in a ticket. It also lists the first sentence that answers each fear before any question is asked. None of these sentences promises an outcome. They promise attention to the thing the requester cares about. That is a promise the desk can always keep. The reassurance is not a soft skill bolted onto the technical work. It is how you get the facts.

Read the ticket twice before replying: once for the fault, once for the fear. The second reading takes ten seconds and changes the whole shape of the reply. A desk that only reads for the fault gets accurate answers slowly. A desk that reads for both gets them fast, and gets a requester who remembers the desk as the people who noticed. That memory is what makes the next ticket arrive by the form, with a photo, and a deadline written down.

The User-Facing Question Set, in Order

Ask in a fixed order, because the first question gets the best answer and the fifth gets the shortest. The order is the one question that splits your theory, then where or which, then since when. After that come who else and the deadline, then what was tried. The splitting question comes first because it is the one you most need and the one they can most easily answer with a yes or no. For Marcus: "Is it the mortgage system that is closing, and does anything appear on screen just before it does?" If yes, the theory stands and the rest of the questions refine it. If no, you have learned the most important thing in one line.

Where-or-which comes second because it is the question requesters can answer from their chair without thinking. Ask: "Is this on your own desk machine, or the laptop?" Since-when comes third, with the prompt that makes it answerable. Ask: "When did it last behave, and did anything change around then, such as an update, a new password, or moving desks?" The how-bad pair comes fourth, with the reason: "Is anyone near you seeing the same, and what is the deadline you mentioned? That tells me how to place it." What-was-tried comes last, because by then the requester is in a rhythm of answering and will list it rather than defend it.

Five is the ceiling, and three is better. Every question past three costs an answer to one of the earlier ones. If the ticket already supplies a fact, do not ask for it, even if the template has the question in it. A requester asked for something they already told you concludes the desk did not read the ticket. They are right. Delete the answered questions and keep the numbering clean. The reply reads as if it was written for them, because it was. Keep the technical words out: "the program that closes", not "the application that terminates"; "the message on the screen", not "the error dialog". The reply is written for the requester's vocabulary. The translation into the desk's vocabulary happens in the note, afterwards.

The Single Reply That Translates, Then Asks

The reply has five parts, always in the same order, and fits on one screen without scrolling. The parts are the fear answered, the theory stated and the questions numbered. Then come the offer of a call and what happens next with a time. The fear comes first for the reason above. The theory comes second so the requester knows the desk has read the ticket and has an idea. "I think what is happening is..." is the most reassuring phrase a desk can send. The questions come third, numbered, with the reason for each in brackets, so the requester can see what the answer is for. The offer of a call comes fourth, with a number, because some requesters will take it and those are the ones whose tickets need it. And the last line says when they will next hear from you, whether or not they reply. The one thing worse than a vague ticket is a vague wait.

Send one reply, not three. The temptation, when a ticket is vague, is to ask the first question that comes to mind and see what comes back. Every desk has done it. It feels responsive. It produces the chain Lena avoided: question, wait, partial answer, question, wait. The result is a ticket that is two days old before anyone knows what it is about. The one reply takes four minutes to write instead of one, and saves two days. If your tool holds predefined replies, keep the skeleton as one. Fill the theory, the fear sentence and the questions by hand every time. A translation reply that is visibly a template has stopped translating. How to keep a template from sounding like one is the subject of Writing a Template That Does Not Sound Canned.

Keep the theory in the ticket as well as in the reply, but not in the same place. The requester sees the reply. The desk needs the working theory, the technical version of it, and what the reply was fishing for. If you run QuerySolv, the natural split is a public reply to the requester and an internal note beside it that the requester never sees. Most tools have the same two kinds of entry under some name. The public reply says "I think the mortgage system is closing on you". The internal note says "suspect session timeout on the application server after the patch on Tuesday; asked for on-screen message and timing; if confirmed, check with the two other mortgage users". The next person to open the ticket reads the note and knows exactly where the translation had got to.

The Phone Call That Saves Four E-mails

Some tickets are a phone call, and the skill is recognising them before the first e-mail rather than after the fourth. The signs are reliable. A ticket that carries a fear and a deadline together, like Marcus's, is a call. Reassurance lands faster by voice and the deadline will not wait for an e-mail cycle. A ticket from a shared mailbox is a call. The first question is "who is this?". That question by e-mail goes to fifteen people. A ticket whose vagueness no single question can split is a call. Examples are "nothing works", "everything is slow", "the system is weird". The requester will show you in thirty seconds what would take six exchanges to describe. And any ticket where the requester has written "can you ring me?" is, remarkably often, a call.

The call takes two minutes and has a shape. Say who you are and which ticket. Say what you think is happening, and ask them to show you or tell you. Close by saying what you will do and when they will hear from you. Do not try to fix it on the call unless the fix is one sentence. The call is for translation, and the fix follows. Two minutes on the phone recovers all five facts. The tone of voice tells you how bad it really is. The requester hangs up knowing a named person has their problem. The call is the most efficient tool the desk owns and the one it reaches for last, because e-mail feels safer. It is not safer. It is slower in a way that looks like work.

Write the call up in the ticket before you do anything else, in a note, in full. "Called Marcus 14:08. The mortgage system closes to the desktop about every twenty minutes with no message, started Tuesday afternoon, desk machine only, two colleagues on the same floor seeing it, completion tomorrow 10:00. He has restarted twice and reinstalled nothing. Saved data intact per the system log; told him so." A call that is not written down is a translation that lives in one head. The next technician will phone Marcus to ask the same questions. That is worse than never having called. Where phone fits in a ticket-based desk, and how to stop calls bypassing the queue, is in Phone Support in a Ticket World.

Writing the Translation Into the Ticket

When the answers come back, by reply or by phone, rewrite the ticket so that the next reader sees the translated version first, not the original. Change the subject line from "Keeps crashing" to something a technician can act on: "Mortgage system closes every ~20 min, three users, 3rd floor, since Tuesday PM, completion Fri 10:00". Add a note that restates the five facts in the desk's words. Leave the original message exactly as it was underneath, because it is the record of what was asked. The requester's own words are sometimes the clue you missed. The ticket now reads, from the top, like a ticket that arrived well formed. That is the point of translation: not to complain about how it arrived, but to leave it in a state the next person can work.

The restating note is the bridge between the requester's vocabulary and the desk's, and it is where the technical words finally belong. "The claims thing" becomes the system's real name. "Kicks me out" becomes "session ends without an error dialog". "The printer by the lift" becomes its label. A desk that keeps a short internal list of what each department calls each system writes this note in seconds. That is the list the first article in this series recommends. The habit of leaving a working note at every step, so that the ticket can be picked up cold, has its own treatment in The Working Note Habit. The translation note is the first one on the ticket and the one most often skipped.

When the Translation Is Wrong

The theory will be wrong about one time in four. The correct response is to say so plainly and move on. The requester correcting the desk is the system working. "Ah, so it is the spreadsheet, not the mortgage system; that changes things, thank you." No defence of the guess, no "well, you did say crashing", no sigh. The requester has just handed over the single most useful fact on the ticket, and the only sensible reaction is gratitude. A desk that gets defensive about its guesses trains requesters to stop correcting them. A requester who stops correcting is a requester whose tickets get worked on the wrong theory to the end.

A wrong theory is still faster than no theory. The requester who corrects "I think it is the mortgage system" with "no, the spreadsheet" has given a precise answer to a precise question. The requester asked "what is crashing?" would have said "the system" and meant the spreadsheet. The desk would have spent an afternoon on the wrong one. State the guess, hold it loosely, and let the requester knock it down. I have been wrong about what "the system" meant more times than I can count. Every time the correction arrived in the first reply because the guess gave it something to push against.

A Short War Story: The "It Keeps Crashing" Ticket at Tollgate Foods

At Tollgate Foods, a ticket arrived at the desk from Ines in purchasing that read "it keeps crashing, can someone look". Dev, who was new, replied within ten minutes with "Hi Ines, what keeps crashing?" The answer came back the next morning ("the ordering screen"). Dev asked which ordering screen. The following afternoon Ines said "the supplier one". Dev asked what happened when it crashed. On day three Ines replied "it just goes". Dev asked whether anything appeared on screen first. On day four Ines sent a photo of a message about an expired certificate that the supplier's portal had been showing all week. Four days, five exchanges, and a two-minute fix that consisted of telling the supplier their certificate had lapsed. During that time, purchasing had been placing orders by phone. They had missed a discount window worth a week of the desk's salary. Dev's lead, Sofia, sat with him and rewrote the first reply as it should have been. It started with a guess that it was the supplier portal. "Ordering" at Tollgate meant one of two screens and only the portal was known to "just go". The reply asked for a photo of whatever appeared before it closed and offered to call. She then had him phone Ines about the next vague ticket, which took ninety seconds. Dev wrote the lesson on a sticky note that stayed on his monitor for a year: guess first, then ask. If it is a call, call.

The Translation Questions Reply

The reply below is the skeleton. The parts in square brackets are instructions to you and are deleted before sending. The blanks are filled by hand every time. The fear sentence, the theory and the chosen questions are what make it a translation rather than a form. Delete any numbered question the ticket already answers. Never send more than five questions, and prefer three. Keep the closing line, with a real time in it, on every reply, including the ones where you expect the requester to phone instead.

TRANSLATION REPLY — FILL EVERY BLANK BY HAND, DELETE THE BRACKETS

Subject: Ref ______ — what I think is happening, and three quick questions

Hi ______,

[THE FEAR, FIRST. One sentence about the thing they are worried about.]
First, about ______________: ______________________________________
____________________________________________. I will look at that
before anything else.

[THE THEORY. One or two sentences, in their words, no technical terms.]
From what you have written, I think what is happening is that
____________________________________________________________________.
If that is wrong, just say so; it helps me more than you would think.

[THE QUESTIONS. At most five. Delete any the ticket already answers.]
To get this moving, could you tell me:

  1. ______________________________________________________________?
     [the one question that confirms or kills the theory]
  2. Is this on ______________ or ______________, and where are you
     sitting?  [so I come to, or connect to, the right one first time]
  3. When did it last behave normally, and did anything change around
     then, such as an update, a new password or a desk move?
     [most faults start with a change, and the time finds it]
  4. Is anyone near you seeing the same, and what is the deadline you
     mentioned?  [this tells me how to place it against other work]
  5. What have you already tried, so that I do not suggest it again?

[THE CALL. Always offer it; some will take it, and those tickets need it.]
If it is quicker to show me, call me on ______ any time before ______
and we can do this in two minutes.

[WHAT HAPPENS NEXT. A real time, whether or not they reply.]
Either way, I will update you by ______ today with where we are.

Thanks,
______
______ desk, ref ______

---------------------------------------------------------------------
INTERNAL NOTE (not visible to the requester; write it at the same time)
Working theory: ______________________________________________________
Asked for: ___________________________________________________________
If confirmed, next step: _____________________________________________
If wrong, alternatives: ______________________________________________

Lena's reply to Marcus used three of the five questions and the call line, and it was the call line he took. Her internal note read: "Suspect app session timeout after Tuesday's patch; asked for on-screen message, machine, others affected; if confirmed, check the two other mortgage users and the server log." When Marcus phoned, she had the theory in front of her. She confirmed it in ninety seconds and found two more affected users he had not thought to mention. She rewrote the subject line before she hung up. The fix took the afternoon. The translation took fifteen minutes. That is roughly the time it would have taken to write the first of four e-mails and wait for the second.

Frequently Asked Questions