A Request Form People Will Finish: Five Facts and Nothing Else

Tuesday, 10:20, at Harbourview Clinic. Jonah, who runs the two-person desk, gets an e-mail from Amara at reception. "Hi, I tried to use the form but it wants a cost centre and I don't know ours, and the 'Service' list doesn't have the card reader in it, so I'm e-mailing. The card machine at the front desk says 'no connection' and there's a queue. Sorry." Jonah built that form. He is rather proud of it. It has eleven fields, four of them required, and a drop-down list of every system the clinic runs. It has a priority selector with a tooltip explaining impact and urgency. It took him a weekend. Amara spent ninety seconds on it, with a patient waiting, and did the sensible thing.

Jonah's form was built for Jonah. Every field on it is a question the desk would like answered, in the words the desk uses. The fields are arranged in the order the desk thinks about tickets. Nothing on it was designed from the chair of a receptionist with a queue. The form is complete, logical and abandoned. And the e-mail it was meant to replace is still doing all the work, which it does badly, because an e-mail asks for nothing at all.

A request form is the web page a requester fills in to ask the desk for help. Its only job is to collect the facts a technician needs to start, in words the requester already has. It must take less time than it would take them to write an e-mail. This article is part of our Getting Better Tickets From Users series, and it is about designing that page. It is the user-facing half of a pair. The triager's side, asking once for whatever the form did not collect, belongs to Gathering the Right Information Up Front. This article will not repeat it.

It covers what a form is for and what it is not, then the five facts as fields and the fields to leave off. Next comes one form per department rather than one form for everything, then labels, examples and placeholder text that teach. We cover where people give up and how to tell, then the screenshot prompt. Next comes the form as the best door rather than the only one. A short war story follows, then the form field specification to copy.

What a Form Is For, and What It Is Not

A form has one job: to get the five facts a technician needs into the ticket while the requester is still standing next to the problem. Who is affected and how to reach them, what they see, which device or system and where, since when, and how bad. If the form collects those, the ticket arrives workable and the desk starts at once. If it collects anything less, somebody has to ask, and the ticket waits a day for the answer. Every other thing a form might do is secondary to that, and most of the things forms are made to do work against it.

A form is not a classification tool. The temptation, when building one, is to make the requester sort their own ticket. That means asking them to pick a service, pick a type, pick a priority, pick a team. Each of those is a decision the desk is better placed to make, in seconds, with knowledge the requester does not have. And each is a field the requester has to stare at. The requester does not know whether "the card machine says no connection" is a network fault, a payments fault or a hardware fault. And it is unkind to ask. Triage exists so that somebody who knows the answer makes the call.

A form is also not a gate. It should never be the only way in, and it should never refuse a request because a field is blank. The moment a form becomes a test the requester can fail, they stop sitting the test and e-mail somebody. The form competes with e-mail, chat, the phone and the hallway. It wins only by being quicker and more useful than those for the person using it. (It has a disadvantage from the start: the hallway has never once asked anyone for a cost centre.)

The Five Facts as Fields

Each of the five facts becomes one field, labelled as a question in the requester's words, and the whole form fits on one screen without scrolling. The who is usually free. If the requester signs in, their name and e-mail come with them. In that case, the only thing to ask is "best way to reach you today?" with a phone number box. The what is a free-text box with a label that tells them what to put in it. It asks: "What were you trying to do, and what happened instead?" The where is a short list of places plus a text box for the label on the device. The since-when is a text box, not a date picker, because "this morning, after the update" is more useful than a calendar date. The how-bad is two plain questions: "Is anyone else affected?" and "Is there a deadline, and when?"

The table shows each fact as the requester meets it on the form. The left column is the fact in the desk's words. The next is the label the requester sees, which is a question. Then come the kind of field and an example of a good answer. That example goes beside the field as grey text or a line underneath. Notice that none of the labels contains a desk word. There is no "asset", no "service", no "incident", no "category". Those words belong to the desk's side of the ticket, and the desk can add them after it arrives.

Five facts, six fields if you count the photo, and every one of them answerable by a receptionist with a queue in under a minute. That is the whole form. It will feel too small to the person building it, because the person building it knows all the other things they would like to know. Resist. The other things can be asked on the two tickets in ten that need them. The form that asks for them on all ten is the form Amara did not finish.

Nothing Else: The Fields to Leave Off

