3- How to Turn a Theory of Change into a Data-Collection Workflow

For: anyone with a framework full of promised outcomes — from a workforce nonprofit to a scholarship fund to an accelerator — and no clear plan for proving them.

Why: a theory of change says what you believe. Data collection is how you find out whether it’s true. Most teams collect plenty and can prove little, because their forms were never designed to test their theory.

Outcome: a one-page plan — one measure per outcome, a home and a moment for each measure, and a deliberate order for building your workflows, starting with the one that shows value in days.

This is Chapter 3 of the Case Intelligence series. Chapter 1 defined the idea: your stakeholders are cases — people on long journeys whose outcomes you owe someone. Chapter 2 built the framework that names those outcomes; a logic model, logframe, or results framework works identically. This chapter turns the framework into a plan — and, importantly, into a sequence, because the order in which you build workflows decides whether this effort survives its first quarter.

We keep following the two organizations from Chapter 1: the grant-funded nonprofit training people toward job-readiness, and the social enterprise placing job-ready candidates with employers. Swap in your own nouns — the method doesn’t change.

As throughout the series, each step is tagged honestly: [DIY] steps run in any AI chat window today; [SENSE] steps are product behavior, because a chat window can’t receive your data as it arrives or connect this month’s answers to last month’s.

The one question that designs the whole workflow

A data-collection workflow sounds technical. It’s one question, asked once per promise:

“What would prove this — and where would that proof come from?”

Your framework is a set of claims: “training builds confidence,” “confidence plus a credential leads to a good job,” “placements hold at six months.” Each claim needs one place where its evidence lands. Decide that for every claim, and the workflow designs itself.

Notice what this replaces. Most software hands you its forms — intake, notes, discharge — and you bend your program to fit. Then the reports describe what you did, not what changed. Here the direction reverses: your framework decides what gets collected, and every field must earn its place by proving something.

Step 1 — One measure per outcome [DIY]

For each outcome in your framework, ask: what single number or answer would show this is real? Not five metrics — one. Then grade yourself honestly:

• EVIDENCED — the data exists and you can quote it
• UNPROVEN — you make the claim, but nothing backs it yet
• MISSING — you aren’t measuring it at all

Paste this into any AI, along with your framework (or even 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.

Step 2 — Choose your first workflow: lead with proof of value [DIY]

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:

• The nonprofit’s training cohort opens with applications: personal statements, goal and barrier questions, sometimes an uploaded proposal. Reviewing them normally means recruiting a committee, aligning calendars for weeks, and accepting that reviewer #1 and reviewer #5 score by different private standards.
• The accelerator’s or fellowship’s version is identical — proposals in, weeks of inconsistent review, decisions that arrive late.

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.

Step 3 — Baseline next: the “before” that makes change provable [DIY]

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].

1. Which application fields already serve as baseline measures — and for which outcome? (2) Which promised outcomes still have no “before” measure — and what one question would capture each? (3) Flag any measure whose later re-ask would use a different scale or wording — those pairs won’t be comparable. Group the result into: REUSE from application · ADD at intake · re-ask later at [moment].

Step 4 — Now design for change: pick your collection moments [SENSE]

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:

• Mid-program check-in — the same baseline questions re-asked, plus “what’s getting in your way right now?” Catches people drifting while intervention is still cheap.
• Mentor, coach, or staff notes — recurring, unstructured, and the richest early-warning source a program has, if they are read on arrival instead of filed.
• LMS or attendance signals — engagement data that already exists; connected to the record, it turns “quietly disengaging” into a visible pattern.
• Exit — closes the before/after pair the baseline opened; completion alone is not change.
• Follow-up (3, 6, or 12 months) — where the outcomes that matter actually live: employment, wages, persistence, placement durability.
• The demand side — for the social enterprise: employer requirements, openings, and placements, so candidate supply and employer demand reconcile instead of living as two unrelated counts.

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.

Common mistakes

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.

What you have now

A one-page plan in your own words: each promised outcome with one measure; the application workflow chosen first because it proves value in days; the baseline stamped at zero extra cost; and a deliberate menu of collection moments — mid, mentor notes, LMS, exit, follow-up, demand side — each justified by a funder requirement or a team decision. Not a big-bang system: a sequence, where every phase earns the next.

The one thing to do this week

Run the Step 1 prompt against your framework — under an hour. Then answer Step 2’s question in one sentence: which of our existing workflows is drowning in words and coordination? That sentence is your starting line, and Chapter 4 is its instruction manual.

Who this is for

Program leads with promises on a slide and data in five disconnected tools. Teams burned by a big system that took a year to configure and still can’t answer “what changed?” Any organization — nonprofit or social enterprise — that wants its first month of this work to produce a visible win, not a longer to-do list.

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.