🗳️ Surveys

Spec map

Home: All V2 Specs · Foundation: Data System (UVP) Mode(s): Relationship Mode Related specs: Data System (UVP), Forms, Polling Engine

🎯 Goals

What This Product Is

Provide a lightweight, campaign-deployed form for group-level intelligence that funnels users toward the Polling Engine. Mode Architecture
Confine Surveys to Relationship Mode alongside Forms, distinct from Campaign Mode Polls. The Defining Distinction: Forms vs. Surveys vs. Polls
Clearly differentiate Forms, Surveys, and Polls by purpose, audience, rigor, and output. The Core Architectural Idea: A Survey Is a Deployed Form
Build Surveys as a Form plus deployment plan, aggregate results, and identity modes on shared infrastructure. What Surveys Deliberately Are NOT
Exclude all Polling Engine rigor capabilities from Surveys to preserve the upgrade funnel. The Deployment Plan — What Makes a Survey a Survey
Define audience, channel, schedule, close conditions, reminders, and anti-abuse that turn a Form into a bounded Survey. The Identity Model — Three Modes
Offer Identified, Anonymous, and Pseudonymous identity behaviors locked at go-live. The Three-Tab UI
Provide Surveys, Canvas, and an aggregate-first Results tab using the shared Forms pattern. The Upgrade Funnel — Surveys to Polls
Surface contextual upsells that route users to the Polling Engine when rigor is needed. Question Types & Builder
Reuse Forms field types plus aggregate-friendly Survey-specific additions. UVP Provenance & Survey-Specific Metadata
Write Survey responses to UVPs with full provenance plus invitation and send/response history. Lifecycle & State Machine
Govern Surveys through a Draft-Scheduled-Live-Closed-Archived state machine that locks the instrument once live. Anonymous Mode & The Data Trust Boundary
Deliver architecturally-enforced honest anonymity for sensitive Surveys. Branding, Templates, Distribution
Provide branded, templated, tokenized, and public distribution mechanics for Surveys. Permissions, V1/V2 Scope
Gate Survey authoring and deployment to Admin/Manager and define phased V1/V1.5/V2 scope.

Mode: Relationship Mode Status: Conceptual Spec — V1 Scope Definition Companion specs: vrm-forms (shared builder, field library, submission pipeline), vrm-polling-engine (the rigorous cousin in Campaign Mode), vrm-data-system (UVP, field system, exposure controls), politogy-vrm-brand

1. What This Product Is

A Survey is a campaign-deployed form. It uses the entire Forms builder, the entire Field Library, the entire submission pipeline, and the entire UVP write infrastructure. What makes it a Survey rather than a Form is how it is deployed and how its results are presented.

Where a Form is a static capture surface — a URL that lives on a website and accepts submissions from individuals over time — a Survey is a bounded, audience-targeted instrument. It has a defined audience, a defined deployment channel, an opening and a closing, and an aggregate-first results view.

Product thesis: Campaigns and organizations need a way to ask their list — or the public — a few questions and see what the group thinks, without paying for a real poll. Surveys give them that capability for free or near-free, with results presented as group-level intelligence. Surveys also serve a second strategic purpose: they are the upgrade funnel into the Polling Engine. Every time a user runs a Survey and gets back a hint of a question the data can’t actually answer, the system points them to the Polling Engine where it can.

Surveys are deliberately not rigorous. That is a feature. They are the lightweight tool for low-stakes intelligence. The Polling Engine is the heavyweight tool for high-stakes intelligence. Honoring this distinction is what keeps the product lineup coherent.

2. Mode Architecture

Surveys live exclusively inside Relationship Mode, alongside Forms. They share the Forms builder infrastructure.

Product	Mode	Audience	Methodology	Scoring	Output
Forms	Relationship	Public, ongoing	None	None	Per-submission UVP captures
Surveys	Relationship	Targeted (list-based) OR public, bounded	None	None	Aggregate roll-up + per-response data
Polls	Campaign	Voter-file sample	Methodology Agent (PhD pollster)	Four-dimensional (Support/Confidence/Intensity/Volatility)	Strategic memo + Heavy-Prescription Next Moves

Petition Mode auto-grants Campaign Mode, so a Petition subscriber gets Polls. Surveys are available in any Relationship Mode account.

