Why Tickets Arrive Saying 'It's Broken', and Why That Is Fair

Monday, 08:14, at Bellweather Logistics. Ticket 5817 lands in the queue from shopfloor@example.com. The subject is "Printer broken". The body, in full, is "Broken again, can you come?" Tomas, who is on the desk alone until nine, reads it twice looking for a clue and finds none. The site has six printers. The shop floor address is shared by about forty people. "Again" refers to something Tomas has never heard of, and "come" implies a walk of some length through a warehouse that is just starting its day. He does what every technician does with a ticket like this. He picks up the phone, gets no answer, and sends an e-mail asking which printer. Work on the actual fault begins at 09:40, by which time dispatch has been printing nothing for ninety minutes and a lorry is waiting.

Here is the uncomfortable part. Nothing about that ticket was unreasonable from where it was written. Priya in dispatch has one printer that matters to her. It has jammed before, and somebody from IT came and fixed it. The quickest way to make that happen again was to send the words she sent. She has no idea the site has six printers on IT's list, because she has only ever used one. She does not know that "again" means nothing to a technician who was not there last time. She does know that dispatch notes are not printing and that a lorry is waiting. She told you the printer was broken, which from her chair is the entire fact.

A vague ticket is one that reports that something is wrong without carrying the facts a technician needs to begin. Those facts are who exactly is affected, what they see, which device or system, since when, and how bad. This article is about why those facts go missing, and why it is not the requester's failing. It also covers why the job of recovering them belongs to the desk rather than to the user. It is the first in our Getting Better Tickets From Users series. The series goes on to cover the form, the required fields, the translation reply, training users kindly, and measuring ticket quality so that you fix the form rather than the person.

It covers the view from the requester's chair, and what they know that you do not and what they cannot know. Next it covers why "it's broken" is a complete sentence to them, why the form gets skipped, and why the translation job belongs to the desk. Then come the tells inside vague words and what they usually mean, and how to ask without making it an interrogation. It ends with a short war story and the translation table to copy, in that order.

The View From the Requester's Chair

The requester is not trying to describe a fault; they are trying to get back to work. That is the first thing to hold onto, because nearly every bad ticket makes sense once you accept it. Priya is not a witness giving a statement. She is a dispatcher with a lorry on the bay, and the ticket is a lever she pulls to make the printing come back. She wrote the shortest thing that had worked before. A technician reads the ticket as a description and finds it empty. The requester wrote it as a request and considers it complete.

From the requester's chair, the thing has one name, and it is "the printer". They do not see six printers; they see theirs. They do not see a system called by its product name; they see "the invoices thing" or "the screen where I book holidays". The names IT uses are the names on the licence, the server, or the asset label. The names users have are the names of what the thing does for them. Neither set is wrong. They are two maps of the same building, and a ticket is written on one and read on the other.

The requester also has no sense of what the desk can see. Many users assume the desk can tell which computer they are on, which printer they mean, and what the error said. To them the desk is "IT" and IT knows about computers. If you have ever been asked "can't you just see it from your end?", that is the belief talking. The desk, from its end, sees a queue and a sender address. The requester imagines a wall of screens. Somebody, at some point, showed them a film.

What They Know That You Do Not

The requester holds almost all of the facts and does not know which ones you need. That is the shape of the problem, and it is worth separating the two halves. Priya knows which printer, where it sits, and what the screen on the front says. She knows that it started after Kofi changed the toner at ten past eight. She knows that six people in dispatch share it and that the lorry leaves at nine. All five facts a technician needs are in her head. None of them made it into the ticket, because nobody ever told her they mattered and the form did not ask.

The desk, meanwhile, holds facts the requester has no access to and does not need. You know the printer's name on the network, its model, and that it had a firmware update last week. You know that two other tickets about tray two came in last month, and what the jam message usually means. This is why the handoff feels asymmetric from both sides. The requester feels they have said everything, since from their chair "the printer is broken again" names the only printer and the only fault they know. The technician feels they have been told nothing, since none of the facts they can act on arrived. Both are right.

Read the right-hand column again, because it is the whole argument of this series. Every missing fact is missing for a reason that has nothing to do with intelligence or effort. The requester did not know the fact mattered, did not know the desk could not see it, or was not asked. All three are fixable by the desk. None is fixable by telling the requester to try harder.

Why "It's Broken" Is a Complete Sentence to Them

"It's broken" carries exactly as much information as the requester believes is needed, which is why no amount of frustration changes it. Consider how a non-technical person experiences a fault. They were doing a task. The task stopped. A box may have appeared, with words in it that they did not write and cannot act on, so they closed it. From that experience, the honest report is "it stopped working". The words in the box are, to them, the computer talking to itself. (It is, to be fair, often doing exactly that.)

