A product feedback form for software teams
In-app feedback arrives as one box of text: a bug, a request and a complaint, all written the same way. The form earns its place by asking which one it is, then asking the question each needs: how to reproduce the bug, and what job the request is for.
What should software product teams ask first?
| Ask | Why it matters |
|---|---|
| Is this a bug, a feature request, or general feedback? | Each goes to a different queue and needs a different next question. |
| For a bug: what were you doing when it happened? | The steps are what an engineer needs to reproduce it. |
| For a bug: does it happen every time, or only sometimes? | An intermittent bug is a different investigation. |
| For a request: what are you trying to get done that you can’t today? | The job behind a request is often better solved by something other than the feature asked for. |
| For a request: how are you working around it now? | The workaround shows how much the gap is costing them. |
| How important is this to you? | It ranks the queue alongside how many people ask. |
| Can we email you when something changes? | Closing the loop is what keeps people sending feedback. |
If an answer would not change what you do next, leave the question out. Each extra question is one more reason for someone to stop before they finish.
Which answers come back too vague to use, and what do you ask next?
The answers that cause a phone call are rarely missing. They are present and too loose to act on. A narrower follow-up, asked straight away while the person is still there, usually settles them. Offering likely answers shows the person the level of detail you need.
| What comes back | The follow-up that settles it |
|---|---|
| “It’s broken.” | What did you click or type just before, and what did you expect to happen? |
| “Add an export.” | Export to what, and what do you do with the file once you have it? |
| “It’s slow.” | Which page or action, and is it slow every time or only at certain times of day? |
Follow up once per gap, then move on. If an answer is still unclear after one follow-up, flag it for whoever picks the request up rather than pressing.
When is a call or a visit still the right move?
A bug that blocks a paying customer goes to support, now, and a request from a large account goes to its account manager. The form replaces neither. It gives everyone else a channel that asks the right second question, so the backlog holds bugs that can be reproduced and requests with a reason attached.
How do you set this up from the Product feedback / feature request template?
Acquainto has a Product feedback / feature request template to start from. After you sign up, open Browse templates, pick Product feedback / feature request, and it lands in the editor as a draft you can change before anything is published.
This template is built for the job. It asks what the feedback is about (a bug, a feature request or general feedback), the details, how important it is and an optional email, and branches: a bug report is asked what the person was doing and whether it happens every time, a feature request what they are trying to get done and how they work around it today. Link it from a “Give feedback” button in your product and match its wording to your product’s.
Acquainto runs it as a short written conversation instead of a form. It:
- asks a follow-up when an answer is incomplete, and asks for clarification when one is vague;
- uses a structured choice where precision matters and open conversation where detail matters;
- shows the person every answer before it is sent, so they correct their own mistakes;
- hands back one clean value per question, delivered to your own systems by webhook.
The person answering needs no account, and nothing has to be scheduled. Start free trial, see how it works, or compare plans.