3. The Defining Distinction: Forms vs. Surveys vs. Polls

This must be internalized by the entire engineering team. The three products look similar on a screenshot and are completely different in purpose.

	Forms	Surveys	Polls
Question being answered	”Can I capture this individual’s info?"	"What does this group think?"	"What does the electorate think, with statistical defensibility?”
Audience	Anyone, anytime	Defined group, bounded window	Methodologically sampled
Identity model	Always identified	Identified, anonymous, or pseudonymous (configurable)	Tokenized respondent linkage
Deployment	Static URL / embed	Campaign with channel + schedule + close	Methodological fielding plan
Default results view	Per-submission table	Aggregate roll-up	Strategic memo with finding-strength tiers
Methodology validation	None	None	Required (Methodology Agent push-back)
Scoring	None	None	Four-dimensional, per-issue
Output	UVP captures	Aggregate intelligence + UVP captures	Scored UVPs + segments + lane assignments + Next Moves
Pricing tier	Included	Included	Premium / Enterprise

The structural relationship: Forms feed Surveys feed Polls, all into the same UVP. A new contact comes in through a Form. Three months later they get invited to a Survey. Six months later, when the campaign has resources, that contact (now a known voter) becomes part of a Poll sample.

4. The Core Architectural Idea: A Survey Is a Deployed Form

A Survey is not a parallel product. It is a Form with additional deployment configuration and a different results view. This means:

Same builder. Canvas tab, frames, drag-and-drop, field library, field types — all identical to Forms.
Same fields. Global fields and custom fields from the account’s Field Library. Custom fields created in a Survey join the same account namespace as custom fields created in a Form.
Same submission pipeline. Identity match → write to UVP → tag → notify. Same priority rules. Same provenance.
Same field deletion rules. A custom field with response data cannot be deleted, whether the data came from a Form or a Survey.
Different deployment. Surveys have a Deployment Plan that Forms do not have.
Different results presentation. Surveys default to aggregate roll-up; Forms default to submission list.
Different lifecycle. Surveys close on a date or sample target; Forms run indefinitely until paused or archived.

This is the engineering implication: Surveys are not a from-scratch build. The Forms codebase ships first; Surveys layer on top with three additions — the Deployment Plan, the Aggregate Results view, and the Anonymous mode toggle.

5. What Surveys Deliberately Are NOT

To prevent scope creep into the Polling Engine’s territory, this list is enumerated explicitly.

Surveys do not offer:

Methodological validation. No Methodology Agent push-back. Users can write questions however they want, in whatever order, with whatever leading language, and the system will not push back. Garbage-in is permitted.
Representativeness claims. A Survey result never says “X% of voters believe Y.” It says “X% of respondents to this Survey answered Y.” The language is locked at the platform level.
Sample quality assessment. No Fielding Scorecard. No finding-strength tiers (Strong / Directional / Descriptive / Inconclusive). Results are presented as they are.
Four-dimensional scoring. No Support/Confidence/Intensity/Volatility per respondent. No latent state tags. No classifications.
Strategic memo generation. No AI Strategic Analyst output. Results stand on their own as charts and counts.
Message lane assignment. No REINFORCE/PERSUADE/MOBILIZE/INOCULATE/ENGAGE lane mapping per segment.
Heavy-Prescription Next Moves. No autonomous follow-up poll generation.
Cross-account Aggregate Intelligence products surfaced to the customer. Survey responses still feed Politogy’s Aggregate Intelligence layer (as does all data in VRM), but the customer-tier UI does not expose cross-account propensity products from Survey data the way Enterprise Polls do.

Why these absences matter. Every one of these capabilities is part of the Polling Engine’s value proposition. Replicating any of them in Surveys collapses the upgrade funnel. The Polling Engine is what a campaign pays for when the stakes are real. Surveys are the lightweight tool that proves the platform has more to offer.

6. The Deployment Plan — What Makes a Survey a Survey

The Deployment Plan is the configuration block that distinguishes a Survey from a Form. It lives in the Canvas tab as a new Frame, replacing the static “Publish & Distribute” frame from Forms.

6.1 Audience

Three audience modes, mutually exclusive at deployment time but switchable while in Draft.