The vocabulary that would make the ticket precise is vocabulary the requester does not own. "Error message", "application", "server", "network drive", "authentication" are desk words. A requester who cannot tell whether the thing that failed was a program, a website or a shared folder is not being lazy. Those are distinctions that exist for people who maintain them. Asking a user to write "the mapped drive is not reconnecting at logon" is asking them to speak a second language they have never been taught. It is then grading the ticket on grammar.

There is also a social reason the sentence stays short. Writing a long, careful description of a fault feels like making a fuss. Most people have a strong instinct against making a fuss, particularly to a department they imagine is busy with more important things. "Broken again, can you come?" is apologetic in its brevity. It is a knock on the door, not a report. The requester has been polite, and the desk reads the politeness as missing data.

Finally, past experience teaches the requester what works. If, last time, "printer broken" produced a technician within the hour, then "printer broken" is the proven method and anything longer is wasted typing. If, last time, a carefully written ticket with a screenshot sat for three days, the requester has learned that detail is not rewarded. Users write the tickets the desk has trained them to write. Mostly by accident, and mostly without noticing.

Why the Form Gets Skipped

The web form asks the right questions, and the requester went round it. The reason is nearly always that the form was the harder route. Priya had a mailbox open. The shop floor address has e-mailed IT since the company had six people. It still works, in the sense that a ticket gets created. The form is a bookmark she does not have, behind a login she has forgotten. It has eleven fields, two of which are drop-down lists of things she does not recognise. The e-mail took eight seconds. The desk designed the good route and left the easy route open beside it, then wondered why people took the easy one.

The form also fails when its questions are the desk's questions in the desk's words. A field labelled "Affected CI" or "Service" or even "Category" asks the requester to classify the fault in a taxonomy they have never seen. A required drop-down whose options are system names they do not use gets the first option, or "Other", or an abandoned form and an e-mail instead. Every field that asks for a desk word rather than a user fact is a small door closing. A form with enough small doors closed is a form people walk around. Designing one they will finish is the subject of A Request Form People Will Finish. The e-mail route that bypasses it gets its own treatment in Required Fields Without the Revolt.

Then there is the moment itself. A fault interrupts. The requester is mid-task, possibly with someone waiting, possibly with a lorry on the bay. The ticket is written in the thirty seconds between the thing failing and the next thing demanding attention. Nobody composes well in those thirty seconds. The form, with its careful fields, is designed for a calm person at a desk with time to think. That person does not raise tickets. The person who raises tickets is standing up, slightly cross, holding a phone in one hand and a jammed sheet of paper in the other.

The Translation Problem Belongs to the Desk

Somebody has to turn "it's broken" into a fault that can be worked. That somebody should be the desk, for the plain reason that the desk is the party that knows what a workable fault looks like. The requester does not know which five facts matter. The desk does. Expecting the person without the knowledge to do the translating is expecting the wrong party to do the work. That is why desks that spend years asking users to "write better tickets" get the same tickets they always got. You cannot train four hundred people one at a time. You can change the questions you ask them, and the form, and the first reply, and those train everybody at once.

Calling it translation rather than information gathering changes how it feels to do it. Information gathering sounds like a form the requester failed to fill in. Translation is a skill the desk has, the way a good pharmacist translates "the little white ones" into a drug name without sighing. The desk reads "the internet is down" and hears "one website I need is not loading". It reads "it's slow" and hears "one application takes longer than it did last week". It reads "it deleted my file" and hears "my file is saved somewhere I did not expect". Each of those translations is a hypothesis, and a hypothesis is what turns one vague sentence into one precise question.

Owning the translation also moves the blame off the ticket and onto the system, where it can be fixed. If a ticket arrives with two of the five facts, the interesting question is not "why did the requester leave three out?" In that case, it is "which of our doors let a ticket through with three facts missing, and what would it take to catch them?" Whichever door the request came through, web form, e-mail, chat or a social message, a tool like QuerySolv turns it into the same kind of ticket in the same queue. So the translation lands on the same desk every time. The only thing that changes by door is how much of the translation the door did for you. An e-mail does none of it. A good form does most. The desk does the rest.

Reading the Tells: What Vague Words Usually Mean

Vague tickets are vague in regular ways, and after a few hundred of them the regularities become a dictionary. "The internet is down" almost never means the internet is down. It means the one site or one program the requester needs is not responding. Occasionally it means the whole connection has gone. You can tell that because three more tickets arrive within a minute. "It's slow" means one specific action takes longer than the requester has learned to expect. They can usually tell you which action if asked, though they will say "everything" first. "I can't log in" is four different faults wearing one coat. They are wrong password, locked account, the wrong login page, or a successful login followed by a failure. The requester experienced that last failure as part of logging in.

Some tells point at the requester's fear rather than the fault. "It deleted my file" is usually a file saved in an unexpected place or overwritten. But the requester is frightened. The first job of the reply is to say that files are rarely gone and you will help look. "I think I clicked something" is a confession. A requester who has made one deserves to be told immediately that nothing they could click is their fault to fix. "Is this a virus?" means something unexpected appeared on screen. A desk that reads the fear and answers it first gets the facts faster, because a reassured person remembers more than a worried one.

