Een feedbackboard voor AI-agents: laat je gebruikers de prompt schrijven

Om elf uur 's avonds schrijft een gebruiker je. "De exportknop doet niets in Safari."

Je weet wat er nu gebeurt, want het is al honderd keer gebeurd. Je leest het. Je begrijpt het. Dan open je een tracker en typ je het opnieuw, in je eigen woorden, met de bestandspaden, de stappen om het te reproduceren en de context die de gebruiker niet had. En later open je een terminal en typ je het een derde keer, als prompt.

Drie keer hetzelfde verzoek opschrijven. De eerste keer was gratis en kwam van degene die de bug daadwerkelijk tegenkwam. De andere twee keer zijn van jou.

Die tweede en derde keer vormen het deel van het werk dat door agents absurd is geworden.

Het laatste wat je nog met de hand typt

Codeeragents hebben een hoop typewerk weggenomen. De briefing hebben ze niet weggenomen. Iets moet de agent nog altijd vertellen wat er gebouwd moet worden, gedetailleerd genoeg dat hij niet gaat gokken, en dat iets is nog steeds een mens achter een toetsenbord die de woorden van anderen omzet in instructies.

Alleen is die omzetting vaak zinloos. Een goede bugmelding bevat al wat een agent nodig heeft: wat er werd verwacht, wat er gebeurde, op welke pagina, in welke browser. Een goed featureverzoek bevat de bedoeling en de reden al. Degene die het schreef zat dichter bij het probleem dan jij.

In plaats daarvan behandelen we die tekst als grondstof die opnieuw bewerkt moet worden, omdat de tool die hem verzamelde en de tool die het werk uitvoert nooit dezelfde tool waren. Feedback woont in het ene product, tickets in het tweede, en de agent draait in een terminal die van geen van beide weet heeft.

Haal die kloof weg en de herschrijfstap heeft nergens meer plaats om te gebeuren.

Wat een feedbackboard wordt zodra het bord kan uitvoeren

Een publieke backlog is een pagina die je gebruikers kunnen bereiken. Ze melden een bug, vragen een feature aan, stemmen op wat iemand anders heeft gevraagd, volgen een gesprek en zien een status veranderen. Tot zover is dit een feedbackboard, en daar bestaan goede van.

Het verschil zit in waar het ticket landt. Het landt niet in een feedbackproduct dat op een export staat te wachten. Het landt op het taakbord waar je agents al uit werken, als volwaardig ticket, naast de tickets die je zelf hebt geschreven.

Vanaf daar start het verplaatsen naar In Progress een agent wiens briefing het ticket is: de titel, de beschrijving in de eigen woorden van de melder, de pagina waarop hij zat, de browser die hij gebruikte en het gesprek dat je sindsdien met hem hebt gevoerd. Niemand heeft iets herschreven. De prompt is de melding.

Het interessante gevolg is niet snelheid. Het is dat degene die het probleem beschreef nu ook degene is die het werk heeft gespecificeerd, wat iedereen zegt te willen halen uit gebruikersfeedback en waar bijna niemand zijn werkwijze op inricht. Die omkering heeft een naam: een klantgestuurde backlog. De wachtrij is niet langer jouw gok over wat ertoe doet, maar een verslag van wat er daadwerkelijk gevraagd is.

Drie deuren, want mensen melden waar ze zijn

Een feedbackboard werkt alleen als melden minder moeite kost dan ergens anders klagen. Dat betekent dat je mensen opzoekt waar het probleem zich voordeed.

De publieke pagina is de voor de hand liggende deur: een URL die je deelt, met een lijst- of roadmapweergave, stemmen en een formulier. Dat werkt voor een product met gebruikers die hem bij hun favorieten zetten, en het levert meteen zichtbaar bewijs dat het werk vordert, wat meer waard is dan een statusmail die niemand leest.

De insluitbare widget is de tweede: een klein script op je eigen site dat ter plekke een formulier opent. De gebruiker verlaat de pagina met de bug niet, en dat is precies het moment waarop hij het meest bereid is die te beschrijven.

