Erstelle in kürzester Zeit mit AI & ohne Technikkenntnisse starke Onboarding-Flows, NPS-Umfragen & Feature-Request-Formulare für dein SaaS-Produkt

Die klassische NPS-Frage am Tag 30 nach Signup ist gut, aber sie misst nur, wer noch da ist — nicht, warum die anderen weg sind. Eine zweite Messung im Onboarding, etwa nach dem ersten "Aha-Moment" (erstes erfolgreich erstelltes Projekt, erste Antwort gesammelt, erstes Team-Mitglied eingeladen), liefert deutlich aktionablere Insights. Die Frage muss dabei nicht "Empfehlen Sie uns weiter?" sein — eher "Wie war Ihr Setup-Erlebnis bisher?".

Das Timing entscheidet zwischen Goldgrube und Spam. Ein Modal, das beim ersten Login aufploppt, frustriert. Ein dezenter Banner, der nach der dritten Session erscheint, wird wahrgenommen. Eine Email-Befragung am Tag 14 hat eine bestimmte Antwortquote, eine In-App-Einblendung im selben Moment eine deutlich höhere — die Hürde "App verlassen" entfällt. Beide Wege haben ihre Berechtigung, je nach Nutzersegment.

Für die In-App-Einbettung bietet sich eine Web Component oder ein iFrame mit URL-Parametern an, die User-ID, Plan und Locale vorbefüllen. So muss der Nutzer nichts tippen, was Sie schon wissen, und die Antwort lässt sich serverseitig direkt mit dem User-Datensatz im Data Warehouse joinen — ohne Email als Krücken-Identifier.

Wenn ein Kunde im Billing-Portal auf "Subscription kündigen" klickt, ist es zu spät für eine Save-Aktion — meistens. Aber es ist genau der richtige Moment, um zu lernen, warum. Eine kurze Cancel-Survey mit zwei oder drei Fragen ("Was hat gefehlt?", "Wechseln Sie zu einem Konkurrenten?", "Würden wir Sie zurückgewinnen können mit X?") liefert Daten, die kein Kohort-Diagramm zeigen kann.

Die Pflichtfeld-Falle ist real. Wenn Sie die Survey vor die Kündigung schalten und Antworten erzwingen, fühlen sich Nutzer erpresst und schreiben Quatsch ("aaa", "no comment", "egal"). Die Survey muss skipbar sein, sonst sind die Daten Müll. Eine Conversion-Rate von 30 bis 50 Prozent ehrlich ausgefüllter Antworten ist realistisch und reicht völlig, um Muster zu sehen.

Routing nach Antwort macht den Unterschied. Wer "zu teuer" ankreuzt, sieht im nächsten Schritt ein Downgrade-Angebot statt Kündigung. Wer "Feature X fehlt" ankreuzt, landet auf einer Roadmap-Seite oder bekommt einen Calendly-Link für ein Customer-Success-Gespräch. Save-Rates zwischen 5 und 15 Prozent sind nicht ungewöhnlich, je nach Setup — und jede gerettete Subscription zahlt Cancel-Survey, Tooling und Engineering-Aufwand mehrfach zurück.

Feature-Wünsche kommen aus allen Richtungen — Sales, Support, Slack-DMs, Twitter, Intercom-Chats. Wer das nicht zentralisiert, baut am Ende Features für die lautesten Nutzer, nicht für die wertvollsten. Ein eigenes Feature-Request-Formular, eingebunden in der App und im Help-Center, macht aus Anekdoten eine Datenbasis.

Multi-Vote ist dabei wichtiger als Single-Vote. Wer sich entscheiden muss zwischen "Dark Mode" und "API-V2", verteilt seine drei Stimmen sinnvoller als jemand, der nur eine Stimme hat. Conditional Logic kann je nach Plan andere Vote-Gewichtung anbieten — Enterprise-Kunden mit höherem ARR bekommen vielleicht fünf Stimmen, Free-Nutzer eine. Das ist keine Demokratie, das ist Produktstrategie.

Die Priorisierung passiert nicht im Formular, sondern im Backend. Anzahl Votes mal Plan-Gewichtung mal "Effort vs. Impact"-Faktor ergibt eine Roadmap-Reihenfolge, die argumentierbar ist. Ein Webhook in Linear oder Jira erstellt automatisch ein Issue pro Request mit allen Vote-Daten als Kommentar. Dann ist die Diskussion im Produktteam nicht mehr "wer hat am lautesten geschrien", sondern "welcher Request hat 47 Votes von 12 Enterprise-Kunden".

Drei Wege führen ein Formular in eine SaaS-App: iFrame, Popup-SDK oder Web Component. Welcher der richtige ist, hängt vom Use-Case ab — eine pauschale Empfehlung gibt es nicht. Der iFrame ist der schnellste Weg: ein HTML-Tag im Marketing-Snippet, fertig. Vorteil ist die Isolation (keine CSS-Konflikte mit Ihrer App), Nachteil die fehlende native Integration und schwierige Höhen-Anpassung bei dynamischem Content.

Das Popup-SDK ist der richtige Weg für In-App-Befragungen, die nicht den ganzen Screen einnehmen sollen. Ein JavaScript-Snippet, ein Trigger-Event ("Nutzer hat dritte Session abgeschlossen"), und das Modal öffnet sich. URL-Parameter füllen User-ID, Plan und Locale vor — der Nutzer tippt nichts, was Sie schon wissen. Ideal für NPS-Pulse-Befragungen oder Feature-Discovery.

Die Web Component ist der schwerste, aber sauberste Weg. Sie verhält sich wie ein nativer HTML-Tag (`<questee-form id="...">`), respektiert Ihr CSS-System (Shadow DOM optional) und integriert sich in jedes Framework — React, Vue, Svelte, Angular. Für Komponenten, die Teil Ihrer App-UI sind (etwa eine Onboarding-Checkliste), ist das die richtige Wahl. Engineering-Aufwand höher, Pflegeaufwand langfristig niedriger.