Surveys and NPS

Structured questions, versioned so that editing one does not corrupt results you already have.

Collection → Surveys → New survey.

Types

Type	Asks
NPS	"How likely are you to recommend us?" 0–10
CSAT	Satisfaction
CES	Effort — "how easy was it?"
PMF	Product/market fit — "how would you feel if you could no longer use this?"
Custom	Your own questions

Each type starts from a preset you can edit. The presets exist so you do not have to invent the wording of a standard instrument, and so the aggregates mean what the name implies.

Question types

Type	Renders as
score	A numbered row, 0–10
likert	A 1–5 agreement scale
select	Single choice from options
text	Free text

Versioning, and why it matters

A survey has versions. Publishing changes creates a new version; answers are recorded against the version the person actually saw.

This is the part that saves you later

Change question 3 halfway through a campaign without versioning, and your average for question 3 becomes a number describing two different questions. Here the old answers stay attached to the old wording, so every aggregate keeps meaning something. Results are reported per version.

The version is pinned in the page and echoed back on submit, so publishing an edit while somebody is mid-answer cannot swap the questions under them.

Draft → live → archived. Only a live survey with a published version is served to visitors; a widget pointing at an archived survey renders nothing rather than something stale.

Where they run

• A hosted survey page, at its own URL.
• A collect_survey widget — a launcher on your own site.
• An nps_popover widget — the one-question version, for a corner of your app.

Results

The results view reports per version: response counts, the NPS breakdown into promoters, passives and detractors, and free-text answers in full.

A low NPS score can fire the nps.low_score webhook, which is the useful one to wire up — it is the response you want somebody to see today, not at the end of the month.