Collect feedback in minutes

Putting a feedback board up genuinely takes five minutes. You will spend longer choosing a favicon. So this is not really an article about the five minutes — it is about the four decisions inside them that determine whether the board is still useful in six months, or a graveyard of eleven requests from launch week that you quietly unlink from the footer.

Decide what you are asking for

The single biggest cause of a dead board is a blank box labelled "Feedback". It asks people to do your categorisation for you, and the result is a stream in which a crash report and a colour-scheme opinion sit at the same weight.

Start with categories instead. Three is plenty:

• Feature request — the thing they wish existed
• Bug — the thing that is broken
• Improvement — the thing that exists but annoys them

New FeedFast projects are seeded with exactly those, and one is marked as the default in the submit form. You can rename them, colour them, reorder them, or add your own — Integrations and Docs are common fourth choices. On the free plan you get three categories; Pro removes the cap.

The categories are not admin: they are the question. "Report a bug" and "Request a feature" produce different writing from the same person.

Do not make anyone sign up

Every account you require costs you most of the feedback you would have got. The person hitting a bug at 11pm is not creating a password to tell you about it.

On a FeedFast board, submitting and voting need no account. A vote is tied to a hashed key — the email if they gave one, otherwise a hash of IP and user agent — so you get one vote per person without a login and without storing anything you would have to explain in a privacy policy. Spam is handled by a honeypot field and a rate limit rather than a captcha, which is another thing your users do not have to do.

Put the box where the problem happens

A feedback page you have to navigate to collects feedback from people who were already going to write to you. The interesting reports come from people who hit something mid-task and would not have crossed the room to tell you.

So put the trigger in the product. One script tag, then any element becomes a trigger:

<script src="https://feedfa.st/embed.js" data-project="your-project" defer></script>

<button data-feedfast="feedback">Send feedback</button>

That is the whole integration — the full set of attributes is in the docs. The modal renders in a shadow root, so your CSS cannot reach into it and its CSS cannot leak onto your page. If the payload never arrives, the button simply does nothing — your layout does not move and nothing lands in the console.

You can pre-fill it for context, which is worth doing on a page where you already know the likely subject:

Feedfast.openFeedback({ title: "Import failed" });

Pass a categoryId alongside it to preselect a category — the ids come from the project's widget payload, so a bug-report button in your error state can open straight into the right one.

The first week is triage, not silence

Here is the failure mode nobody plans for. The board goes up, twelve requests arrive in a fortnight, none of them get a response, and submission thirteen never comes. People are quite good at working out whether writing to you achieves anything.

You do not need to build what they asked for. You need to answer:

• Move it to Planned if you intend to, In progress when you start
• Move it to Declined with one sentence of reason if you will not
• Leave it Open if you genuinely have not decided

The status is the answer. A request sitting at Planned tells the eleven people who voted for it more than a reply saying "thanks for the feedback" ever will, and it stops them emailing you to ask.

Then close the loop, once

The mechanism that keeps a board alive is short: someone asks, you ship, they find out. It is worth seeing the whole loop drawn out.

When a post is Done, a Create changelog entry button appears on it. One click opens the editor with the title, the body and a tag mapped from the category already filled in — Bug becomes Fixed, Improvement becomes Improved. Publishing puts the entry on your public changelog, in your RSS feed, and in the "What's new" widget with an unread dot.

Then reply on the post itself. Owner replies carry a badge, so it is visible that the answer came from you rather than another user. If you drive FeedFast from the API or an AI agent, resolve_feedback does all three in one call: marks it Done, publishes the entry, and posts a reply that links to it.

That last part is the one that matters. The person who asked gets told, in public, that asking worked. Everyone else reading the board sees that asking works. That is the difference between a board that is busy in month six and one that is a museum.

The five minutes, then

1. Create a project and keep the three seeded categories
2. Drop the script tag and one data-feedfast="feedback" button into your app
3. Share the board link once — in-app, in your newsletter, in the footer

Then spend ten minutes a week on statuses. That is the actual job.

If you want the longer version of where to put the button and why email is the wrong intake channel, that is its own article. And if you would rather look at a working board than read about one, here is a live hub.