One before-number per promised outcome, captured at intake on the scale every later wave will re-ask, joined by one persistent ID — so the pre/post story writes itself.
For: anyone who runs a program with a before and an after — a training cohort, a scholarship, a fellowship, an accelerator — and can't yet prove the after.
Why: most intake forms are built to register people, not to measure them. They capture demographics and a pile of free text, and at reporting time the only honest answer to "did anything improve?" is compared to what?
Outcome: an intake where every field earns its place — one "before" number per promised outcome, on a scale a later wave will re-ask, joined by one persistent ID — so the pre/post story writes itself.
What a well-designed intake pays back immediately:
This is Chapter 5 of the Case Intelligence series. In Chapter 4 you scored every application on arrival against one rubric. Here's the quiet bonus of that work: the application you just scored already holds your "before" numbers. This chapter turns them into a baseline — the starting line every change claim will be measured against. Whether your participants are trainees, students, founders, or grantees, the method is identical.
As always, the first two steps are [DIY] — they run in any AI chat window today. The last two are [SENSE] — product behavior, because a chat window can't read forms as they arrive or check instruments it has never seen.
Picture reporting season. The exit survey says confidence averages 7.4. The funder asks the obvious question: up from what? If intake never asked the same question on the same scale, there is no answer — the 7.4 floats alone, and a year of real work reads as an anecdote.
The failure is designed in at intake. Registration-style forms collect what enrollment needs — name, age, eligibility, program assignment — plus a couple of open text boxes nobody reads until someone hand-codes them weeks later. Nothing on the form was built as the "before" half of a pair, so no pair ever exists.
The distinction that fixes it: demographics describe the person; a baseline measures the outcome, before. Age and education you collect once, for segmentation. Confidence 1–10, current wage, employed yes/no — each of those exists because a promised outcome needs a starting number, and each will be re-asked later on the identical scale, joined by the same ID. Hold that test against every field on your form and the redesign is nearly mechanical.
For each outcome in your framework (your Chapter 2 theory of change, or any plain list of promises), decide the single number or answer that will show it changed. One measure per outcome — a confidence question asked identically at start, middle, and end reads as one line: 4.3 → 7.1 → 7.4. Three different confidence instruments produce more data and less proof.
Paste this into any AI:
Here are the outcomes my program promises: [paste your theory of change, logic model, or a plain list — and describe your program in one sentence].
For each outcome, suggest ONE "before" measure to capture at intake — a single question or number with its scale (for example: confidence, self-rated 1–10). Name the later moment that should re-ask it on the identical scale (mid, exit, or follow-up). If an outcome has no sensible before-number, say NONE — don't invent one. Finish with the two open-ended questions worth adding: one about barriers ("what might get in your way?") and one about goals.
Two design notes. Fix the scale permanently. The scale you choose at intake is a contract with every future wave — a 1–5 re-asked later as 0–100 is not a pair, it's two orphans. And keep the open text to those two questions. Barriers and goals are the text that explains every number you'll ever collect; a third open box is where response rates go to die.
Here is the move most programs miss: you probably already collected the baseline — at admission. The Chapter 4 application asked for confidence, current situation, barriers, and goals, because the rubric needed them to score need and readiness. Those are the same fields the baseline needs. So don't build a second form that asks everything twice; stamp the application as your "before" wave, and pre costs zero extra effort.
Here is my application (or current intake) form: [paste the questions]. And here are the baseline measures from Step 1: [paste them].
Mark each baseline measure REUSE (the application already asks it, same scale), ADD (intake must ask it), or flag it MISMATCH if the later re-ask would use a different scale or wording. Then mark any form field that maps to no outcome and no decision as CUT. Confirm the form starts with one persistent ID field — email — so every later wave joins back to this record.
A separate intake wave earns its place only for what admission genuinely can't capture — cohort assignment, start-date logistics, or a measure you deliberately keep out of the admission decision. Everything else: reuse, don't re-ask. Duplicate questions cost completion rate and invite inconsistency — $14 an hour on the application, $15 at intake, and now nobody knows which is the baseline.
From here on, this is what the product does — not a prompt you run. A chat window can classify the one barrier answer you paste into it. Sense holds the form, so every record is read the moment it is submitted: barriers classified, a readiness flag set, the before-numbers stored against one ID — for participant #1 and participant #80 alike, with nobody pasting anything.
What that looks like for one arriving record:
Read the barrier row the way a case manager would have to: the answer is compositional — transport tangled with childcare tangled with money. Classified on arrival, each strand lands with its quote, and the support routes before day one. The same sentence sitting unread in a text box until week six is a dropout that looks like a mystery.
The last step is a check no chat window can run, because it spans instruments a chat window never sees: every before-number must have a later wave that re-asks it, on the same scale, joined by the same ID. In Sense you ask for it in plain language:
The flagged row is the audit earning its keep. Caught now, the fix is one question added to the exit survey. Caught at report time — which is when most programs discover every one of these holes — it's a year of unprovable claims. And a clean audit is what the whole series cashes in later: 4.3 → 7.1 → 7.4 on confidence, $9.96 → $25.11 on wages, completers employed at nearly double the rate of non-completers. None of that is analysis heroics; all of it is baseline design.
Confusing registration with baseline. If your intake is demographics plus free text, you have a registration form. Add the before-numbers your outcomes need, or accept that change will be unprovable.
Changing the scale between waves. Same scale, same wording, every time. "Roughly comparable" is not comparable.
Asking everything twice. If the application already asked it, reuse it. Every duplicate question costs completion rate and creates a second, conflicting answer.
Letting the open text pile up. Two open questions are gold if they're read on arrival and dead weight if they wait for a coding sprint that never comes.
Skipping the ID. A record without a persistent ID is a baseline for nobody — it can never reconcile with a later wave. Make email the first required field, and validate it.
An intake where every field earns its place: demographics that segment, one before-number per promised outcome with its later wave named, two open questions that arrive classified instead of piling up, and a persistent ID that joins every future wave automatically. Plus an audit that catches dead fields and scale drift now, while the fix is a one-line edit.
Add two questions to your intake, on the exact scales you'll reuse later: a 1–10 self-rating on your core outcome, and one open barrier question. The 1–10 becomes your 4.3; the barrier text becomes your support routing. Everything else in this chapter is refinement on those two.
Program leads whose intake form was designed by the registration process instead of the theory of change. Evaluators who discovered at report time that exit measured on a different scale than intake. Anyone with a drawer of unread open text and a funder asking "compared to what?" If your program collects plenty and proves little, the fix starts here.
See a baseline captured on arrival in Sopact Sense — sopact.com/academy.
Next in the series: How to Spot At-Risk Participants Mid-Program — the baseline you just captured becomes the reference line, and the mid-program wave reads every record against it while intervention is still cheap.
Open Sopact Sense, paste your program description, and put it to work.
Try it in Case Intelligence →
