Required Fields Without the Revolt: What to Require and What to Ask

Monday, 09:00, at Stonebridge Insurance. Mei switches on the new request form. It has been three weeks in the making and it fixes everything the old one got wrong. Six fields are now required, including asset tag, impact, urgency and the affected system. The aim is that no ticket can ever again arrive saying "it's broken". By Wednesday afternoon the form has produced nine tickets and the IT mailbox has produced forty-one, up from about twenty on a normal Wednesday. One of the forty-one, from Beatriz in claims, reads in full: "Your form won't let me send anything without an asset tag and I don't know what that is, so: the claims system logs me out every ten minutes. Sorry to e-mail." Eleven others say some version of the same thing. The form has not reduced the number of vague tickets. It has moved them to a channel with no fields at all.

Mei did what the previous article in this series warned against and what nearly every desk does once. It looks like the obvious fix. If the tickets lack facts, make the facts mandatory. The logic is sound and the result is a revolt. It is quiet at first, as people route around the form. Then it is loud, when a department head asks why IT is making the claims team look up asset tags while the claims system logs them out. A required field is not a request for information. It is a refusal to listen until the information is supplied, and people respond to refusals the way people do.

A required field is a field the form will not submit without. An asked field is one the form shows, labels and encourages but will accept blank. The difference sounds small and is the whole subject. This article is part of our Getting Better Tickets From Users series. It follows A Request Form People Will Finish, which decided what the form asks. This one decides which of those questions the form may insist on. It also covers what happens on the channels where it cannot insist on anything.

It covers what "required" actually does to a requester, and the cost of each required field. Next come the three-part test a field must pass before it may be required, which fields pass, and dropdowns versus free text. Then it covers testing the form with three real users, and the e-mail channel that bypasses the form. It finishes with changing required fields without the revolt, a short war story, and the required-fields decision table to copy, in that order.

What "Required" Actually Does

A required field turns the form from a conversation into a checkpoint, and the requester feels the change instantly. An asked field says "tell us this if you can". A required field says "we will not take your problem until you tell us this", in red, usually with an asterisk, at the moment they press submit. For a fact the requester has, that is a small nudge. For a fact they do not have, it is a locked door. Then the only choices are to invent an answer, to abandon the form, or to find another route. All three happen. None of them produces the fact the desk wanted.

The invented answer is the quiet failure of the three, because it looks like success. The field is filled and the ticket submits. The report at the end of the month shows that every ticket now carries an asset tag. The tags are "n/a", "don't know", "123", the number off the back of the monitor, and in one memorable case at Stonebridge, the requester's own staff number. A required field with no good answer does not collect data. It collects whatever gets the door open, and the desk then builds reports on it. (The reports are very tidy.)

The other two failures are visible if you look. Abandonment shows up as fewer form tickets. The route-around shows up as more e-mail, more phone calls and more "quick question" messages to technicians. All of those carry fewer facts than the worst form ticket. Mei's forty-one e-mails on a Wednesday were the form's required fields, arriving by another door with none of the fields filled. A required field never reduces the number of vague tickets on a desk that has an e-mail address. It only decides which channel they arrive by.

The Cost of Each Required Field

Every required field is paid for by every requester on every ticket, whether or not that ticket needed the fact. The bill comes in four currencies. Time: a required field the requester must look up, such as an asset tag on a sticker under the desk, is a minute of crawling. That goes for the one ticket in ten where the tag mattered and the nine where it did not. Accuracy: a requester forced to answer a question they cannot answer gives a wrong answer. A wrong value is worse than a blank because a blank is honest and a wrong value is believed. Abandonment: each required field is another point at which the requester can decide the e-mail is quicker. And resentment, which is the slow one, and the one that department heads carry into meetings.

The cost also falls on the desk, in a way that is easy to miss. A required field is a promise that the desk reads it and acts on it. If the form insists on "impact" and the triager overrides it on every ticket because requesters pick the highest value, the question is unused. In that case, the desk has made four hundred people answer it. Requesters notice when their answers change nothing. The next time the field is required, they type whatever is quickest, and they are right to. A field the desk ignores should not be asked, and a field the desk ignores should certainly not be required.

Set against those costs is the benefit, which is real and narrow. A required field guarantees that one fact is present on every form ticket. That saves a question on the tickets where the fact was missing and would have been asked. For a fact that is missing on most tickets, acted on by the desk on most tickets, and known by the requester on all of them, the benefit wins. For anything else, the costs win. They win by more than the person building the form expects. That person knows every answer and cannot feel the locked door.

The Test a Field Must Pass

A field may be required only if it passes three tests, and it must pass all three. First: can every requester, including the newest starter and the visiting contractor, answer it truthfully in ten seconds without looking anything up or asking anyone? Not most requesters; every one. If a receptionist with a queue cannot answer it, it fails. Second: does the desk act on the answer on every ticket, not just some? If the triager would read it and move on without doing anything differently on half the tickets, it fails. Third: is a blank worse than a wrong answer? If a requester forced to fill it would plausibly type something misleading, a blank is the better outcome, and the field fails.