Other tells point at history. "It's doing it again" is a gift, because the requester is telling you that a previous ticket exists and that the symptom is identical. The previous ticket has most of the facts in it already. "The usual problem" is the same gift with less wrapping. "Since the update" and "since I got the new laptop" are the since-when fact arriving under its own power. A desk that misses them because they were in the body rather than a field has only itself to blame. The picture below shows the whole translation on one ticket. The Bellweather printer is shown as it arrived on the left and as Tomas could finally work it on the right. The single question that recovered each fact runs across the middle.

Notice what the right-hand card does not contain. There is no model number, no network name, no firmware version, no phrase the requester would not have used. Every fact on the right is something Priya knew at 08:14 and could have typed in one minute, had anyone asked her the five questions in the middle. The translation did not add knowledge to the ticket. It moved knowledge that already existed from one head into one record. That is all it ever does, and it is still the most valuable minute on the ticket.

How to Ask Without Making It an Interrogation

The reply that recovers the facts asks for all of them at once, in the requester's words, with a reason attached to each. Writing that reply is a specific craft that two other articles own. The triager's discipline of asking once, with the full numbered reply and the five facts behind it, is laid out in Gathering the Right Information Up Front. The user-facing version, which opens by telling the requester what you think they mean and asks only for what is left, is in Translating the Vague Ticket Into One You Can Work. What belongs here is the posture, because the posture is what the requester remembers.

Ask as a colleague who wants to help, not as a clerk who has found the form incomplete. "Which printer is it?" and "Could you tell me which printer, so I come to the right one first time?" ask for the same fact. Only the second explains why it is worth the requester's thirty seconds. Every question with a reason attached gets answered more fully and more quickly, because the requester can see what the answer is for. A question without a reason reads as a hoop, and people step over hoops.

Never return a ticket with "insufficient information" or anything that means it. The requester did not withhold information; they did not know it was wanted. A ticket bounced back with a status that says "needs more info" and nothing else teaches the requester that the desk is a form-checking department. The lesson they take from it is to phone a technician directly next time. The phone call, as it happens, is sometimes the right move for the desk too. Two minutes on the phone recovers all five facts. The recovered facts go into the ticket as a note. That way, the next person to read it does not have to make the same call.

One more thing about asking: if the ticket gives you enough to start, start. A vague ticket that says "SF-02 jammed again" has a where and a what. Go and look, or check the printer's status remotely, and ask the rest when you get there. Translation is not a gate the ticket must pass through before any work begins. It is a habit of making sure the facts are in the record before the ticket moves on. It can happen in parallel with the fix. A desk that refuses to touch a ticket until the form is complete is running a very tidy queue of people who have stopped using it.

A Short War Story: The Mystery Slowness at Redbrook Engineering

At Redbrook Engineering, a design office of about ninety people, the desk received a ticket from Hannah in drafting. It read "computer very slow, has been for ages, please sort". Leon, the technician, replied asking what was slow and got "everything" the next day. He asked since when and got "weeks" two days after that. He asked whether it happened at particular times and the reply, four days later, was "mostly mornings I think". By the second week he had reimaged the machine, which took Hannah's whole Thursday. The slowness returned on the Friday. Only when he finally walked over and watched her work did he see it. The drawing files were being opened from a shared folder on a site link that crawled every morning while the nightly backup finished. And "everything" had meant one program opening one kind of file. Nine working days, a reimage and a lost Thursday to learn what two minutes beside her desk would have told him on day one. The lesson Redbrook wrote on the wall was short: when the ticket says "everything", go and watch the thing.

The 'It's Broken' Translation Table

The table below is the dictionary. Down the left are the phrases that arrive most often. In the middle is what each usually turns out to mean, which is the hypothesis you start from. On the right is the one question that confirms or kills it, written as you would say it to the requester. Pin it near the triage screen, and add a row every time a new phrase fools the desk twice. The middle column is a list of probabilities, not certainties. "The internet is down" does occasionally mean the internet is down. The question on the right is there to find out.

Use the table in two directions. Reading left to right at triage, it turns a phrase into a first question in a few seconds. The question goes into one reply with any others the ticket needs. Reading it right to left when designing the form, it tells you what to ask before the ticket is ever written. Every question in the right-hand column is a candidate field, labelled in those exact words. A form built from this column collects most of the answers while the requester is still standing at the printer with the facts fresh. Tomas added the question about the label on the front to the Bellweather form the week after ticket 5817. The next printer ticket arrived saying "SF-04, east stairwell, says 'load tray 1'", from Priya. She had never written a ticket like it before and was not asked to. The form asked, and she answered.

Frequently Asked Questions