Audience Mode	Who Receives	Identity	Typical Use
Targeted Invite	Specific contact list / segment / tag selection from the account’s existing UVPs	Identified (tokenized link links to UVP)	Member feedback, issue testing on supporters
Public Distribution	Anyone with the link / embed / QR	Identified if Survey collects identity fields; otherwise pseudonymous	Issue surveys distributed via social, embedded on website
Hybrid	Both — invited contacts get tokenized links, public link is also live	Mixed	Maximizing reach while still tracking known contacts

In Targeted Invite mode, the system pre-fills known field values for the respondent (name, email, phone) and the response is automatically attached to their UVP, even if the respondent doesn’t fill in identifying fields. This is the core advantage of the invited channel — known recipient, accurate attribution.

6.2 Channel

How the Survey is delivered. V1 supports:

Email — sent through the VRM email engine (or integrated provider in V2)
SMS — short message with tokenized link (requires Phone consent + TCPA, V1.5)
Embed — same iframe / JS embed as Forms
Public Link — hosted page on surveys.politogyvrm.com/<account>/<slug>
QR Code — for offline / event distribution

A single Survey can be deployed across multiple channels simultaneously. Response source is recorded per submission.

6.3 Schedule & Close Conditions

A Survey is not perpetual. It has a defined window.

Open conditions:

Immediate — opens as soon as deployed
Scheduled — opens at a future date/time

Close conditions (set at least one; system enforces whichever triggers first):

Close date — explicit calendar close
Response target — close when N responses received
Manual close — keeps open until user clicks Close (allowed, but at least one of the above is strongly encouraged)

Once a Survey is Closed, it cannot be re-opened (it can be cloned into a new Survey with the same questions and a new deployment plan). This is intentional. A Survey is a moment-in-time snapshot. Re-opening contaminates the analytic baseline.

6.4 Reminders & Re-invites (Targeted Invite mode)

For Targeted Invite Surveys, the system supports:

Reminder schedule — send N reminders at configurable intervals to non-respondents (V1: up to 2 reminders)
Re-invite on no response — single one-click action to re-send the initial invite to all non-respondents
Stop on response — invited contacts who have responded never get a reminder

Reminders use the same channel as the initial invite. Per-contact send history is recorded on the UVP (see Section 11).

6.5 Anti-Abuse for Public Distribution

When a Survey includes Public Distribution:

CAPTCHA on by default (Forms-style)
Honeypot on by default
Rate limiting on by default
One response per session/IP by default (configurable; relevant for Public Surveys where you want one response per person, not aggregated household submissions)
Geo restrictions optional

Targeted Invite mode does not need this layer because the tokenized link is its own anti-abuse mechanism (one token per contact, one response per token).

7. The Identity Model — Three Modes

A Survey can be configured for one of three identity behaviors. This is a Survey-level setting, locked at deployment time.

7.1 Identified

Behaves exactly like a Form.
Submissions link to UVPs via identity matching (same priority chain as Forms).
Public submissions can create Relationship-Sourced UVPs.
Invited submissions auto-link via token, no matching needed.
Default mode.

7.2 Anonymous

No identity capture. Identity fields are excluded from the canvas with a warning if the user tries to add them.
For invited Surveys: the token is consumed (so we know the contact responded) but the response is NOT attached to their UVP. The fact of response is recorded; the content of response is not linkable to the individual.
For public Surveys: pure aggregate data, no UVP creation.
Politogy still receives the data for Aggregate Intelligence (this is disclosed in the platform Terms; anonymized data may be aggregated commercially).
Used for: sensitive issue testing within a contact list (“what do our supporters secretly think about Issue X?”), public sentiment surveys where attribution is not the goal.

7.3 Pseudonymous

Identity fields are optional rather than required.
Respondents may or may not provide identity. If they do, the response writes to a UVP (existing or new). If they don’t, the response is stored with submission-level provenance only.
Useful for: public issue surveys where contact conversion is a bonus but not required.

The identity mode is immutable once Live. Changing it would corrupt the analytic baseline.

8. The Three-Tab UI

Surveys use the same three-tab pattern as Forms, with the third tab purposefully different.

8.1 Tab 1 — Surveys (Live, Scheduled, Closed, Draft)