De Chrome-extensie is de derde, en die verandert het gedrag het sterkst. Je gebruiker selecteert de kapotte tekst op willekeurig welke pagina, klikt op de extensie, en het ticket wordt ingediend met de URL en de selectie er al aan vast. Wat jij ontvangt is niet "het werkt niet", het is een melding met coördinaten.

Voor een bureau is de derde deur meestal de klant zelf, en de modus klantportaal werkt alleen op uitnodiging: één bord per klant, niemand anders ziet het, geen extra SaaS-abonnement in de stack.

Routering, want "de juiste agent" is niet één agent

Een binnenkomend ticket is aan niemand geadresseerd. Dat is het praktische probleem van elke inbox: iemand moet beslissen wie het oppakt.

Tickets die van buiten binnenkomen worden gerouteerd naar de agent wiens specialisme erbij past, dus een kapotte lay-out gaat naar een frontendspecialist en een lekkende query naar een backendspecialist, zonder dat jij elke ochtend met de hand de wachtrij zit te triëren. Is er niets ingesteld, dan is de terugval bewust dom en voorspelbaar: de eerste ontwikkelagent in het project, nooit een marketing- of PM-rol die toevallig bovenaan de lijst staat.

Je kunt een ticket ook op een heel team van agents richten in plaats van op één agent, zodat een klantverzoek eerst een ontwikkelstap en dan een QA-stap doorloopt voordat het bij jou belandt.

Het deel dat iedereen vergeet: wat de melder terugziet

Feedback verzamelen is makkelijk. Het is de terugkoppeling waar producten mensen kwijtraken.

Gaat een ticket in ontwikkeling, dan hoort de auteur dat. Wordt het geprioriteerd, dan hoort hij dat. Besluit je het niet te doen, dan hoort hij dat ook, met de reden die je hebt opgeschreven, wat oneindig veel beter is dan stilte. En zodra de fix echt live gaat, krijgt hij een bericht dat dat zegt, gebundeld tot één melding per release in plaats van vijf losse mails voor vijf tickets.

Er is een kleiner detail dat meer uitmaakt dan het lijkt: de commit die een gebruikersticket afsluit noemt de melder bij voornaam, en die vermelding blijft staan tot in de publieke changelog. Wie zijn naam ziet hangen aan een opgeleverde wijziging, meldt de volgende bug ook. Dat is het hele retentiemechanisme, en het kost niets. Draai die lus een paar maanden en je krijgt feedbackgedreven ontwikkeling als waarneembaar feit in plaats van als slogan: de stemmen bepalen de volgorde, en de volgorde bepaalt de releases.

Komt een verzoek vaag binnen, dan zit ticketafbakening tussen de melding en het werk: een Product Manager-agent maakt van het wollige verzoek een mockup van je echte product met de wijziging erin, zodat je het idee op datzelfde ticket valideert voordat er één regel code is geschreven.

Waar de klassieke tools stoppen

Dit is geen sneer naar de gevestigde namen. Canny, Featurebase, Fider en UserVoice doen verzamelen, ontdubbelen en rangschikken goed, en ze hebben jarenlang geschaafd aan precies de onderdelen die er voor productteams toe doen. Ze stoppen op hetzelfde punt, om dezelfde structurele reden: ze zijn gebouwd voor organisaties waar engineering een andere afdeling is, alleen bereikbaar via een export.

De laatste regel geeft de doorslag. In een groot team is het omzetten van een verzoek in een specificatie een echt vak met echte waarde, en is de export niet het knelpunt. In een team van één tot vijf mensen dat met codeeragents oplevert, is dat herschrijven juist wel het knelpunt, en is het puur verlies.

Wat dit niet oplost

Een feedbackboard dat aan agents gekoppeld is, is geen automatische piloot, en het als zodanig behandelen levert precies op wat je zou verwachten.

Slechte tickets leveren nog steeds slecht werk op. Een melding van één regel zonder pad om het te reproduceren geeft een agent niets om mee te werken, en hij doet dan vol overtuiging iets verkeerds. Het bord kan alleen doorgeven wat er is opgeschreven.