Every field beyond the five is a cost paid by every requester on every ticket, and most of the usual extras buy nothing. The priority selector is the classic. Requesters set it to the highest value, because their problem is the most important problem they have. Or they set it to the lowest, because they do not want to make a fuss. The desk overrides it either way. A priority the desk always overrides is a field that exists to be ignored. Who sets priority, and why the requester's answer is an input rather than a decision, is in Who Decides the Priority. Ask the two how-bad questions instead; they collect what the priority field was pretending to.

The category or service list is the second. A drop-down of forty system names asks the requester to know which product runs the card reader, and they do not. So they pick the nearest word, or "Other", or leave. The desk's categories are for the desk's reports and routing. And the desk applies them at triage in seconds with a glance at the ticket. The list that works on a form is a list of places or things the requester can see. Examples are "front desk", "consulting room 3", "the printer by the lift". Those they know. The desk can map "card reader at the front desk" to whatever the category tree calls it. Keeping that tree short is a subject in its own right elsewhere in this library.

Cost centre, asset tag, department code, manager's name, operating system version and "affected configuration item" round out the usual suspects. Each of them is knowable by the desk from the requester's login, the directory or the asset list. Asking the requester to look it up is asking them to do the desk's filing. If a fact can be looked up from who the requester is, do not ask for it. If it cannot, ask whether the desk needs it on every ticket or on one ticket in twenty. If it is the latter, ask on that ticket, not on the form. The eleven-field form at Harbourview had four fields the desk could look up and three it never read.

One Form Per Department, Not One Form for Everything

A single form for every kind of request is a form that asks everyone for things only some of them have. And the fix is one short form per department that takes requests. The IT form asks which device and what the label says. The facilities form asks which room and what is wrong with it. The HR form asks what the request is about and who it concerns. Each is five or six questions. Put them together into one form and you get a dozen fields, half of which are irrelevant to any given requester. There is a "which department?" selector at the top to decide which half. The requester has to read all of it to find out.

Per-department forms also route the ticket for free. A request raised on the facilities form lands with facilities. Nobody at the IT desk has to read it and move it. Nobody at facilities wonders why a card reader is in their queue. In QuerySolv each department has its own form and its own mailbox. So the IT form can ask for the label on the device while the facilities form asks for the room number. Each request lands as an ordinary ticket in its own department's queue without a human sorting it first. Tools differ in how they do this, and some have one form with a department selector that changes the fields below it. Either works, as long as the requester sees only the questions that apply to them. How routing by form and mailbox fits together is in Routing by Department, Form and Mailbox.

The landing page that leads to the forms matters as much as the forms. A requester who does not know whether a broken door badge is IT or facilities should not have to guess. Use one page with three or four big plain links, each saying what the department fixes in the requester's words. Examples are "Computers, phones, printers and logins", "Rooms, doors, heating and furniture", "Pay, leave and contracts". A wrong guess costs the desk a move and the requester a day; a clear page costs one sentence per department. Write the sentences for the person who has never raised a ticket, because they are the one reading them.

Labels, Examples and Placeholder Text That Teach

The label on a field is the only training most requesters will ever get, so write it as the question you would ask aloud. "Description" teaches nothing. "What were you trying to do, and what happened instead?" teaches the requester, every time they see it, that the desk wants two things. Those are the task and the failure. "Location" teaches nothing. "Which device or system, and where is it? The label is usually a sticker on the front or the back" teaches them where to look. A label that is a noun gets a noun back. A label that is a question gets an answer.

Put a good example beside every field, visible all the time, not just as grey text that vanishes when they start typing. A line under the box in smaller type might say "for example: taking a card payment; the reader says 'no connection'". That shows the requester what a useful answer looks like and how long it needs to be. Most people, shown a good example, write one like it. Shown an empty box, they write "it's broken", because the box gave them no idea how much was wanted. The example does more to raise ticket quality than any instruction page, because it is in front of them at the moment they are writing.

Be careful with placeholder text, the grey words inside the box that disappear on the first keystroke. It is fine for showing the shape of an answer, and useless as the label, because the moment the requester types the question is gone. If they pause to think they are looking at a box with no idea what it was asking. Keep the question above the box, in full, always visible. Put the example beneath or beside it; use the placeholder only for something short like "e.g. RC-02". A form that hides its questions behind the typing is a form that forgets them faster than the requester does.

Use the requester's words throughout, and find out what they are by listening. If reception calls it "the card machine", the example says "the card machine". If the warehouse calls the handheld scanners "the guns", the where-field example says "scanner (the gun), label on the handle". The desk's words can go on the desk's side of the ticket. Every desk word on the form is a small translation the requester has to perform. And the first article in this series explains at length why that translation is the desk's job, not theirs.