Default landing tab. Four sections, stacked:

Live Surveys — currently accepting responses. Row shows: name, deployment channels, audience size, response count, response rate, days remaining, close condition, action menu.
Scheduled Surveys — deployed but not yet open. Row shows: name, scheduled open date, audience size, action menu.
Closed Surveys — completed. Row shows: name, close date, total responses, response rate, action menu (View Results, Clone, Archive, Export).
Draft Surveys — under construction. Row shows: name, last edited, completeness indicator, action menu.

Clicking any row opens the Survey’s detail view. For Live/Closed, the default is the Results view (aggregate). For Draft/Scheduled, the default is the Canvas tab.

8.2 Tab 2 — Canvas (Builder)

Identical to the Forms Canvas, with two changes:

Modified frames:

Frame E — Deployment Plan (replaces Forms’ “Publish & Distribute” frame): Audience, Channel, Schedule, Close Conditions, Reminders, Identity Mode. This is the survey-specific configuration block.

Inherited frames (identical to Forms):

Frame A — Survey Settings (name, description, tags)
Frame B — Field Library (Global + Custom + Add Custom Field)
Frame C — Canvas (drag-and-drop construction)
Frame D — Style & Branding
Frame F — Anti-Abuse (active only when Public Distribution is enabled)
Frame G — Consent & Compliance

The user does not need to learn a new builder. If they have built a Form, they can build a Survey.

8.3 Tab 3 — Results

This is the architectural surface where Surveys diverge from Forms. The default Results view is aggregate-first: charts and counts, not individual submissions.

Default layout (per Survey):

Headline strip — Total responses, response rate (if Targeted Invite), days open/closed, channel breakdown
Question-by-question results — One panel per question, rendered with the appropriate chart:
- Dropdown / Radio → donut or horizontal bar
- Checkbox multi-select → horizontal bar with multi-count
- Number → histogram + mean/median
- Short Text → word cloud + recent responses list
- Long Text → recent responses list (full pagination)
- Date → distribution chart
- Email / Phone / Address → count only, no chart (not analytic dimensions)
Cross-tabulation panel (V1.5) — pick two questions, see the cross-tab
Segment filter bar — filter the entire view by demographics, tags, channel, response date (only when responses are identified)
Export — CSV (raw responses), PDF (charts as a deck), shareable public results page (optional, controlled by user)

Switch to per-response view — secondary tab inside the Results surface. Submission table identical to Forms’ Submissions tab. Same UVP click-through. Same filters. Hidden in Anonymous mode.

8.4 Why Results Defaults to Aggregate

Surveys are aggregate intelligence tools. The user’s first question after sending a Survey is “what did the group say?” not “what did each individual say?” Inverting the default from Forms is a deliberate product decision that signals what Surveys are for.

9. The Upgrade Funnel — Surveys → Polls

This is the strategic role Surveys play in the product lineup. The Polling Engine is a paid upgrade; Surveys are how users discover they need it.

9.1 Surfaces Where the Upsell Appears

On the Results view:

When a Survey’s results are inconclusive or show high variance: “These results are noisy. A representative poll would tell you definitively. Run a Poll →”
When a question is methodologically weak (leading language, double-barreled, etc., detected by AI): “This question may be biasing responses. The Polling Engine catches this automatically. Learn more →”
When the user filters by demographic and the cell sizes are too small: “Too few responses in this segment to draw conclusions. A targeted poll would solve this. Run a Poll →”

On the Survey Detail page:

“Want representativeness on this question? Convert to a Poll →” — pre-populates a Poll draft in Campaign Mode using the same questions as a starting point. (Requires Campaign Mode subscription; if not subscribed, the link routes to upgrade.)

In the AI nudge engine (background):

AI watches Survey usage patterns. If an account is running 3+ Surveys per month and consistently looking at cross-tabs with small n’s, the account gets a contextual prompt about Polls.

9.2 What Carries Over on Conversion

When a user clicks “Convert to Poll,” the system creates a Campaign Mode Poll draft with:

Same questions (copied — the Methodology Agent will then review them)
Same audience intent (Survey audience description → Poll target audience)
A reference back to the originating Survey for context

The Methodology Agent then engages in its normal four-phase consultative interaction. It will likely revise the questions (and that’s the point — that’s the value of the Polling Engine).