Run the Stonebridge six through the test and most of them fall at the first fence. Asset tag: the newest starter does not know what one is, so it fails test one. Impact and urgency: requesters answer honestly from their own chair, which is the wrong chair for the question. So the desk overrides them and the field fails test two. Forced answers also skew high, so it fails test three. Affected system, as a list of product names: fails test one for anyone who calls it "the claims thing". The requester's name and e-mail pass all three. So does "what were you trying to do, and what happened instead?" Everyone can describe what they were doing. The desk acts on it on every ticket, and a blank there is a ticket that says nothing.

The test leaves most fields in the asked column, and that is the point. Asked fields still collect the fact on most tickets, because most requesters who can answer a clearly labelled question do. They leave the door open for the ones who cannot. The triager then asks for whatever is blank, once, in one reply. That discipline belongs to Gathering the Right Information Up Front. A form that asks for everything and insists on almost nothing produces tickets that are mostly complete and a channel mix that stays healthy. That is a better outcome than tickets that are entirely complete and a form nobody uses.

Which Fields Pass

On a general request form, two fields pass the test and the rest do not. The requester's identity, name and e-mail, passes because the form usually fills it from the login and the desk cannot reply without it. The description, "what were you trying to do, and what happened instead?", passes because everyone can answer it, the desk reads it on every ticket, and a blank is useless. Those two can be required without a murmur. A requester who hits a required description field has not been refused anything. They have been reminded to say what is wrong.

The where-field is the interesting borderline. A list of places in the requester's words might say "front desk", "claims floor", and "the warehouse office". It passes test one only if it ends with an honest escape such as "somewhere else or not sure". Without the escape, the requester whose place is not listed is forced to lie, and the field fails test three. With it, the list can be required, and the triager treats "not sure" as the question to ask. The same rule applies to any list: a required list without an honest escape is a required lie for whoever does not fit.

Since-when, how-bad and the photo are asked, never required. Since-when is unknown to a requester who arrived at a problem someone else noticed. How-bad is a judgement most requesters are reluctant to make for fear of overstating it, and forcing it produces either "urgent" or "whenever". The photo is optional because not every problem has a screen, and because a required attachment on a phone is a locked door with a file dialog behind it. All three are collected on most tickets by a good label and a good example, which is the training the form does on the desk's behalf. It is what Training Users to Write Better Tickets Without Lecturing treats as the main event.

Dropdowns Versus Free Text

A drop-down list is right when the list is short, complete, written in the requester's words and has an honest escape. Otherwise free text wins, and it wins more often than form builders like. A list of six places the requester can see out of their own window works. A list of forty-one product names does not, and the previous article has the war story to prove it. The question to ask of any list is whether the requester can find their answer in it in three seconds without reading the whole thing. If they have to read the whole thing, it is too long. If their answer is not there, it is a locked door with a scroll bar.

Lists have a hidden cost that free text does not: they produce confident wrong data. A requester who cannot find their answer picks the nearest one, or the first one. The ticket arrives with a value that looks deliberate and is not. The desk routes on it, reports on it, and a month later wonders why the labels application generates so many tickets. Free text produces "the claims thing", which is vague but honest. Vague-but-honest is translated in one reply while confident-wrong is believed until something breaks. Where the list must exist for routing, keep it to a handful of entries in the requester's words. In that case, let the desk map them to whatever the system names are, as triage, after arrival.

Radio buttons, the row of round options where one is picked, suit lists of five or fewer because every option is visible without a click. A list of two or three yes-or-no style options ("Is anyone else affected? Just me / A few people / Everyone here") is better as radio buttons than a drop-down. It is better still with "I'm not sure" as the last option. Free text suits everything with more than one honest shape of answer, which is most things. The desk's categories, priorities and system names stay off the form entirely, in whatever control. The desk owns those fields and sets them on the ticket after it arrives. There, a wrong value costs a click to fix instead of a requester to lose.

Testing the Form With Three Real Users

Before any field is made required, watch three real people from three different departments use the form. Believe what you see over what you intended. Pick a receptionist, someone from the department that e-mails most, and the newest starter you can find. Give each a real, recent problem from the queue to raise, say nothing, and start a stopwatch. Note every pause longer than three seconds, every question they ask aloud, and every field they skip. Note every time they scroll back up to reread a label, and every "what does this mean?" Those notes are the form's defects, written by the only testers whose opinion counts.

Three is enough because the failures repeat. If two of three stall at the same field, the field is the problem, and you do not need a sample of thirty to know it. If all three finish in under a minute without a question, the form is ready. If one of three abandons it, ask them why before they leave the chair. The answer then will be a sentence you can act on: "I didn't know what to put in that box" or "I thought I'd be quicker e-mailing". Run the test again after every change, with three new people, because the people who tested the last version now know too much.