Where People Give Up, and How to Tell

Requesters abandon a form at a small number of predictable points, and each one is a design choice the desk can reverse. The login wall is first: a form that needs a password the requester has forgotten is a form they will not reach. If the tool allows it, let the form accept a name and e-mail address from anyone on the network, and confirm the requester by e-mail afterwards. The field count is second: more than seven or eight visible boxes and the form looks like work before anyone has read a label. The unknown drop-down is third. A list of names the requester does not recognise stops them dead, because there is no honest answer and they can feel the wrong one being recorded.

Required fields with no good answer are the fourth, and the most damaging, because they do not merely slow the requester, they refuse them. A required cost centre for someone who has never heard the phrase is a locked door with the desk's name on it. Which fields can safely be required, and what each one costs, is the whole of Required Fields Without the Revolt. So here the rule is only this: require nothing the requester might not know. The fifth is the phone. A requester standing beside a jammed printer is holding a phone, not sitting at a keyboard. And a form that is unusable on a small screen is unusable at the moment the facts are freshest.

You can tell a form is being abandoned without any analytics. Count the tickets that arrived by e-mail against the ones that arrived by form over a month, and ask the e-mailers why. "I couldn't find it", "it wanted something I didn't know", "it was quicker to e-mail" are the three answers. Each points at one of the five failures above. Then sit beside three people from three departments and watch them raise a ticket on the form without helping. Watching a receptionist meet your drop-down is a humbling and useful afternoon. I have done it twice and rebuilt the form both times.

The Screenshot Prompt

A picture of the screen is the single most useful attachment a ticket can carry. And most forms either do not ask for it or ask in a way that only technicians understand. "Attach screenshot" assumes the requester knows what a screenshot is and how to take one. It assumes they know where it went, and how to find it again in a file dialog. Many do not, and the ones who do not are disproportionately the ones whose tickets say "it's broken". Ask instead for a photo: "If there is a message on the screen, take a photo of it with your phone and add it here. A photo is fine." Everyone knows how to take a photo. Nobody needs to find the folder it went to.

Say why, briefly, beside the field, because the reason is what makes people bother. Say: "The exact words on the screen usually tell us what is wrong straight away." That sentence is true and it reframes the photo from paperwork into the fastest route to a fix. Requesters who understand that the message they dismissed is the clue stop dismissing it. A desk that receives the exact wording of an error on the first ticket skips the first round of questions entirely. One photo often replaces three e-mails.

Make the attachment work from e-mail as well, since e-mail is where many tickets will keep coming from. Most tools attach whatever was attached to the message. A line in the auto-acknowledgment can say "if there is an error on the screen, reply to this with a photo of it". That recovers the picture from the e-mail route too. The desk does not care how the picture arrived. It cares that the ticket carries the words on the screen before anyone has to ask for them. The form field, the acknowledgment line and the triager's question are three doors to the same photo.

The Form Is the Best Door, Not the Only One

The form will never be the only way in. And a desk that tries to make it so loses the tickets rather than the e-mails. People will e-mail, phone, message and walk up for as long as those routes exist. Closing them pushes the requests into shadow channels the desk cannot see, which is a worse outcome than a vague ticket. The aim is for the form to be the route most people choose most of the time because it is quickest for them. At the same time, the aim is for every other route still to produce a ticket in the same queue. One queue fed by several doors is the arrangement described in One Queue, Many Doors. And the form is simply the door that asks the best questions on the way in.

Make the form the easiest route and the choice makes itself. A link on every desktop and a short address people can remember are part of it. So is a line in the acknowledgment e-mail saying "next time, this form gets you a faster answer". Together with a form that takes under a minute, these will move most requesters over without a policy. The e-mail route then carries the leftovers, the requests from people who did not know, the forwarded messages, the ones sent in a hurry. And those get the translation treatment from the triager. A form that is pleasant to use is the only user-training programme that scales. It runs itself, four hundred times a week, and never gets tired of asking the same five questions.

A Short War Story: The Forty-Item Dropdown at Northgate Retail

