Create powerful onboarding flows, NPS surveys & feature request forms for your SaaS product in no time — with AI, no tech skills needed

The classic NPS question on day 30 after signup is fine but measures only who is still there — not why the others left. A second measurement during onboarding, say after the first "aha moment" (first project created, first response collected, first team member invited), delivers far more actionable insights. The question does not need to be "would you recommend us?" — more like "how was your setup experience so far?".

Timing decides between gold mine and spam. A modal popping up at first login frustrates. A subtle banner appearing after the third session gets noticed. An email survey on day 14 has a certain response rate, an in-app prompt at the same moment a noticeably higher one — the hurdle "leave the app" disappears. Both paths have merit depending on user segment.

For in-app embedding a Web Component or an iFrame with URL parameters that prefill user ID, plan and locale fits well. The user does not have to type what you already know, and the answer can be joined server-side directly with the user record in your data warehouse — without email as a crutch identifier.

When a customer clicks "cancel subscription" in the billing portal, it is mostly too late for a save action. But it is exactly the right moment to learn why. A short cancel survey with two or three questions ("what was missing?", "are you switching to a competitor?", "would we win you back with X?") delivers data no cohort chart can show.

The mandatory-field trap is real. If you place the survey before cancellation and force answers, users feel coerced and write nonsense ("aaa", "no comment", "whatever"). The survey must be skippable, otherwise the data is trash. A conversion rate of 30 to 50 percent honestly filled answers is realistic and entirely enough to see patterns.

Routing by answer makes the difference. Anyone ticking "too expensive" sees a downgrade offer instead of cancellation in the next step. Anyone ticking "feature X missing" lands on a roadmap page or receives a Calendly link for a customer success call. Save rates between 5 and 15 percent are not unusual depending on setup — and every saved subscription pays back cancel survey, tooling and engineering effort many times over.

Feature requests arrive from all directions — sales, support, Slack DMs, Twitter, Intercom chats. Anyone not centralising this ends up building for the loudest users, not the most valuable ones. A dedicated feature request form, embedded in the app and the help centre, turns anecdotes into a data foundation.

Multi-vote matters more than single-vote. Anyone forced to choose between "dark mode" and "API v2" distributes their three votes more meaningfully than someone with just one vote. Conditional logic can offer different vote weighting per plan — enterprise customers with higher ARR perhaps get five votes, free users get one. That is not democracy, it is product strategy.

Prioritisation happens not in the form but in the backend. Vote count times plan weighting times "effort vs. impact" factor yields a roadmap order that is defensible. A webhook into Linear or Jira automatically creates an issue per request with all vote data as a comment. Then the product team discussion is no longer "who shouted loudest" but "which request has 47 votes from 12 enterprise customers".

Three paths lead a form into a SaaS app: iFrame, popup SDK or Web Component. Which one is right depends on the use case — there is no blanket recommendation. The iFrame is the fastest path: one HTML tag in the marketing snippet, done. Advantage is isolation (no CSS conflicts with your app), disadvantage is missing native integration and tricky height adjustment with dynamic content.

The popup SDK is the right path for in-app surveys that should not take the entire screen. A JavaScript snippet, a trigger event ("user completed third session"), and the modal opens. URL parameters prefill user ID, plan and locale — the user types nothing you already know. Ideal for NPS pulse surveys or feature discovery.

The Web Component is the hardest but cleanest path. It behaves like a native HTML tag (`<questee-form id="...">`), respects your CSS system (Shadow DOM optional) and integrates with any framework — React, Vue, Svelte, Angular. For components that are part of your app UI (such as an onboarding checklist) this is the right choice. Engineering effort higher, maintenance effort lower long-term.