A nonprofit logic model is the clearest way to explain how your program turns resources into change. It takes the reasoning that usually lives in a long grant narrative — "with this funding we will do this, which will cause that" — and puts it on one page where every link is visible and can be questioned.
This guide walks through how to create a nonprofit logic model from scratch: the five columns, the difference between outputs and outcomes, and how to build and check the causal chain.
Why a logic model beats a grant narrative
A grant narrative can bury a weak assumption in three pages of prose. A logic model cannot. When you have to place each claim in a column and connect it with an arrow, the gaps become impossible to ignore. If your activities do not actually lead to your outcomes, the model shows it as a broken chain.
That is the real value of a logic model. It is not a document for the funder to admire; it is a tool that forces you, the program team, to be honest about how the program works. Staff, board members, and funders can all read the same page and see exactly where the program's reasoning holds and where it is wishful.
The model also keeps a program honest over time. When you measure outcomes and they do not move, you can walk back up the chain and ask which link was wrong — the inputs, the activities, or the assumption connecting them.
One page also travels better than a narrative. A program officer can absorb a logic model in a minute, but a fifteen-page proposal has to be read, and anything that has to be read can be skimmed, and anything that is skimmed will lose the part where your reasoning actually lives.
The five columns, defined
Every logic model uses the same five columns, read left to right.
Inputs are the resources you have before the program starts: staff, volunteers, funding, space, equipment, and partners. These are the things you bring to the table.
Activities are what the program does with those resources: the training you deliver, the meals you serve, the sessions you run. Activities are the work itself.
Outputs are the direct, countable results of those activities: how many people were trained, how many meals were served, how many sessions were held.
Short-term outcomes are the changes in people that happen as a result of the outputs: the knowledge gained, the behavior changed, the trust built.
Long-term impact is the mission-level change the whole program exists to create: better health, stable employment, higher graduation rates.
The five columns form a chain. Each one should lead to the next, and the arrows between them are what make it a logic model rather than five separate lists.
Outputs vs outcomes: the distinction everyone gets wrong
The most common mistake in a logic model is writing outputs where outcomes belong. The rule of thumb is simple: if you can count it, it is usually an output. If it describes a change in a person, it is an outcome.
"Trained 100 participants" is an output. It counts an activity's result. "Participants can now use the skills they learned" is an outcome. It describes what changed for those 100 people afterward.
The distinction matters because funders and boards are increasingly asking for outcomes, not just outputs. A program that reports only outputs has proven it was busy; a program that reports outcomes has proven it worked. Keeping the two columns separate is what lets you measure the second one.
A useful test is to ask "so what?" after each item. If the item is an output, the answer to "so what?" is the outcome you should write in the next column. If the item already answers "so what?", it belongs in the outcomes column.
Step 1: Start with inputs
Begin on the left, with what you already have. List every resource the program uses: the people, the money, the space, the equipment, the partnerships. Be specific rather than generic. "Staff" is weaker than "one full-time coordinator and four part-time mentors," and the specificity forces you to see whether your inputs can actually support the activities you have in mind.
Do not list inputs you wish you had. The logic model is built from the resources that exist today, because those are the only ones the program can actually use. If you discover a gap here — you have the space but not the staff — that gap is a finding, not a reason to write a wish into the model.
Starting with inputs also keeps the rest of the model grounded. It is easy to design an ambitious activities column; it is harder to make it fit the resources you actually command.
Step 2: List activities, then their outputs
Next, write what the program does, then what that work directly produces. Keep the two columns side by side because each activity should have a matching output.
An activity is "run weekly mentoring sessions." Its output is "sessions held" or "youth matched." An activity is "distribute food boxes." Its output is "households served." For every activity, ask what you can count when it is done — that count is the output.
Do not try to make the output sound impressive. The purpose of the output column is not to persuade; it is to measure. A plain, countable output is more useful than a grand one you cannot actually track.
Step 3: Write outcomes as change, not activity
Now move to the columns that are hardest to write: short-term outcomes and long-term impact.
Short-term outcomes describe the change that happens in the near term as a result of the outputs. After the sessions are held, what is different for the participants? They know something they did not know, they behave differently, or they feel differently about themselves and the program.
Long-term impact is the big, slow change the whole program exists to create. It usually takes years and many programs, not just yours, to produce it. Do not claim it too casually; a single mentoring program does not single-handedly raise a city's graduation rate, but it contributes, and that contribution is what belongs here.
Write outcomes from the participant's point of view, not the program's. "Participants complete the course" is about the program; "participants can apply what they learned" is about the person. The second one is the outcome.
Step 4: Draw the arrows and check the chain
The arrows between columns are the logic model, and they are where the real work happens. Draw an arrow from each column to the next, then test each one by asking whether the link actually holds.
Does this activity really follow from this input? Does this output really follow from this activity? Does this outcome really follow from this output? The moment an arrow does not hold — when you realize the activity would not actually produce the output, or the output would not actually cause the outcome — you have found the weak point in the program's reasoning.
This is the step people skip, and it is the whole point. A logic model with unexamined arrows is a poster. A logic model whose arrows have been tested is a plan. Work the chain backward from impact to inputs, and forward from inputs to impact, until every link survives the question "does this actually cause that?"
Common mistakes in nonprofit logic models
The first mistake is the output-outcome confusion described above. Most first drafts have a full output column and an outcome column filled with more outputs.
The second mistake is leaving the arrows out. Without the arrows, the five columns are unrelated lists, and the model cannot reveal where the reasoning breaks.
The third mistake is writing aspirational inputs. A logic model built on funding you hope to win and staff you hope to hire describes a different program than the one that exists.
The fourth mistake is claiming a long-term impact no single program can deliver. Long-term impact is where your program contributes, not where it performs alone. Overclaiming here weakens the model's credibility with funders who read it carefully.
Free nonprofit logic model template
Open the nonprofit logic model template to get the five columns and the arrows already in place. It includes three filled-in scenarios — youth mentoring, a community food pantry, and workforce training — with concrete counts such as people served, sessions held, and certificates earned. Start from the closest example, replace the numbers with measures you can actually collect, then test whether every outcome follows from the work before it.
If you are still defining the problem the program addresses, the 5 Whys template helps you get to the root cause first, and the fishbone diagram template helps you map all the contributing factors before you design the solution.
A logic model will not run your program for you, but it will make the reasoning behind it visible enough to question, and that is the first step toward a program that actually works.