At Northgate Retail, the desk lead, Caleb, built a store-support form with a required "Store system" drop-down. It listed all forty-one applications the tills, back offices and stockrooms ran, by their product names. The aim was for tickets to route to the right specialist without triage. Store managers did not know the product names; they knew "the till", "the handheld" and "the stock screen". So within a fortnight most of them picked the first entry alphabetically, a labels application that nine stores used. The labels specialist was triaging the whole retail estate's tickets from her own queue and forwarding them on. That cost roughly a day's delay on each. Rosa, who managed the flagship store, gave up on the form entirely and e-mailed Caleb directly, as did eleven other managers. The form's share of store tickets fell to under a fifth. Caleb replaced the drop-down with a six-item list in the managers' own words. It read "till", "handheld scanner", "stock screen", "back-office PC", "printer or labels", "something else". He let triage map them to the forty-one. The form's share went back above three quarters within a month, and the labels specialist got her queue back. A list the requester cannot read is a required field with one option, and it will be the wrong one.

The Form Field Specification

The specification below is the form on one page. It is written so that the person who configures the tool and the person who approves the design are looking at the same thing. There is one block per field. It covers the label exactly as the requester will read it, the example shown beside it, the field type, and whether it is required. It also gives the reason the field exists, in one line, so that anyone proposing a new field has to write a reason too. Fill one copy per department. If a block's reason line is hard to write, the field does not belong on the form.

REQUEST FORM FIELD SPECIFICATION — ONE PAGE PER DEPARTMENT
Department: ______________   Form owner: ______________   Reviewed: ________
Target time to complete: under one minute, on a phone, standing up.

LANDING LINK TEXT (what this department fixes, in requesters' words)
  "______________________________________________________________"

FIELD 1 — WHO
  Label:      Your name and e-mail (filled in from your login)
  Also ask:   "Best way to reach you today?"
  Example:    "Extension ____, or ask for me at ______________"
  Type:       pre-filled text + one short text box
  Required:   name and e-mail yes; phone no
  Reason:     the technician can call instead of e-mailing back and forth

FIELD 2 — WHAT
  Label:      "What were you trying to do, and what happened instead?"
  Example:    "______________________________________________________"
  Type:       free text, four lines visible
  Required:   yes
  Reason:     the task and the failure together point at the cause

FIELD 3 — WHERE
  Label:      "Which device or system, and where is it?
               The label is usually a sticker on the front or back."
  Example:    "______________, label ______, in ______________"
  Type:       short list of places in requesters' words + one text box
  Required:   the list yes; the text box no
  Reason:     nobody has to come and find it first

FIELD 4 — SINCE WHEN
  Label:      "When did it last work, and did anything change around then?"
  Example:    "Worked yesterday. ______________ this morning."
  Type:       free text, one line
  Required:   no
  Reason:     most faults start with a change, and the time finds it

FIELD 5 — HOW BAD
  Label A:    "Is anyone else affected?"
  Label B:    "Is there a deadline we should know about? When?"
  Example:    "Everyone at ______________ / needed by ______ today"
  Type:       two one-line text boxes
  Required:   no
  Reason:     sets the priority honestly without a priority selector

FIELD 6 — PICTURE
  Label:      "If there is a message on the screen, add a photo of it.
               A phone photo is fine."
  Why line:   "The exact words on the screen usually tell us what is
               wrong straight away."
  Type:       file attachment
  Required:   no
  Reason:     the exact wording replaces the first round of questions

FIELDS DELIBERATELY LEFT OFF (and where the desk gets them instead)
  Priority ............ set at triage from Field 5
  Category / service .. set at triage from Fields 2 and 3
  Asset tag ........... looked up from Field 3 or the requester's login
  Cost centre / dept .. looked up from the requester's login
  Manager ............. looked up from the directory
  ____________________ ______________________________________________

PROPOSED NEW FIELD (fill in before adding anything)
  Label as the requester will read it: _______________________________
  Needed on every ticket, or one in ____?  Can the desk look it up? [ ] yes [ ] no
  Reason in one line: ________________________________________________
  Approved by form owner: ________   Date added: ________

The last block is the one that keeps the form small after you have left. Fields are added by people with good reasons and a particular ticket in mind. A form with no process for saying no grows by a field a quarter until it is Jonah's eleven again. The proposed-field block makes every addition write down its reason and say whether the desk could look the fact up instead. And most proposals do not survive the second question. Jonah rebuilt the Harbourview form from this sheet in an afternoon, six fields, two required, in reception's words. Amara used it the following week for a label printer and attached a phone photo of the display without being asked. The ticket needed no questions, which was the first time Jonah had seen that from reception, and he had not trained anyone. The form had.

Frequently Asked Questions