9.3 What This Means for Product Positioning

Surveys are the trial experience for the data product. A good Survey experience teaches the user that VRM understands research. When the stakes go up — a real campaign, a real measure, a real ad buy — the user already knows where to go.

10. Question Types & Builder

Surveys use the same field types as Forms (Short Text, Long Text, Email, Phone, Number, Date, Dropdown, Radio, Checkbox single, Checkbox multi, Address Block, Hidden) with three Survey-specific additions in V1.5:

Likert Scale (5- or 7-point agree/disagree)
NPS (0-10 Net Promoter Score style)
Star Rating (1-5 stars)

These additions are appropriate for Surveys because they are aggregate-friendly question types and they don’t really fit a Form (you don’t ask “how would you rate us 1-5 stars” on a newsletter signup).

These types feed the same custom field system. A Likert response on Issue X creates a custom field of type Likert; it can be reused on another Survey; if 35 accounts create the same Likert field, Politogy can promote it. The field promotion pipeline applies.

11. UVP Provenance & Survey-Specific Metadata

Every Survey response writes to the UVP with full provenance, identical to Forms, with two additional metadata fields:

Invitation context — for Targeted Invite responses, which contact list / segment the respondent was invited from
Send/response history — for Targeted Invite responses, the full sequence of invites + reminders + final response time

These fields are useful for understanding engagement velocity (who responds immediately vs. after the second reminder is a signal about contact intensity) and feed the broader Aggregate Intelligence layer.

For Anonymous Surveys, the UVP is not updated with response content (per Section 7.2), but the fact that a token was consumed is recorded as an “engagement event” on the UVP — useful for engagement scoring without revealing what they said.

12. Lifecycle & State Machine

State	Meaning	Receives Responses	Editable
Draft	Under construction	No	Fully
Scheduled	Deployment configured, awaiting open time	No	Restricted (deployment plan locked; questions editable until open)
Live	Open and accepting responses	Yes	Restricted (no question changes, see below)
Closed	Window ended, results final	No	No (clone to create new Survey)
Archived	Retired, retained for historical reference	No	No

12.1 Editing a Live Survey

Once a Survey is Live and has received at least one response:

Cannot add, remove, reorder, or modify questions. This is stricter than Forms because Survey integrity demands a stable instrument across all responses.
Cannot change identity mode or audience.
Cannot modify close conditions toward an earlier close. (Can extend close date; cannot shorten.)
Can modify branding, confirmation message, consent line.
Can add channels (e.g., started as Email-only, add a Public Link mid-flight).
Can send reminders.

The locked-instrument rule is what makes Survey results coherent. If question 3 changes mid-flight, all prior responses to question 3 are interpreted under one wording and all subsequent responses under another. That’s not survey data; that’s noise.

12.2 Cloning

The primary mechanism for “re-running” a Survey. Closed Survey → Clone → new Survey in Draft state with identical questions and a fresh Deployment Plan. The cloned Survey is a distinct entity with distinct results, not a continuation.

This is the V1 answer to longitudinal Survey tracking. (V2: explicit longitudinal Survey series with comparable result rendering across versions. Defer.)

13. Anonymous Mode & The Data Trust Boundary

When a Survey is configured as Anonymous, the customer-tier UI must enforce the following:

Identity field types (First Name, Last Name, Email, Phone, Address Block) cannot be added to the canvas. The Field Library shows them disabled with a tooltip explaining the Anonymous mode restriction.
The Results view does NOT include the per-response submission table. There is nothing to show — responses are not individually linkable.
The export is aggregate-only. The CSV contains response counts and percentages by question, not per-row response data.
The consent line is auto-augmented to disclose anonymity: “Your individual response will not be linked to your identity in this Survey.”

What Politogy does behind the scenes:

Responses are stored with submission-level metadata (timestamp, IP, source, token if invited) but the relational link between the response and the responder’s UVP is severed.
This is honest anonymity, not fake anonymity. The customer cannot identify respondents through any UI surface or export.
Politogy retains the data in aggregate form for Aggregate Intelligence purposes per the platform Terms.

