A feedback form goes out. Forty people answer. Thirty-four of them give four out of five, the comment box mostly says "good" or is empty, and the two people who wrote something detailed were already complaining by email anyway. The form worked, in the sense that it collected responses. It produced nothing anyone can act on.
This is the normal outcome, and it is not caused by the respondents. It is caused by a form that was written to collect opinions rather than to answer a question. A feedback form that changes something has a decision behind it, and the questions exist to inform that decision. Everything below follows from that.
Start from the decision, not from the questions
Before any question is written, there should be a sentence that begins "depending on the answers, the thing that changes is". If that sentence cannot be finished, the form will produce a number that gets reported and nothing else.
Three examples of the difference.
A form that asks "how satisfied were you with the event" produces a score. A form that asks which of the four sessions was worth the time and which one could be cut produces next year's schedule.
A form that asks "how was the support you received" produces an average. A form that asks whether the problem is now solved, and if not what is still broken, produces a queue of things to fix.
A form that asks staff "how do you feel about working here" produces a number that moves by two points a year. A form that asks which one thing, if changed, would make the job easier produces a list somebody can work through.
The second version in each pair is narrower and less flattering. It is also the only one with a use. Narrowness is the whole trick: a feedback form should be about one interaction, one event, one decision, and it should be sent close to the thing it asks about.
Choosing a scale that means something
Most feedback forms open with a rating, and the choice of scale decides what can be done with the answers.
| Scale | What it is good for | What it costs |
|---|---|---|
| Zero to ten, likelihood to recommend | Comparing over time and between teams, with published benchmarks | Says nothing about what to change |
| One to five satisfaction | Familiar, quick to answer, easy to chart | Clusters at four, so small real changes disappear |
| Five point agree to disagree, on specific statements | Points at a specific cause, such as the room, the pace, the price | Needs several statements, which makes the form longer |
| Two options, worked or did not work | Highest completion rate, unambiguous | No gradation, so trends are coarse |
The recommendation question is worth understanding properly rather than copying. Bain, which originated the measure, defines it as asking "How likely are you to recommend us to a friend or colleague?" scored on a zero to ten scale, with the score calculated as the percentage of respondents who answer nine or ten minus the percentage who answer zero to six, and seven and eight counted as neither. The reasoning for eleven points rather than five is documented: a zero to ten scale avoids people confusing the ends of the scale, and it gives enough room that satisfied respondents do not default to the top mark. The full method is described in Bain's explanation of how the score is measured.
The trap is treating that number as diagnosis. It tracks something real and it never says what to fix. Whatever scale is chosen, the question that follows the score is where the information is.
A last note on scales: pick one and keep it. Changing from five points to ten points between rounds destroys the comparison, which is usually the only reason the score was being collected.
The open question is the one that pays
One well placed open question produces more usable material than six rating questions. Three things decide whether it gets answered.
Place it after the score, not before. A respondent who has just chosen a number is primed to explain it, and the explanation arrives without prompting.
Make it specific enough to answer. "Any other comments" is answered by nobody. "What is the one thing that would have made this better" is answered by most people, because it asks for one thing rather than an essay, and because it gives permission to be critical without being rude.
Branch it on the score where the tool allows. Someone who answered nine should be asked what was worth telling a colleague about. Someone who answered four should be asked what went wrong. Sending both the same question wastes the best moment either of them will give.
Keep it to one open question, or at most two. The second open box halves the answer rate on the first, because the respondent can see how much typing is ahead. If several open questions seem necessary, that is usually a sign the form is covering more than one decision and should be two forms.
Who answered, and what they were talking about
An anonymous feedback form and an identified one are different instruments, and the choice should be deliberate rather than a default.
| Anonymous | Identified | |
|---|---|---|
| Honesty on uncomfortable subjects | Higher | Lower, sometimes much lower |
| Ability to follow up on a specific problem | None | Direct |
| Ability to link answers to what actually happened | Only in aggregate | Per person, per interaction |
| Risk of the same person answering repeatedly | Real | Low |
| Suitable for | Staff surveys, sensitive topics | Support, events, orders, anything with a next step |
For anything with a next step, identified feedback is worth the loss in candour, because an unanswered complaint is worse than no complaint. A middle path works well: identify the response by the email address that received the request, and make the name optional.
Two fields are worth adding whichever route is chosen. The first is what the feedback is about, filled in automatically where possible rather than asked, so the answer is tied to a specific order, session or ticket. The second is whether the person wants a reply. That single question sorts the responses into the ones that need action and the ones that are information, and it saves reading all of them with the same attention.
What does not belong on the form is anything the team records afterwards: whether the issue was resolved, who dealt with it, what was refunded. Those are internal fields that sit beside the response rather than questions the respondent answers, and keeping them separate is what stops a feedback log becoming unreadable. Tools built around response management treat those as columns the team fills in, appearing in the list and in the export but never on the form.
The question faults that quietly ruin the answers
Four faults account for most unusable feedback, and all four are invisible to the person who wrote the form.
Leading questions. "How much did you enjoy the new booking process?" has the answer built into it, and the respondents who disliked it will either soften their answer or stop. The neutral version asks what the new booking process was like to use.
Two questions in one. "Was the venue and the catering satisfactory?" cannot be answered by somebody who liked the room and not the food, so they pick a middle value and the information is gone. Every question should have exactly one subject.
Grids of statements on a phone. A matrix of eight statements across five columns is readable on a laptop and close to unusable on a small screen, which is where most feedback forms are opened. The same eight statements asked one at a time take longer to write and get answered far more often.
Required open boxes. Forcing a comment produces "n/a", a full stop, and abandonment. The open question should be optional and worth answering, not compulsory.
There is a fifth fault that is harder to see: asking about things that will not be changed. If the catering contract is fixed for two years, asking about the catering generates complaints that cannot be acted on and teaches respondents that answering is pointless. Only ask about what is actually in play.
Length, timing and how many people answer
Response rate is a design outcome, not luck.
Send it close to the thing. Feedback requested the same day carries detail. Feedback requested three weeks later carries a general impression, which is the thing nobody can act on.
Keep it to what fits on one screen of a phone. Three questions and one open box is a form people finish. Twelve questions is a form people abandon halfway, which is worse than no form because the partial responses skew whatever is left.
Show one question at a time when the form goes out by link. On a phone, a single question with a progress bar finishes more often than a long scrolling page, because the respondent can always see how little is left.
Say how long it takes, and be accurate. "Three questions, about a minute" raises completion. Saying "a short survey" when it is eighteen questions costs the next one as well.
Ask fewer people, more often, rather than everybody once a year. A monthly sample of fifty is more useful than an annual census of six hundred, because it catches changes while they can still be traced to a cause.
Reading them is the job the form does not do
Here is where most feedback programmes actually fail. The form is fine. The responses arrive. Nobody owns them.
A response that contains a specific complaint needs three things to happen: somebody has to be responsible for it, somebody has to reply, and the state of it has to be visible to everyone else so that two people do not both answer and so that nothing sits untouched for a fortnight. A spreadsheet of responses supports none of that. It supports counting.
The practical shape that works is unremarkable. Every response gets a status, such as unread, needs a reply, replied, or no action needed. Every response that needs action gets an owner. Replies are sent from the same place the response is read, so the record of what was said stays attached to what it answers. Then the weekly question, which is how many responses are still unanswered, has a number rather than an argument.
That shape is also what makes the score worth collecting, because a respondent who gets a reply to a complaint answers the next form. Feedback that visibly changes something is the only thing that sustains a response rate. Seeing what a worked example looks like takes less time than reading about it, and the demo is loaded with sample responses already at different stages.
What to change first
Write the sentence that says what will change depending on the answers, then cut every question that does not inform it. Add one specific open question after the score, and ask whether the person wants a reply. If the responses are already arriving and the problem is that nobody can see which of them has been answered, Halict keeps an owner, a status and the sent replies on each one.
Q1. How many questions should a feedback form have?
Three or four, with one of them open. That fits on a phone screen and gets finished. Longer forms produce more abandoned responses, and partial responses are worse than none because they skew whatever is left. If more than four questions seem necessary, the form is probably covering two different decisions and should be split.
Q2. Is a one to five rating or a zero to ten scale better?
They answer different questions. A one to five satisfaction rating is quick and familiar, but answers cluster at four, so real changes are hard to see. The zero to ten recommendation question, as defined by Bain, counts nines and tens as promoters and zero to six as detractors, and it is designed for tracking over time rather than for diagnosis. Whichever is chosen, keep it constant between rounds or the comparison is lost.
Q3. Should feedback be anonymous?
For staff surveys and sensitive subjects, yes, because candour matters more than follow up. For support, events and orders, identified feedback is worth more, because a specific complaint can be answered. A workable middle path is to identify the response by the email address the request was sent to and leave the name optional.
Q4. What open question actually gets answered?
One that asks for a single specific thing, placed after the rating. "What is the one thing that would have made this better" works because it limits the effort and gives permission to be critical. "Any other comments" is answered by almost nobody. Branching the question on the score, so high raters and low raters are asked different things, raises the quality further.
Q5. How soon after the event should a feedback form be sent?
The same day, or the next one at the latest. Requests sent close to the interaction come back with specifics that can be traced to a cause. Requests sent weeks later come back with general impressions, which are the answers nobody can act on. Asking a small sample often beats asking everybody once a year.