A customer feedback form is the cheapest research tool a SaaS team has, and most of them are wasted. The usual version asks for a star rating, adds a giant "Any other comments?" box, and lands in a shared inbox nobody owns. A few weeks later someone exports the answers to a spreadsheet, skims the first page and moves on.
The form itself is rarely the problem. The problem is that nobody decided what each question was for, or what would happen to the answer. This guide fixes both: which questions to ask, three copy-ready customer feedback form templates for the moments that matter in a SaaS product, and a simple routine for turning answers into roadmap decisions customers can actually see.
Start with the decision, not the questions
Before you write a single field, finish this sentence: "We will use these answers to decide ______."
Good answers sound like "which onboarding step to fix first", "whether to build bulk export this quarter" or "why trial users on the Free plan do not upgrade". Bad answers sound like "to understand our customers better". That is a wish, not a decision, and it produces forms with fifteen questions and no owner.
The GOV.UK Service Manual puts it plainly: before you start, know why you are asking every question. That advice comes from government services, but it applies even more to a SaaS feedback form, because your users owe you nothing and will close the tab the moment a question feels pointless.
A useful test: for each field, write next to it who reads the answer and what they would do differently because of it. If you cannot fill that in, delete the field.
The five question types that earn their place
Almost every useful customer feedback form is built from five kinds of question. You rarely need all five at once.
The GOV.UK guidance also notes that closed questions are easier to answer than open ones, that a series of simple questions can beat one complex question, and that "I am not sure" should be an allowed answer when it is a valid one. All three hold up well in product feedback forms. A user who is forced to pick a reason they do not agree with gives you noise, not data.
Questions to cut
These appear in a lot of feedback forms and almost never change a decision:
Cutting questions is also a privacy decision. The UK ICO guidance on the data minimisation principle says personal data should be adequate, relevant and limited to what is necessary for your purpose. If a feedback form collects a phone number "just in case", that is exactly the kind of field the principle asks you to drop. Check the rules that apply where your customers are, and tell people in one line what you will do with their answers.
Template 1: In-app feedback form (always available)
This is the form behind a "Send feedback" link in your app menu. People open it when something is annoying them right now, so keep it short.
Intro line: "Tell us what is working and what is not. A real person on the product team reads every message."
1. What is this about? (single choice) Bug or something broken / Idea or feature request / Something is confusing / Pricing or billing / Other
2. What were you trying to do? (short text, one line)
3. What happened, or what would you like to happen instead? (open text)
4. Can we contact you about this? (yes or no)
Hidden fields, filled automatically: account ID, plan, page URL, browser and app version. Never ask a user to type something your app already knows.
Route the answers by the first question. Bugs go to support. Pricing and billing go to whoever owns billing. Ideas and feature requests go to the product team, ideally into the same place as every other request, using a consistent feature request template so the detail is comparable.
Template 2: Post-onboarding feedback form
Send this once, a few days after a new account finishes setup or reaches its first real outcome, whichever your product can detect. The goal is to find the step where new customers struggle while they still remember it.
1. How easy was it to get set up? (scale from 1, very hard, to 5, very easy)
2. What is the main reason for your score? (open text)
3. Which step took the longest? (single choice, listing your actual setup steps, plus "I am not sure")
4. Is there anything you expected to find but could not? (open text, optional)
5. Can we contact you about your answers? (yes or no)
Question 3 is the one that pays off. When answers cluster on one step, you have a specific, fixable problem instead of a vague satisfaction number.
Template 3: Relationship feedback form (quarterly)
This is the "how are we doing overall" form. Many teams use the Net Promoter question here. Bain and Company, which created the Net Promoter System, describes the standard question and calculation: ask "How likely are you to recommend us to a friend or colleague?" on a zero-to-ten scale, then subtract the percentage of detractors from the percentage of promoters (those who answer 9 or 10).
1. How likely are you to recommend us to a friend or colleague? (0 to 10)
2. What is the main reason for your score? (open text)
3. What is the one thing we should improve next? (open text)
4. Which of these do you use most? (multiple choice, listing your main features)
5. Can we contact you about your answers? (yes or no)
Whichever score you choose, the number is a thermometer, not a plan. The plan comes from questions 2 and 3, and it only works if you read them.
What to do with the answers
A customer feedback form only builds trust if people can see something happen afterwards. This is the part most teams skip, and it is why response rates fall over time.
1. Give every response an owner and a tag within a week. Use a small, fixed tag list such as area of the product, type of feedback and plan. Our feedback inbox tagging checklist has a ready-made scheme.
2. Merge feature requests into one public place. When three customers ask for bulk export in three different forms, that should become one request with three supporters, not three rows in a spreadsheet. On Roadmapr, customers can post a request with a title, a description and an optional category on your public board, and signed-in users vote once per request, so repeated asks show up as votes instead of duplicates. Our feature voting software page explains how that board works.
3. Reply to the people who said yes to contact. A short, honest answer beats silence. If the answer is "not now", our guide on how to say no to feature requests has reply templates.
4. Show the status change. Move the request through Under review, Planned, In progress and Completed so everyone who asked can follow it without emailing support.
5. Announce it when it ships. Write a changelog entry and link it back to the original request. Our release notes template shows how to write that entry, and closing the feedback loop covers the last step: telling the people who asked.
When customers see that a form answer turned into a roadmap card, and the card turned into a shipped feature, the next form gets more and better answers. That is the real return on a feedback form.
A quick checklist before you publish your form
FAQ
How many questions should a customer feedback form have?
For in-product forms, three to five. Every extra question lowers the number of people who finish. If you need more detail, ask for permission to follow up and have a conversation instead.
Should feedback forms be anonymous?
Usually not for SaaS products. Knowing the account and plan makes the answer far more useful, and lets you reply. Be clear about it in the intro line, and keep an optional anonymous route if your users need one.
What is the difference between a feedback form and a feature request board?
A form is private and good for capturing context. A public board is where requests are merged, voted on and given a status. The strongest setup uses both: the form collects, the board shows progress.
How often should we send a relationship survey?
Often enough to spot a trend, rarely enough that customers do not feel nagged. Quarterly is a common starting point. Keep the question wording identical so the results stay comparable.
Keep the form small and the loop visible
A good customer feedback form is short, asks only what someone will act on, and is connected to a visible process. Pick one of the templates above, cut it down to the questions you can actually use, and decide today who reads the answers. The form starts the conversation. Your roadmap and changelog are where customers see you kept your side of it.
Ready to build your public roadmap?
Roadmapr gives you a public roadmap, feature voting, and a changelog in one place. Start on the Free plan and upgrade when your team grows.
Get Started Free