• Choose three people from three departments, including the newest starter available.
• Give each a real recent problem to raise, and say nothing while they do it.
• Time each from opening the form to the confirmation screen.
• Note every pause over three seconds, and which field it was on.
• Note every question asked aloud, word for word.
• Note every field skipped, and ask afterwards why.
• Note any value that was guessed, and what the honest answer was.
• Fix the two worst findings, then retest with three new people.

I have run this test on forms I was proud of and have never once come out of it with the form unchanged. The field I was surest about was the one the receptionist read three times and then skipped. The test is cheap, slightly embarrassing and the best hour the desk will spend on the form. It should be rerun whenever anyone proposes a new required field. Do it before the field goes live rather than after the e-mails double.

The E-mail Channel That Bypasses the Form

E-mail cannot have required fields, and the desk should design for that rather than resent it. A requester who e-mails the desk sends whatever they typed. The ticket is created from it with the sender as the requester and the subject line as the title. Every tool that turns mail into tickets works this way, QuerySolv included. An e-mail is a message, not a form. The form's fields are empty on it by definition. No setting changes that. The question is what the desk does about the fact, and there are two good answers and one bad one.

The first good answer is to accept the e-mail and let the acknowledgment do the asking. The automatic reply that confirms the ticket can carry two lines: "If there is an error on the screen, reply with a photo of it. If you can, tell us which device and since when." Many requesters reply at once, because they are still beside the problem and the ticket number has made them feel heard. The triager asks for whatever is still missing, once. The e-mail route then produces tickets that are nearly as complete as the form's, and nobody was refused anything.

The second good answer is to make the form easier than the e-mail, so that the e-mail route dwindles on its own. Consider a form with two required fields, a one-minute completion time and a link on every desktop. It also has a line in every acknowledgment saying "next time, the form gets you a faster answer". A form with those features moves most requesters across without a policy. The e-mail that remains is from the people who did not know, the forwarders and the hurried, and that is a manageable share. The bad answer is to refuse e-mail, or to reply to it with "please use the form". That teaches the requester that the desk is a form-checking department. The next request goes to a technician's personal inbox, where no ticket is created at all. The whole argument for many doors into one queue is in One Queue, Many Doors, and required fields do not change it.

Changing Required Fields Without the Revolt

Make one field required at a time, say why in one sentence, and watch the channel mix for a fortnight before touching the next. The sentence goes in the acknowledgment and on the form itself: "We now ask which device it is so that we can come to the right one first time." People accept a required field whose reason they can see and whose answer they have. They revolt against six at once with no reason given, which is what Mei shipped on a Monday. The revolt was reasonable.

Watch two numbers while the change settles. One is the share of tickets arriving by form against e-mail. The other is the number of first replies from the desk that are questions. If the form share falls after a field is required, the field failed the ten-second test for a group of requesters you did not think of. In that case, it goes back to asked until you find out why. If the question rate falls, the field is earning its place. Both numbers belong to Measuring Ticket Quality and Fixing the Form, Not the User. They are the only honest way to tell whether a required field did what it was for.

Be ready to reverse. A required field that produced "n/a" on a third of tickets in its first fortnight has told you something. The something is not that a third of your requesters are careless. Set it back to asked, rewrite the label or the example, and try again. The form is the desk's, and the desk can change it in a minute. The requesters' habits take months to change and longer to win back. A reversal costs nothing. A revolt costs the form.

A Short War Story: The Mandatory Asset Tag at Ashgrove Housing

At Ashgrove Housing, the desk lead, Noor, made the asset tag a required field after an audit found that a third of hardware tickets could not be matched to a device. For two months the field was filled on every form ticket. When Noor finally ran the matching report again, the unmatched share had risen, not fallen. Housing officers who did not know where the tag was had typed the serial from the back of the monitor, the number off the mouse, the extension number and, in forty-one cases, the word "laptop". The e-mail queue had grown by about a quarter over the same two months, mostly from the repairs team. Their tablets had no tag at all. Their officers had learned that the form would not take their tickets. The asset team had meanwhile spent an afternoon each week correcting the tags the form had collected. That was more time than the old blank field had ever cost them. Noor set the field back to asked. She rewrote the label to say where the sticker usually was and that "not sure" was a fine answer. The matching rate climbed past where the audit had found it within a month. A required field does not make people know things; it makes them type things.

The Required-Fields Decision Table

The table below runs the usual fields through the three tests. It says for each whether it is required, asked or left off the form, and what the desk does when it arrives blank. Use it as the starting position for a general request form and argue with individual rows for your own desk. The tests are the part that must not change. The right-hand column is the one that keeps the asked fields honest. An asked field with no plan for the blank is a field the desk will eventually be tempted to require.

Two fields required, six asked, five left off: that is where the test leaves a general form. It is roughly where every form I have watched real people finish has ended up, whatever it started as. Mei rebuilt the Stonebridge form from this table in the week after the e-mails doubled. Name, e-mail and the description stayed required; the where-list got a "not sure" option; impact, urgency and the asset tag came off. The form's share of tickets recovered within three weeks. Beatriz, who had apologised for e-mailing, used it the next time without comment. That is the only review a form ever gets.

Frequently Asked Questions