A one-page plan — one measure per outcome, a home and a moment for each measure, and a deliberate build order that starts with the workflow that shows value i
Start with each outcome in your theory of change and ask four questions:
• What evidence would prove this outcome?
• What is the simplest measure that captures that evidence?
• Where and when should the measure be collected?
• Who owns the quality of that data?
Answer those four questions for every promised outcome and you have a working data-collection workflow.
Instead of collecting information because a form happens to ask for it, every field exists for a reason: to prove an outcome, test an assumption, support a program decision, or satisfy a reporting requirement.
In this guide you'll build that workflow in four steps:
1. Choose one defensible measure for each outcome.
2. Start with the workflow that creates visible value first.
3. Establish a baseline that makes change measurable.
4. Connect every measure to the right collection moment.
The result is a one-page collection plan that connects your theory of change to applications, intake forms, mentor notes, surveys, exit assessments, and follow-up data—creating evidence that can improve programs while they are still running, not just after they end.
As throughout this series, every step is tagged honestly. [DIY] steps can be completed in any AI chat window today. [SENSE] steps require a connected system that can receive data as it arrives, link this month’s answers to previous responses, and build a longitudinal record for each participant.
A data-collection workflow may sound technical, but it begins with one question asked about every outcome:
What evidence would show that this outcome is occurring—and where would that evidence come from?
Your theory of change contains a series of claims: training increases confidence; confidence combined with a recognized credential improves employment prospects; placements remain stable six months later. Each claim needs a clearly defined measure, data source, and collection moment. Make those decisions for every outcome, and the structure of your workflow begins to emerge.
Important assumptions may also need evidence. If your theory assumes that employers continue to recognize a credential, for example, that assumption should become a monitoring question with its own source and collection schedule.
This reverses the way many organizations approach data collection. Most software starts with predefined forms—application, intake, case notes, discharge—and asks the organization to adapt its program to those forms. The resulting reports describe what the organization did but often cannot show what changed.
Here, the theory of change determines what gets collected. Every field must earn its place by supporting an outcome, testing an assumption, meeting a reporting requirement, or informing a decision.
For each outcome in your framework, ask:
What single number or answer would provide credible evidence that this outcome is occurring?
Start with one measure—not five. This is a minimum viable measurement approach: the simplest defensible evidence your team can collect consistently. More complex outcomes may eventually require multiple indicators, but beginning with one forces you to identify what matters most.
Then grade your current measurement honestly:
These grades assess the current state of your evidence, not whether the program itself is succeeding. An UNPROVEN or MISSING label is not a failure; it identifies what your data-collection workflow needs to address.
Paste the following prompt into any AI tool, along with your theory of change, logic model, or a paragraph describing your program:
I run a [describe your program in one sentence]. Here are the outcomes we promise: [paste your theory of change, logic model, or a plain list].
For each outcome, suggest ONE simple way to measure it — a single question or number, with its scale (for example: confidence, self-rated 1–10). One measure per outcome, no more. Label each honestly: EVIDENCED if I told you data exists, UNPROVEN if we claim it but have no data, MISSING if nothing measures it. If no simple measure would truly prove an outcome, say MISSING — don’t invent one.
Two notes on reading your own version of this table. First, the grades are supposed to look bad today — the UNPROVENs and MISSINGs are the map telling you what to build, and pretending otherwise only defers the problem to reporting season. Second, one measure beats five. A confidence question asked the same way at the start, middle, and end of a program reads as one line — 4.2 → 7.1 → 7.4 — three points, one story. Three different confidence instruments produce more data and less proof.
Here is where most initiatives go wrong, and where this chapter departs from the standard advice. The instinct is to build in journey order — intake first, then everything else. The better rule:
Build first the workflow where intelligence shows its value fastest — to your own team.
A first workflow earns its keep when three things are true: the work is already happening, it is drowning in qualitative input, and it is painful because of coordination. You aren’t asking anyone to collect new data or change behavior — you’re taking a pile everyone dreads and returning it read, scored, and cited in minutes. That early, visible win is what buys patience for the baselines and follow-ups whose payoff comes months later.
For most cohort-based programs, that workflow is the application:
Run that same pool through scoring-on-arrival and the contrast is immediate: every application scored against one rubric the moment it is submitted, each score backed by the applicant’s own words, the whole pool ranked and comparable — with no reviewer coordination at all. The time saved is measured in weeks; the consistency is something a committee cannot produce even in principle. That is the demonstration that turns skeptics into sponsors.
Ask your AI to pressure-test the choice:
Here is my measure map from Step 1: [paste it]. And here are the workflows my program already runs (for example: applications, intake, mid-program survey, mentor check-ins, exit survey, follow-up).
Which ONE workflow should I make intelligent first? Prefer a workflow that already exists, receives lots of open-ended text, and currently costs heavy coordination (like application review). Explain the trade-off of your top pick versus starting in journey order.
If your program truly has no application moment, the same logic points to whichever workflow holds the most unread words today — a backlog of session notes, a stack of open-ended survey answers. Start where the pile is.
The natural second workflow is the baseline — the pre-program or needs snapshot. Two reasons it comes right after applications, and not later.
The application often already is the baseline. The nonprofit’s application asked for confidence (1–10), current wage, goals, and barriers — because the admission decision needed them. Those same fields are the “before” half of every change claim the program will ever make. Stamp the application as your baseline wave and “pre” costs zero extra effort; no applicant fills a second, duplicate form.
Needs analysis pays off on day one, not at reporting time. Baseline answers, read on arrival, tell you who needs what before the program starts — the applicant whose barrier text says “no car, and the site is 40 minutes away” gets transport support in week zero, not a dropout flag in week six. A baseline is not just a future comparison point; it is the program’s first act of service.
The discipline that makes a baseline usable later: every measure you capture “before” must be re-asked at a named later moment, on the same scale, worded the same way. A 7.4 at exit proves nothing without the 4.2 it started from — and it proves nothing either if the intake asked the question differently.
Here is my application/intake form and my measure map: [paste both].
With applications scored and a baseline locked, the remaining question is: where else does the journey speak? This is where the plan becomes a workflow map — and where it stops being generic, because the right moments depend on what your funders require and what your team needs to decide.
The common menu, from which each program picks:
Choose against two lists: what your funder or board must see (their report defines mandatory moments), and what your team must decide (an early-warning list needs mid-program data; a staffing decision needs LMS signals). A moment that serves neither list is a survey nobody needed.
Why this step is [SENSE]. A plan on paper can name these moments; only a connected system makes them worth collecting. Two behaviors do the work. First, each stakeholder carries one ID across every form, so a mid-program dip lands next to that person’s baseline automatically — for example, confidence 4.2 → 7.1 → 7.4 across three waves, same people, same scale; or completers employed at follow-up at nearly double the rate of non-completers. Second, every arriving record is read on arrival, so each new moment you add starts producing signal its first week — not after an analyst clears the backlog. That is also what de-risks the phased build: add one moment, watch it work, add the next.
Building in journey order instead of value order. Intake-first feels logical and dies quietly: months of collection before anyone sees a benefit. Lead with the workflow that returns a visible win in days — usually applications — and let it fund the patience for the rest.
Measuring the end without the beginning. Every “after” needs a “before” on the same scale. Baselines are the cheapest thing to collect and the most expensive to reconstruct.
Adding collection moments no one asked for. Every moment must serve the funder’s report or a real decision your team makes. Anything else lowers response rates and goodwill.
Merging instead of connecting. Don’t flatten everything into one giant spreadsheet; keep each moment’s data where it lands and connect through one ID. It’s the missing ID, not the missing field, that silently breaks the story.
A theory of change guides data collection by identifying the outcomes and assumptions that require evidence. Each outcome should be mapped to an indicator, data source, collection method, responsible person, and collection moment. This prevents organizations from collecting information that is easy to count but cannot show whether stakeholders experienced the intended change.
Start by rewriting the outcome as an observable change in a defined population. Then ask, “What would we expect to see if this change occurred?” Select one practical measure that captures that evidence, define its scale, and identify when and from whom it should be collected. Use the same wording and scale at baseline and follow-up whenever change over time must be measured.
A practical plan should include the outcome, indicator, data source, collection method, responsible person, collection frequency, baseline moment, follow-up moment, and participant identifier. It should also include monitoring questions for important assumptions. Every data field should support an outcome claim, test an assumption, satisfy a reporting requirement, or inform a program decision.
Yes, when the application is completed before services begin and captures the same outcome measures that will be repeated later. For example, an application can establish initial employment status, wage, confidence, goals, or barriers. It should not be treated as a baseline when questions, scales, or participant identities cannot be matched reliably with later responses.
A data-collection plan specifies what information will be collected, from whom, when, how, and where it will be stored. An M&E plan is broader: it also defines indicators, targets, responsibilities, analysis methods, learning questions, reporting schedules, and how findings will influence decisions. The workflow in this article forms the data-collection foundation of the broader M&E plan.
Collect outcome data when meaningful change could reasonably occur and when the result can inform a decision. Common moments include baseline, mid-program, exit, and three-, six-, or twelve-month follow-up. More frequent collection is not automatically better. Every collection moment should support a comparison, reporting requirement, early intervention, or program decision.
Every outcome the organization intends to manage or report should have at least one defensible indicator. Some long-term or system-level outcomes may be beyond the organization’s practical measurement capacity. Those should be marked clearly as unmeasured or contribution-level outcomes rather than supported with weak proxy measures.
See an application pool scored on arrival in Sopact Sense — sopact.com/academy.
Next in the series: How to Review Applications Without Reviewer Bias — the workflow you just chose first, built end to end: one rubric, every application scored the moment it arrives, every score backed by the applicant’s own words.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Try it in Case Intelligence →