Er wordt niets vanzelf gemerget. Een agent levert een branch en een diff op, en elke regel die je al had over het beoordelen van agentwerk blijft gelden, zeker voor alles wat authenticatie, betalingen of data raakt. Een ticket van een vreemde is geen reden om die lat te verlagen. Het is een reden om hem te verhogen.

En volume is een reëel gegeven. Een publiek bord dat aanslaat wordt rumoerig, en dat is een luxeprobleem met een echte prijs. Duplicaten worden bij het indienen gemarkeerd, stemmen scheiden wat één iemand wilde van wat veertig mensen wilden, en een ticket sluiten met een opgeschreven reden gaat sneller dan het laten wegrotten. Maar iemand leest die inbox nog steeds.

Het opzetten

Open de backlog van een project, klik op Public backlog, kies een URL en een zichtbaarheidsmodus. Dat is de hele opzet, en op dat moment staat de pagina live.

Wat je daarna doet telt zwaarder dan de opzet. Zet de link waar je gebruikers al zijn: in de app, in je supportantwoorden, onderaan je release notes. Een feedbackboard waarvan niemand weet verzamelt niets, en het faalscenario van deze feature is niet technisch: de link wordt gewoon nooit gedeeld.

AgentsRoom is het commandocentrum waarop dit draait: een taakbord waar een kaart een draaiende agent wordt, een publieke of private feedbackpagina die erop is aangesloten, een insluitbare widget, een Chrome-extensie, en klantmeldingen die afgaan zodra het werk echt live staat. Het werkt met Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe en Kimi Code.

Download AgentsRoom en publiceer je eerste bord.

Veelgestelde vragen

Wat is een feedbackboard voor AI-agents?

Een publieke pagina waar gebruikers bugs melden en features aanvragen, gekoppeld aan hetzelfde taakbord waar je codeeragents uit werken. Het verschil met een klassieke feedbacktool zit in de laatste stap: in plaats van het verzoek te exporteren naar een tracker en het als prompt te herschrijven, wordt het ticket zelf de briefing van de agent, in de woorden van degene die het meldde.

Kan een ticket van een gebruiker echt uit zichzelf een AI-agent starten?

Starten blijft een bewuste handeling: iemand verplaatst het ticket naar In Progress, en de agent start op met het ticket als prompt. Wat wel automatisch gaat is de routering, die een binnenkomend ticket naar de agent stuurt wiens specialisme erbij past. Alles wat een vreemde schrijft volautomatisch laten uitvoeren is geen feature, dat is een beveiligingslek.

Waarin verschilt dit van Canny, Featurebase, Fider of UserVoice?

Die zijn uitstekend in het verzamelen, ontdubbelen en rangschikken van vraag, en ze stoppen allemaal op hetzelfde punt: je krijgt een geprioriteerde lijst, en een mens moet elke regel alsnog omzetten in werk. Ze hebben geen uitvoeringslaag omdat ze gebouwd zijn voor productteams wier engineers ergens anders zitten. De inzet is hier precies omgekeerd: het oppervlak waarop je verzamelt en het oppervlak waarop je uitvoert zijn hetzelfde object.

Moet je je roadmap openbaar maken om dit te gebruiken?

Nee. Publiek, verborgen en alleen op uitnodiging zijn drie aparte modi. Een bureau dat één bord per klant draait, gebruikt alleen op uitnodiging en geen enkele zoekmachine krijgt het ooit te zien. Een solo-ontwikkelaar die verzoeken en stemmen van zijn gebruikers wil, kiest publiek. Het uitvoerende deel werkt in alle drie hetzelfde.

Wat voorkomt dat een publiek bord volloopt met ruis?

Niets houdt de ruis tegen, en doen alsof van wel zou oneerlijk zijn. Wat het bord verandert is wat het kost om ermee om te gaan: bijna-duplicaten worden bij het indienen gemarkeerd, stemmen laten zien wat er werkelijk gevraagd wordt, en een ticket dat je niet gaat doen sluit je met een reden die de melder bereikt. De tickets die je wel houdt, komen binnen met de context die een vreemde al voor je had opgeschreven.