SaaS Feedback Widget Microcopy: Examples for Every Field

A good SaaS feedback widget tells visitors what they can send, gives them one clear place to write it, and makes the next step obvious. Keep the form short: name the feedback types, use a plain-language prompt, and make clear that an email is only needed if they choose to request a reply.

Start with copy that sets expectations

Visitors should be able to tell, at a glance, what the widget is for and what to write. Avoid vague instructions such as “Send feedback” on their own. A little direction helps people distinguish a bug report from a feature idea or a question, without turning the form into a questionnaire.

Copy examples for each widget field

Form heading

Use a short heading that says what the visitor can do. For a general feedback widget, try “Share feedback” or “Tell us what you think”. If the widget is focused on a specific part of your SaaS, name it: “Help us improve the reports page”. Make sure the heading still fits if visitors can send issues, ideas and questions.

Supporting text

Use this line to explain the available choices and how much detail is useful. For example: “Choose Issue for something that is not working, Idea for a possible improvement, or Question if you need clarification. A short description is fine.” This gives visitors a cue for each type without asking them to fill in a long report.

Message-field label

Keep the label direct: “What would you like us to know?” or “Describe your feedback”. If you want bug reports to be easier to investigate, “What happened?” is a useful prompt, but it may feel less natural for questions and ideas. Choose wording that makes sense across the feedback types you have enabled.

Message placeholder

A placeholder can give one practical hint, but it should not repeat the whole supporting text. For a shared form, try: “What were you trying to do, and what happened?” It encourages useful detail for an issue while still allowing a visitor to describe an idea or question. Avoid wording that implies every visitor needs to provide technical details.

Submit button

Use a button label that describes the action: “Send feedback” or “Submit feedback”. “Send” is shorter, but may be less clear if the widget contains other actions. Avoid promising a reply with a label such as “Get help” unless the process actually guarantees support.

Success message

Confirm that the message was sent, without suggesting that the team will act on every request. For example:

• Heading: “Thanks for letting us know”

• Message: “Your feedback has been sent. If you asked for a reply, we have your email address.”

Only use the second sentence if your widget allows visitors to request a reply and provide an email address. Do not say “We’ll get back to you” unless you can reliably meet that expectation.

Make it easy to describe an Issue, Idea or Question

The category names do some of the work. Your supporting text can explain them in everyday language, while the message prompt invites a useful description. For example, visitors might write:

• Issue: “I tried to export the report, but the download did not start.”

• Idea: “Could I choose which columns appear in the export?”

• Question: “Does the monthly total include archived projects?”

These are examples of clear messages, not a script visitors should have to follow. Page and device context can help you understand where feedback came from, but it does not replace the visitor’s own description. If you need screenshots or more detail to investigate a particular issue, you may still need to ask for them separately.

Keep email optional unless a reply is needed

If you want to follow up, explain that visitors can request a reply and that they will need to provide an email address for that. For example: “Want a response? Request a reply and add your email. You can also send feedback without sharing contact details.” Keep this explanation close to the reply option so visitors can make an informed choice.

Do not make an email address sound compulsory if it is not. In Feedback Bubble, an email is optional for an ordinary submission. When reply requests are enabled, a visitor can request a reply and provide an address; the editor lets the owner turn that option on or off. The current wording controls include the form heading, supporting text, message-field label, placeholder, submit-button label and success message. See the Feedback Bubble customisation guide for the editor workflow.

Review the copy in the live widget

Read the form as if you were a first-time visitor. Check that the heading, supporting text and placeholder do not repeat one another; that Issue, Idea and Question are understandable; and that the button and success message describe what actually happens. If reply requests are enabled, confirm the email field is presented as optional and that the success message does not promise a response you cannot guarantee.

Use the editor’s live preview to check both the open and closed widget states, then review the wording on the website at desktop and mobile sizes. Copy can make the form clearer, but there is no single phrase that guarantees more submissions. Start with a clear version, then change it if visitors regularly misunderstand what to send.

For a practical next step, write one short instruction that fits your enabled feedback types, then test it in the widget preview before publishing.