Scripts and surveys

Scripts live under Scripts in the dashboard. Each has a name, an internal description for staff, a status (draft, active, archived), and a body with tokens. Walks reference the script, not a specific version, so when you push a new version every attached walk shows it immediately, and the list tells you how many walks use each script.

Surveys live under Surveys. Each has a name, a description, a status, and an ordered list of questions. A walk carries one survey; walkers see it as a bottom sheet at each door. Phone banks carry their own call script with questions built in, and their answers land in the same place as walk answers.

Both are staff-and-above surfaces. Volunteers never see the builders; they see the active script text and the survey questions on the walk they are assigned to.

The editor is a plain text body with a token bar: candidate name, walker name, election date, office, and the voter's first name. Tokens are filled at the door from the campaign record, the walker's profile, and the stop's household, so one script reads correctly at every house. A token the app cannot fill stays visible in braces so the walker knows to substitute it. The new-script template suggests an opener, a key-issue prompt, and the ask.

Saving creates a new numbered version and makes it active; older versions stay in the history and can be re-activated with one click as a rollback. Scripts attach to a single walk from its detail page or to many walks at once from the walks list, and the batch generator attaches the campaign's active script to every walk it creates.

Walker scripts are linear: they do not branch on answers. Phone bank scripts are different. They are built from sections and questions, and each answer choice can point to the next section, so a call script can route a supporter and an undecided voter down different paths. That builder is described on the phone banks page.

The survey builder takes up to 100 questions. Each question has a prompt, optional help text, a required flag, and one of seven kinds: Yes / No, Rating 1 to 5, Single choice, Multiple choice, Short text, Long text, and Number. Choice questions carry labeled options with stable values, so you can reword a label later without breaking stored answers. Questions can be reordered, and the whole set saves as one unit.

You can also import a survey as JSON, which is handy for reusing an instrument across campaigns or drafting it with a consultant; imported surveys arrive as drafts. Status matters: walks pick up the campaign's active survey automatically when they are generated, and activating a survey later sweeps every live walk that has no survey yet and attaches it. The walk generator warns you before creating walks if no survey is active, because a walk without one collects outcomes but no answers.

On a walk's detail page you can attach or swap the survey and script. Once a walk has responses, its survey is locked, so recorded answers stay attached to the questions they answered. The walks list has bulk pickers to set a survey or script across many walks at once, and the generate wizard lets a precinct chair or manager see up front whether a survey will be attached.

Phone banks record answers and tags in the same transaction as the call disposition. Each answer carries the question text, the script version, and an optional annotation key, so a phone-bank answer and a walk-survey answer to the same question end up on the voter record in the same shape. Every response is stamped with its context (block walk, phone bank, or direct entry), and the results views can filter by it.

In the app the walker first chooses who they spoke with: the whole household or one named voter. Answers are stored per voter per question, so a household-level answer is written to every member and an individual answer only to that person. Re-answering a question overwrites the earlier answer for that stop and voter; partial answers are kept. In the browser walker link each answer saves as it is entered and shows a checkmark once the server has it.

App answers go through the offline outbox described on the mobile app page: saved on the phone if the signal drops, synced when it returns, never reported as saved unless the server confirmed it. The server checks that the person saving is assigned to the walk or a member of its campaign, and derives the campaign from the walk rather than trusting the phone. Door Hanger Only stops refuse survey writes entirely, at the database.

Each question can be mapped to an annotation key, one of the campaign's controlled-vocabulary fields that show on the voter card. The builder only offers keys the question's kind can feed: a yes/no question can fill a boolean or text key, a rating or number can fill a scale key, and choice and text questions fill text keys. When a response is saved, a database trigger derives the annotation immediately, latest answer wins, and the raw response stays as the audit trail.

Mapping an existing question backfills its past responses in one step and reports how many voters were updated. Unmapping stops future writes but leaves what is already on the records. From there the answers behave like any other voter attribute: they appear on the voter card, the AI voter query can filter on them (voters who said they support us and rated us 4 or higher), the result can be saved as a list, and a list can be tagged in one action from its page. Phone bank callers can also apply tags directly during the call.

Separately, the built-in walk outcomes (stop status, walker note, receptiveness, supports candidate, intends to vote) are written as annotations when a walk completes, described on the block walking page.

Every survey has a results page with each response in context: who answered, at which stop, on which walk, recorded by whom, and filterable to one walk. Each walk's results page shows response count, average receptiveness, supporter and intends-to-vote counts, filter chips for supporters and high receptiveness, and a CSV export for staff and above. The campaign dashboard's Top Survey Insights widget shows the last seven days of support answers as a supports, undecided, and opposes bar, plus the most-applied tag of the week.

School board, one question that matters. The survey is three questions: will you vote, rate the candidate 1 to 5 after the conversation, and top issue (schools, roads, public safety, other). The rating maps to a scale key and top issue to a text key. After 600 conversations the manager asks the query layer for voters rated 4 or 5 who said schools, saves the 210 who match as a list, and sends them the schools mailer.

City council, script discipline. The candidate rewrites the opener after the first weekend. The manager saves it as version 2; every walk that Saturday shows the new opener without anyone re-attaching anything. When the old close tests better in week three, it is one click to roll back.

County party, phone bank plus doors. Chairs knock with a four-question survey; the evening phone bank uses a branching call script that asks the same two core questions with the same annotation keys. Both feed the same fields, so the county's support count is one number, not two spreadsheets.

A conversation at the door is expensive: a volunteer's Saturday, a candidate's evening. The door-knocking guide makes the case that it is worth it, and the case rests on remembering what was said. A survey that maps onto the voter file means the supporter ID from March is still on the record in October when the turnout list is built, the undecided voter who cared about drainage gets the drainage mailer, and the vote goal is tracked against named people rather than a hunch.

The limits worth knowing before you build an instrument:

• Walker surveys and walker scripts have no branching or skip logic; every question shows at every door. Phone bank scripts do branch.
• Enumerated-value annotation keys (fixed pick-lists) cannot be fed by a survey; they are manual-entry only. Choice questions map to text keys instead.
• A walk's survey cannot be swapped once the walk has responses. Create a new walk for a new instrument.
• Import is JSON only; there is no CSV or third-party form import.
• The dashboard widget shows the built-in support distribution and the top tag, not per-question breakdowns for custom questions. Use the survey's results page for those.
• Surveys and scripts belong to one campaign. To reuse across campaigns, export the JSON and import it.

Scripts and surveys are the instrument; these are the features that carry and consume it:

• Block walking: walks carry a survey and script, and completion writes outcomes to the voter record.
• Volunteer mobile app: the survey sheet, script view, and offline outbox at the door.
• Phone banks: branching call scripts whose answers and tags land on the same records.
• AI voter query: filter on mapped answers in plain English and save the result as a list.
• Search, lists, and tags: tag a list built from survey answers in one action.
• Dashboard and reporting: the Top Survey Insights widget.