Why this matters legally. Anonymous Surveys are a meaningful trust feature. A campaign asking its supporters about a controversial position needs to be able to promise that responses are not individually tracked. The product must deliver on that promise architecturally, not just in copy.

14. Branding, Templates, Distribution

14.1 Templates (V1)

Politogy-curated Survey starter templates:

Issue Pulse — 3-5 questions on a single issue, Likert-heavy
Member Satisfaction — NPS + open-ended follow-up
Event Feedback — post-event ratings + comments
Candidate Awareness — name recognition + favorability (basic, NOT a poll)
Volunteer Interest Check — issues + skills + availability

Each template is single-purpose and intentionally short. The product opinion is that Surveys should be brief (5-10 questions max for completion rate). Longer Surveys get longer abandonment.

14.2 Per-Survey Branding

Same brand frame as Forms. Account-level defaults inherited; per-Survey overrides available.

14.3 Distribution Mechanics

Tokenized invite system (Targeted Invite mode):

Each invited contact gets a unique URL containing a single-use token (or multi-use if Survey allows multiple responses, which it doesn’t by default).
Token expires when the Survey closes.
Token is invalidated on response (one response per token).
Token resolves the responder’s UVP identity automatically — they don’t have to re-enter name/email.

Public Distribution:

Same surfaces as Forms — hosted link, iframe, JS embed, QR. URL parameter pass-through into Hidden fields supported.

15. Permissions, V1/V2 Scope

15.1 Permissions

Identical to Forms (see vrm-forms §15). Custom field creation gated to Admin/Manager. Survey deployment authority gated to Admin/Manager.

15.2 V1 — Ship

Three-tab UI (Surveys / Canvas / Results)
Survey builder using Forms infrastructure
Deployment Plan frame: Audience (Targeted Invite / Public / Hybrid), Channel (Email + Embed + Public Link + QR), Schedule, Close Conditions, Reminders (up to 2), Identity Mode (Identified / Anonymous / Pseudonymous)
Aggregate-first Results view with question-by-question charts
Per-response submission table (when not Anonymous)
Survey lifecycle state machine (Draft / Scheduled / Live / Closed / Archived)
Cloning Closed Surveys to create new ones
5 starter templates
Upgrade-to-Poll surface (link routing; conversion seeded with same questions)
Anonymous mode with full data trust enforcement
CAPTCHA / honeypot / rate limiting for Public Distribution
Tokenized invite URLs for Targeted Invite mode

15.3 V1.5 — Near-term Additions

SMS channel (requires TCPA infrastructure)
Likert / NPS / Star Rating field types
Cross-tabulation panel in Results view
Public shareable Results page (read-only, branded)

15.4 V2 — Defer

Conditional logic (show/hide questions based on prior answers)
Multi-page Surveys
File upload / signature capture in Survey responses
Longitudinal Survey series with comparable result rendering across versions
Reminders >2 per Survey
A/B testing of question variants
AI question quality flags (light version of Methodology Agent — flagging only, no push-back, with link to Polls)
Webhooks on response

15.5 V3+ — Aspirational

Auto-translation of Surveys
Voice-response Surveys (IVR)
Survey-to-Poll auto-conversion with Methodology Agent pre-revision

16. Summary Mental Model

A Survey is a Form deployed as a campaign. Same builder, same fields, same UVP writes — different deployment, different results presentation, different identity options, different lifecycle.

Surveys are the lightweight intelligence tool in Relationship Mode. They are intentionally lower-rigor than Polls. They give Relationship Mode users group-level intelligence on their own list (or the public) without methodology requirements. They feed Aggregate Intelligence behind the scenes. They are the upgrade funnel into the Polling Engine.

The North Star: Surveys feel simple enough that any user can deploy one in five minutes, give back aggregate results that are useful for low-stakes decisions, and consistently produce moments where the user recognizes “for the big questions, I need a Poll.” That triad is what makes Surveys an effective product and an effective funnel.

Developer Open Questions

These are the V1 decisions that need a recommendation before engineering can scope. Each is genuinely open.

