Feedback widget copy: 23 neutral prompts and action labels
Copy-ready prompts and action labels for docs, pricing, onboarding, and feature screens. 23 neutral options in a CSV you can paste into any widget.
A feedback widget can load perfectly and still collect unusable answers, because the wording decides what a prompt can collect. The embed works. The placement is right. Then the prompt reads "Tell us how we're doing!" and the button says "Submit," and a thumbs-down could mean the page is broken or that the reader is annoyed about something else. The words are the part you control most easily.
This page is a library of prompts and action labels you can paste into a widget today. Every prompt is neutral. None of them push an answer, and none of the labels use emotional pressure to get a click.
The library covers four screen types: documentation, pricing, onboarding, and feature screens. There are 23 combinations. Each one pairs a prompt (the question the reader sees) with an action label (the button that sends the answer) and an optional follow-up.
If you want the whole set as a file, Download widget copy library (CSV).
What neutral microcopy means here
A neutral prompt asks without steering. It does not tell the reader how to feel and it does not reward one answer over another.
Three rules shape every entry in this library:
- Ask about the page, not the person. "Was this page helpful?" asks about the page. "Are you happy with FeedValue?" asks the reader to rate you, which invites a polite answer instead of a true one.
- Use plain action labels. "Send" and "Submit" describe what the button does. "Don't miss your chance!" and "Yes, help me improve!" describe a feeling. Do not use pressure to raise a click count.
- Make the follow-up optional. A one-click answer is valuable on its own. If you show a follow-up question, let the reader skip it.
Neutral copy can make a response easier to interpret. A reader who taps "No" on "Was this page helpful?" is answering a question about the page. A reader who taps "No" on a leading prompt may be reacting to the tone instead.
How to use the library
Each entry has three parts:
- Prompt — the question shown inside the widget.
- Action label — the button text. For binary prompts this is a pair, such as "Yes / No".
- Optional follow-up — a short second question. Show it after the first answer, and only when it adds a detail you can act on.
Match the prompt to the failure you expect on that screen. Documentation pages often fail on clarity, pricing pages on comparison, onboarding on drop-off, and feature screens on breakage or discoverability. Pick the row that names the likely problem.
Documentation screens
Documentation feedback is a signal about the page, so keep the prompt tied to the reader's task.
| Prompt | Action label | Optional follow-up | Use when |
|---|---|---|---|
| Was this page helpful? | Yes / No | What were you looking for? | Baseline reaction on every doc page. Keep the follow-up short and optional. |
| Did this page answer your question? | Yes / Partly / No | Which step was unclear? | Use when partial success matters. "Partly" separates an unclear page from a missing one. |
| Did you find what you needed? | Found it / Not yet | What were you trying to do? | Use on search or index pages where navigation, not wording, is the likely problem. |
| How clear were these instructions? | Clear / Confusing | Which section lost you? | Use on step-by-step guides where clarity is the failure mode. |
| Is anything missing from this page? | Send note | — | Use on reference pages where gaps, not errors, are the common complaint. |
| Was a code sample needed here? | Yes / No | Which language? | Use on API and SDK pages when examples are the likely gap. |
Pricing screens
Pricing feedback should not ask the reader to negotiate. Ask about the information, not the price you wish they would accept.
| Prompt | Action label | Optional follow-up | Use when |
|---|---|---|---|
| Was the pricing information clear? | Yes / No | What was unclear? | Use on the pricing page itself. Neutral wording avoids steering the answer. |
| Did you find the plan details you needed? | Found it / Not yet | Which plan were you checking? | Use when plan detail, not price, is the friction. |
| Is there a plan detail we should add? | Send note | — | Use where comparison tables leave gaps. |
| Did you need help choosing a plan? | Yes / No | What were you comparing? | Use to route undecided visitors to a human, not to push a plan. |
| Was the billing FAQ useful? | Helpful / Not helpful | — | Use on help-center pricing answers to find the weak ones. |
Onboarding screens
Onboarding feedback should catch the step that blocks a new user, so keep each prompt next to the step it judges.
| Prompt | Action label | Optional follow-up | Use when |
|---|---|---|---|
| How did setup go? | Smooth / Rough | Where did you get stuck? | Use right after the first setup step completes. |
| Was anything unclear in these steps? | Send note | — | Use on each onboarding guide page. |
| Did you finish the setup steps? | Yes / Not yet | What stopped you? | Use before the first success screen to catch drop-off. |
| Was a step missing for your stack? | Send note | Which stack? | Use on framework-specific setup pages. |
| Did you need a credential you did not have? | Yes / No | — | Use where an API key or account step can block setup. |
| Would a checklist have helped here? | Yes / No | — | Use to test whether a download would reduce repeated questions. |
Feature screens
Feature feedback covers two different questions: does it work, and can people find it. Use different prompts for each.
| Prompt | Action label | Optional follow-up | Use when |
|---|---|---|---|
| Is this feature working as expected? | Yes / No | What happened instead? | Use on new or changed feature screens to catch breakage. |
| Was this release note useful? | Useful / Not useful | — | Use under changelog entries. |
| What would make this feature better? | Send idea | — | Use on established feature pages to collect requests. |
| Did you find this feature where you expected it? | Yes / No | — | Use to test information architecture, not the feature itself. |
| Is anything about this feature unclear? | Send note | — | Use where labels or state are ambiguous. |
| Which part of this feature do you use most? | Send note | — | Use to guide what you invest in next. |
Optional follow-up prompts
These work as second questions under any of the prompts above. Show them after the first answer and let the reader skip them.
- What were you trying to do?
- What happened instead?
- Which step was unclear?
- What would have helped?
- Anything else we should know?
Keep the follow-up to one question. A second page of fields turns a quick tap into a form, and forms get closed.
Good versus weak rewrites
The difference is usually one word. These rewrites keep the same intent and drop the pressure.
| Weak copy | Neutral rewrite | Why the rewrite is better |
|---|---|---|
| "Loving FeedValue? Tell us!" | "Was this page helpful?" | Asks about the page instead of demanding praise. |
| "Rate your experience!" | "How did setup go?" | Names the moment, so the answer is specific. |
| "Yes, improve my docs!" | "Send" | The label describes the action, not a promise. |
| "Don't miss the chance to shape our roadmap!" | "What would make this feature better?" | Drops urgency and asks one clear question. |
| "Submit!" next to "You're unhappy, right?" | "No / Yes" paired with "Is this feature working as expected?" | Removes the leading frame. |
| "Help us help you!" | "Was anything unclear in these steps?" | Says what is being asked, not what the reader owes you. |
Download the library
The full set of 23 prompts and labels is in one file: Download widget copy library (CSV). It has columns for the screen, the prompt, the action label, the optional follow-up, and a short note on when to use each row.
If you would rather start from an existing checklist, the feedback checklist template covers what to look at once responses arrive. The feature request template covers the prompt side when a single message needs more structure than a widget prompt.
Where these responses land
The current documentation says FeedValue stores each response with an AI category, an AI sentiment, and a status, and that a response can carry a source page, browser and device details, and any custom data fields you configure. The documented categories are bug_report, feature_request, praise, complaint, question, and general. The documented sentiments are positive, neutral, and negative. The documented workflow statuses are new, read, resolved, and archived. The docs also describe filtering responses by app, widget, date range, and status, and updating or deleting several at once. See the feedback documentation for the current list. These descriptions come from the docs and are not behavior we have tested. A given response may not have every optional field populated.
Turn prompts into a process
Good prompts give you clean signal. They do not tell you what to do with it. Once responses arrive, you still need to categorize them, decide what to build, and reply to the people who wrote in. The companion guide on closing the feedback loop covers that side: close the feedback loop.
Collect the answers to these prompts in one place. The current documentation describes FeedValue as a dashboard that lists widget responses from your apps, with filters and a status on each. Start your free trial.
Related
- Feedback checklist template — what to look at once responses arrive.
- Feature request template — the prompt side when a message needs more structure.
- Close the feedback loop — categorize, decide, and reply to the responses.
Or automate it with FeedValue
Embed feedback widgets directly in your app. AI categorizes responses and routes them to the right team.