Getting Better Tickets From Users

"Printer broken." That is the whole ticket: two words, no printer name, no floor, no error, no sender other than an address that belongs to a shared mailbox. The technician who opens it has a choice between walking the building and sending the first of what will be four e-mails. Neither is the user's fault. From where they sit, the printer is broken, they have said so, and the people who know about printers have been told. The desk built a form with eleven fields and the user found the one channel that skips it. That is also the one everybody has used since the company had six people. Tickets arrive empty because the desk made it easiest to send them that way.

This series is about making the good ticket the easy one. It covers why tickets arrive saying "it's broken" and why that is a reasonable sentence. It covers a request form people will finish, with the minimum fields and nothing else, and required fields without a revolt. It covers translating the vague ticket into one you can work, in a single reply. It covers training users to write better tickets without lecturing anyone. And it covers measuring ticket quality so that the thing you fix is the form, not the user. The desk cannot train four hundred people. It can change one form, and the form trains them.

Articles in This Series

• Why Tickets Arrive Saying 'It's Broken', and Why That Is Fair
  The user's view, what they know and what they do not, and why the form gets skipped. Also covers why the translation problem belongs to the desk, and the 'it's broken' translation table.
• A Request Form People Will Finish: Five Facts and Nothing Else
  The minimum fields and the five facts, a form per department, placeholder text that teaches, friction and abandonment, the screenshot prompt, and a form field specification.
• Required Fields Without the Revolt: What to Require and What to Ask
  Which fields to require and which to merely ask for, dropdowns versus free text, and the cost of each required field. Also covers testing with three real users, and a required-fields decision table.
• Translating the Vague Ticket Into One You Can Work
  The user-facing questions in order, reading between the lines, and the single reply that asks for everything at once. Also covers the phone call that saves four e-mails, and the translation reply to copy.
• Training Users to Write Better Tickets Without Lecturing
  Nudges in the form, examples beside the fields, thanking a good ticket, and the two-line guide in the acknowledgment. Also covers never scolding, and a 'how to ask IT for help' one-pager for users.
• Measuring Ticket Quality and Fixing the Form, Not the User
  The back-and-forth count before work starts, the first-reply-is-a-question rate, quality by channel and department, what the numbers say about the form, and a ticket-quality scorecard.

Explore More Topics

This series is part of the QuerySolv helpdesk topic library. It covers the foundations, processes, communication, knowledge, tooling, metrics, classic ticket domains, people and strategy behind a support desk that works. The library pairs well with the software we build: QuerySolv. It is a self-hosted help desk that runs as one Windows service on your own network. It is licensed once per installation, not per agent per month.