Survey vs. Form as a single object type or two object types? Architecturally, a Survey is a Form with deployment configuration. Do we model them as one object with a deployment_mode discriminator, or two distinct objects with a shared field schema? Recommend one object with discriminator — simpler, more DRY, and supports clean “convert this Form to a Survey” workflows. The trade-off is that the UI conceptually treats them as separate products.
Where does Survey navigation live in the app sidebar? Same sidebar entry as Forms (e.g., “Forms & Surveys” combined) or distinct entries? Recommend distinct entries for navigation clarity even if the underlying object is unified — users mentally categorize them differently.
Targeted Invite audience selection UX. Does the user pick from saved segments / tags only, or build an ad-hoc filter inline at deployment time? Recommend both: a saved-segment picker AND an inline filter builder. Inline lives in the Deployment Plan frame.
Email send infrastructure. Does VRM build native send capability for invites and reminders, or integrate with an existing provider (SendGrid, Postmark, etc.) for V1? Recommend native send for V1 to keep the user experience contained in VRM; introduce provider integration in V1.5 as scale demands.
Token security model. Tokens for Targeted Invite links: short and guessable but rate-limited, or long and cryptographically secure? Recommend long and cryptographically secure (e.g., 32-byte URL-safe), accepting the slightly uglier URL.
One-response-per-token enforcement. Hard enforce or allow override (user can configure “respondents can update their response”)? Recommend hard enforce for V1 — coherent analytic baseline.
Anonymous mode + identity field block. When the user toggles Anonymous and the canvas already has identity fields on it, what happens? Auto-remove with warning? Block the toggle until removed? Recommend block the toggle with a clear error pointing to the offending fields.
Aggregate Results rendering tech. Charts are the entire Results view. Do we use a charting library (Recharts, Chart.js) or roll our own SVG components? Recommend library — charting is solved; don’t reinvent.
Cross-tab cell-size guardrails. When the Results view’s cross-tab panel produces cells with very low n, do we render them (with caveat) or hide them? Recommend render with a “low confidence — n=X” caveat, which doubles as a Polls upsell trigger.
Identity-mode lock timing. When does identity mode become immutable? At Schedule? At Live? At first response? Recommend at deployment-to-Live (state transition Draft/Scheduled → Live) — gives the user maximum flexibility while in Draft.
Reminder channel inheritance. Can a reminder use a different channel than the initial invite (e.g., initial Email, reminder SMS)? Recommend same-channel only for V1; cross-channel reminders in V1.5 alongside SMS infrastructure.
Public Results page authentication. When a user enables “shareable public results,” is the link gated (token / password) or fully public? Recommend offering both with public as default.
Aggregate Intelligence disclosure on Anonymous Surveys. The platform Terms cover this generically; do we add a specific in-product disclosure when a user toggles Anonymous mode (“note: Politogy still receives data in aggregate”)? Recommend yes — earns trust through transparency.
Response-rate metric for Public Distribution. Targeted Invite has a natural denominator (invites sent). Public Distribution doesn’t (views are only countable on JS embed). Do we surface a response rate at all for Public Distribution? Recommend showing total responses + completion rate (started but didn’t finish) only, not a “rate.”
Survey re-invitation and consent. If a contact has opted out of one Survey, are they auto-excluded from future Survey invites? Recommend yes by default, with a per-Survey override for legally-required communications.
Convert-to-Poll question carry behavior. When a user clicks “Convert to Poll,” do all questions carry, only some (the user picks), or none (the Poll starts fresh with audience description only)? Recommend all questions carry by default, user can deselect any; the Methodology Agent then revises them in Campaign Mode.
Single-question Surveys. Should the system allow a one-question Survey? Recommend yes — high utility for quick pulse checks (e.g., “Are you attending the rally? Yes / No”). Most one-question Surveys will be Likert/NPS/Radio.
Survey-driven UVP creation gate. Same question as Forms had: when an anonymous-public Survey creates a Relationship-Sourced UVP, what’s the minimum required data? Recommend same threshold as Forms (at least one of: Email, Phone, Name+Address).

End of Spec

This document is the V1 conceptual specification for VRM Surveys in Relationship Mode. It is intentionally pared down to the conceptual layer; data model details, API surface, and UI specifications follow in implementation specs derived from this document.

The North Star: Surveys feel simple to the user, produce useful group-level intelligence, and consistently teach the user where to go when the stakes get serious — the Polling Engine.

🗳️ Politogy VRM — V2 Specs

Explorer