Sopact is a technology based social enterprise committed to helping organizations measure impact by directly involving their stakeholders.
Copyright 2015-2026 © sopact. All rights reserved.
How to design a pre and post survey — 30 sample questions across five domains, common mistakes to avoid, and the analysis methods that produce real deltas.
A pre and post survey measures change by asking the same participants identical questions before a program starts and after it ends, so the difference between the two — for the same person — is the evidence of what the program changed. The pre survey captures the baseline; the post survey captures the outcome; the matched gap between them is the finding.
It is the method funders, boards, and investment committees ask for, because it is the only survey design that can argue your program caused the change rather than merely coincided with it. And it is the one most teams quietly get wrong — not at the question, but at the match.
The design looks simple: ask twice, subtract. The execution is where it collapses, and the research on how it collapses is unusually clear.
The first failure is matching. To compare a participant's two responses you must link their pre record to their post record — and teams that rely on names, emails, or participant-remembered codes lose a large share of the data doing it. In the peer-reviewed literature on matching longitudinal responses, losing up to 50% of cases is "not uncommon" when exact code agreement is required, and match rates average around 65% across studies (Survey Methods: Insights from the Field). Even the landmark matching method held 92% of pairs over one month but only 78% over a year (Yurek et al.). A post survey with 200 responses and a 60% match rate is a finding built on 120 people — and those 120 are not a random subset. They are the ones whose details stayed consistent, which is itself a bias.
The second failure is attrition. People leave. Research treats 20–40% attrition as enough to bias results, especially when it is nonrandom, and real programs routinely lose more: one longitudinal study lost 26% of participants by six months and 42% by twenty-four (NIDILRR study).
The third failure is the sheer manual cost of getting to an answer. Surveys arrive as exports; the analyst spends the bulk of the project reconciling them. Across the data profession, roughly 80% of the work is data preparation and about 60% is cleaning and organizing (Forbes / CrowdFlower). In a program office without a data team, that work lands on whoever ran the survey, and it stretches to months. By the time the matched analysis is ready, the cohort has already graduated.
None of this is a skills problem. It is what happens when identity and structure are decided after collection instead of at it.
Almost every team starts the same way: a survey tool to collect, a spreadsheet to match and analyze, and lately a general AI tool to summarize the open text. On paper it works. In practice each wave is an independent export with no shared identity, so the reconciliation the research describes becomes your problem, every cycle. Sector studies find exactly this pattern: organizations "juggle surveys, donor CRMs, spreadsheets, and grantee reports, but nothing ties it together," leaving a persistent gap between the intent to measure change and the ability to actually show it (Pew Charitable Trusts).
The tempting shortcut — paste the exports into ChatGPT and ask it to find the change — makes the problem worse, not better. A general model handed five spreadsheet exports of one cohort will produce a fluent answer, and a different fluent answer the next run, with no way to trace any number back to a participant a reviewer can open. It has no persistent record beneath it, no shared codebook, and no link from a claim back to a source. Fluent and unreproducible is worse than slow when the reader is your board.
So the real shift is not from one survey tool to a better survey tool. It is from collect-then-clean to structured-at-collection: fix identity and structure at the moment data arrives, so there is nothing to reconcile later. That single change is what the rest of this page is about.
Name the failure precisely, because you fix what you can name. The Identity Break is the moment a participant's pre-survey record and post-survey record become permanently disconnected, because no persistent unique ID was assigned at first contact. "Sarah Johnson" in January becomes "S. Johnson" in June, her email changes in between, and the two records can no longer be proven to be the same person. Every statistic above — the 50% loss, the year-long decay from 92% to 78% — is the Identity Break measured from a different angle.
Sopact closes it by assigning a persistent participant ID at first contact and carrying that same ID into every survey link, document, and follow-up that follows. Pre, post, and the six-month wave land on one record automatically, so matching is not a step you schedule — it is a property the data already has.
The Identity Break is fixed by architecture, not effort, so it is worth being concrete about what that architecture is. Four things have to be true at the same time, and they have to be true at collection, not bolted on afterward.
One persistent record per participant. A single system-assigned ID is attached to a participant at first contact and survives an email change, a re-spelled name, or a new address. A trainee's week-one baseline, week-twelve post, and 90-day follow-up are the same record — not three rows in three exports that someone has to prove belong together. This is the difference between matching being a project and matching being automatic.
Clean at the source, against a codebook. The survey is designed so every field — including the open-ended "why" — maps to your rubric or data dictionary as it is captured, not decoded from free text three months later. The structure exists before the first response, so the data arrives analysis-ready. This is what removes the 60–80% preparation tax the research describes: there is nothing to clean because nothing was collected shapeless.
Analysis at collection, tied to the record. Each response is read the moment it lands and coded against the codebook your team defined, with the reasoning and the source sentence attached to the participant's record. The open-ended answer is not exported to a separate tool and re-imported; the theme and the quote behind it live on the same row as the score.
Traceable and reproducible by design. Because analysis runs against a fixed record and a defined codebook, asking the same question twice returns the same answer, and every number links back to the exact response it came from. That is the property a board update or a funder report actually needs, and it is precisely the property a spreadsheet plus a general chatbot cannot provide.
The short version: a survey tool gives you responses, a spreadsheet gives you a place to reconcile them, and a general AI gives you a fluent guess over whatever you paste. Sopact gives you one durable record per participant, structured at collection and readable on arrival — which is the only foundation on which pre-post evidence holds up.
Below is the full cycle. Each stage has what happens, the exact request to give the Sopact Assistant, and what you get back. Read the prompts as instructions the Assistant runs against your connected, ID-linked records and your codebook — that is why they return a cited, reproducible answer here. The same words pasted into a general chatbot over loose exports return a different guess each time, because the record, the codebook, and the source links are missing. The prompt is only as good as the architecture beneath it.
The baseline is the reference every later wave is measured against. Build it so every field maps to your rubric and every respondent gets a persistent ID at first contact.
Ask the Sopact Assistant: Build a pre-program baseline survey from [PROGRAM DOC] — a short skill and confidence rubric (1–5), one open-ended "why" per scale item, and metadata fields for cohort and demographics. Assign every respondent a persistent participant ID embedded in the survey link.
Expected output. A mobile-ready baseline where every response carries a persistent ID and each number has a paired "why," structured against your codebook. Why it holds in Sopact: the ID and the codebook are created here, so everything downstream attaches to them automatically.
A mid-program pulse on the same ID catches the participant slipping while you can still act.
Ask the Sopact Assistant: From this week-6 pulse for [COHORT], flag any participant whose confidence or engagement dropped from baseline on the same ID, quote the source sentence, and route each flag to an owner.
Expected output. A ranked list of at-risk participants tied to their baseline record, each flag cited to the exact response. Why it holds: the pulse is already linked to the baseline by ID, so "dropped from baseline" is a real comparison, not a fuzzy name-match.
Re-run the baseline instrument, unchanged, on the same IDs. Because identity holds, there is no matching step to schedule.
Ask the Sopact Assistant: Administer the identical post survey to [COHORT] on the existing participant IDs, and confirm every post response is linked to its pre record before analysis.
Expected output. A closed post wave already matched to baseline, with any unmatched records flagged. Why it holds: matching happened at collection; you are confirming links, not rebuilding them in a spreadsheet.
With records linked, compute each participant's change score and read the distribution.
Ask the Sopact Assistant: For [COHORT], compute each participant's pre-to-post change on the matched IDs, correlate the largest gains with themes from the open-ended "why," disaggregate by cohort and demographics, and pair every number with a representative quote.
Expected output. Matched-pair results with correlation and segmentation, each figure carrying a source quote — reproducible on re-run. Why it holds: the "why" was coded at collection against your codebook, so correlating it with the score is a query, not a month of manual coding. For deeper method, see survey analysis and how to analyze pre-mid-post survey data.
The same record produces the funder report today and the follow-up wave later, because the ID keeps the participant reachable and comparable.
Ask the Sopact Assistant: Generate a [funder / board] report for [COHORT] — outcomes against targets, ranked themes with quotes, equity breakdowns — then schedule the 3/6/12-month follow-up on the same IDs.
Expected output. A funder-ready matched report plus a scheduled longitudinal wave on the same records. Why it holds: every figure links to its source response, so the report survives the question "show me where that number came from." See longitudinal data collection.
Architecture does the heavy lifting, but a few design decisions still have to be right before the first response.
Identical wording. Pre and post must use the same wording, scales, and order; changing "confidence" to "self-assurance" between waves invalidates the comparison. Lock the baseline before launch.
A persistent ID, not a remembered code. Assign a system-generated ID at first contact rather than a name, email, or code the participant has to recall — the research is explicit that recalled codes are where the up-to-50% loss comes from.
A "why" beside every number. Pair each scale item with one open-ended question, so the number shows how much changed and the text shows what drove it.
Metadata at intake. Capture cohort, site, and demographics in the first survey; equity gaps hide under the average when disaggregation is retrofitted from exports.
Strategic timing. Pre immediately before, post immediately after, and follow-ups planned from day one — with the contact infrastructure to reach people later, which is itself an architecture question.
"Scores improved 35%" hides who moved and why. Credible analysis goes five ways past the mean: matched-pair change per participant; correlation between the biggest gains and qualitative themes; segmentation that exposes equity gaps; longitudinal follow-up that shows whether gains persist; and mixed-methods integration that ties each number to the "why" behind it. The full method with worked examples lives in how to analyze survey data and the Academy walkthroughs below.
Most tools collect two waves. The dividing line is whether they link the waves for the same participant, and whether the open-ended "why" is analyzed beside the numbers or exported away.
SurveyMonkey and Qualtrics are capable survey platforms; the gap is architecture, not features. Pre-post participant tracking was never their design center, so the matching and cleaning land on your analyst — the exact 60–80% preparation cost the research quantifies. Sopact is built around the persistent record, which is why that cost disappears.
Pre-post runs the same way whether you are a training provider, a nonprofit program, or an impact fund — only the stakeholders differ. Training providers prove skills were gained and kept: baseline, exit, and 90-day retention on one ID (see training feedback surveys). Nonprofit programs need individual, disaggregated change across intake, mid, exit, and follow-up (see beneficiary feedback surveys and impact survey questions). Impact funds run a diligence baseline against quarterly monitoring on a persistent investee ID. Different stakeholders, one requirement: persistent identity from first contact.
A workforce program ran a week-one baseline and week-twelve post on the same scale and the same participant IDs. Matched analysis showed confidence up 1.8 points on average — but participants who mentioned "peer study groups" in the open-ended "why" gained 60% more than those who did not. The program doubled peer learning for the next cohort. That finding was invisible in the average and impossible without the "why" coded against the same record as the score — which is the whole point of the architecture.
A pre and post survey is the right instrument when you need to measure change in the same people across a program — but it is one of four common designs, and reaching for the wrong one is a frequent and expensive mistake. A retrospective pre/post asks participants at the end to rate themselves "before and after" in one sitting: faster, and it sidesteps the matching problem, but the "before" is a memory, so it only approximates change. A longitudinal panel follows the same people across years for durable outcomes at higher cost. A cross-sectional survey takes a one-time population snapshot and cannot measure individual change at all. The table is the quick decision.
Whichever design fits, the same rule holds: the moment you need to track change for the same person, you need a persistent participant ID — which is what turns the pre/post and longitudinal rows above into evidence instead of a matching project.
A pre and post survey measures change by asking the same participants identical questions before a program begins (the pre survey or baseline) and after it ends (the post survey). Tracking the same individuals across both waves is what lets a program attribute change to its intervention — which is why Sopact links every wave to one persistent participant record rather than matching exports afterward.
Because the evidence depends on matching each participant's two responses, and matching by names or recalled codes loses a large share of cases — the research finds losses of up to 50% are common and match rates degrade over time. Add normal attrition (20–40% is enough to bias results) and the manual cleanup that consumes most of an analyst's time, and most pre-post studies end up reporting on a biased subset. Sopact removes the matching failure by assigning a persistent ID at first contact.
A survey tool collects each wave as an independent export with no shared identity, so linking the waves becomes manual reconciliation — the step where cases are lost and months disappear. Pasting the exports into a general AI tool makes it worse: it returns a fluent but different, untraceable answer each run. Reliable pre-post needs identity and structure fixed at collection, which is what Sopact provides.
Match them with a persistent unique ID assigned at first contact and embedded in each survey link — not names, emails, or recalled codes, which change between waves and drive the documented match-rate losses. Sopact assigns this ID automatically so pre, post, and follow-up link without spreadsheet work. This is the fix for the Identity Break.
Match each participant's responses on the persistent ID, compute individual change scores, and analyze the distribution, not just the average. Correlate the largest gains with qualitative themes, segment by demographics, and pair every number with a quote. Because Sopact codes the open-ended "why" against your codebook at collection, the correlation is a reproducible query rather than a month of manual coding.
The Identity Break is the moment a participant's pre-survey and post-survey records become permanently disconnected because no persistent unique ID was assigned at first contact. Email and name changes sever the link, forcing programs to report aggregate statistics that hide who benefited. Sopact prevents it by assigning persistent IDs at intake and linking every later wave to the same record.
Yes. Pre and post surveys must use identical wording, scales, and question order; even a synonym breaks comparability. Lock the baseline before launch and version any later change rather than editing silently.
Three to six minutes on a phone. Every question should map to a decision you will act on; past six minutes, completion drops and satisficing rises.
A pre and post survey measures self-reported perceptions — confidence, attitudes, barriers. A pre and post assessment (pre-test/post-test) measures objective knowledge with scored answers. Strong evaluation often uses both, and both depend on the same persistent-ID architecture to link records validly across time.
Bring one cohort's pre and post export. The walkthrough links the two waves on your real participant IDs, computes matched-pair change with the qualitative "why" coded against the same record, and ends with a funder-ready report where every number traces to a response — no VLOOKUP, no "which Sarah is this," no biased subset. If the matched analysis is not defensible in front of your board, do not continue. Scope a 30-minute walkthrough →