What is a logic model template?
A logic model template helps a team describe how a program's resources and activities are expected to contribute to its results. A common layout includes inputs, activities, outputs and short-, intermediate- and longer-term outcomes. Add context and assumptions so the model explains more than the contents of a set of boxes.
The model is a planning and communication tool. It can be useful before results exist, and a clear static diagram is not a failure. The next step is to connect the priority questions in the model to a feasible evidence and review plan.
Use this page to download a blank template, see a filled example and work through the distinction between delivery and change. For the broader concept, read what a logic model is.
Download the editable logic model template
Download the blank logic model template — CSV for Excel or Google Sheets →
Open or import the CSV in a spreadsheet, replace the starter text and save it in your preferred format. It includes a row for the proposed chain, a row for assumptions and context, and a row for evidence questions. Add branches or supporting notes where your program is more complex than one sequence.
Scroll horizontally to see all columns →
| Inputs | Activities | Outputs | Short-term outcomes | Intermediate and longer-term outcomes |
|---|---|---|---|---|
| Resources the program uses | What the team does | What is delivered and to whom | Early changes expected | Later changes the program aims to support |
| Under the chain: assumptions, context, other influences and possible unintended effects | ||||
| Alongside the chain: priority evidence questions, sources, timing and review responsibility | ||||
This is a general-purpose planning aid, not a required funder form. Use the relevant format when your organization or funder specifies one.
What belongs in each part?
Inputs: the resources and conditions you work with
Include relevant people, funding, partnerships, materials, systems and existing knowledge. Do not assume these resources are guaranteed simply because they appear in the model. Note critical gaps or dependencies.
Activities: the work undertaken
Describe the main actions, such as delivering workshops, coordinating referrals or supporting local partners. Keep the level of detail useful for the audience; a model does not need to become a complete task list.
Outputs: what is delivered
Outputs describe the direct products or services of the work. Examples include sessions delivered, participants completing a defined course or referrals made. Specify the unit and relevant quality conditions rather than treating every contact as an equivalent result.
Outcomes: the changes expected
Outcomes may concern knowledge, practice, access, organizational capability or wider conditions. Distinguish early changes from later ones and show the proposed connection. A participant's satisfaction with a session is not the same as later use of a skill.
Context and assumptions: why the links might hold
Explain conditions such as opportunity to apply learning, availability of services or support from partner organizations. Include other influences and plausible unintended effects. Logic models can include assumptions; these are not exclusive to a theory of change.
The CDC's program-description guidance presents logic models as a way to show activities and intended outcomes while considering context. Its logic model components resource also includes assumptions or context.
Filled example: professional-development program
Fictional example. A network wants members to apply a practical method at work. The model below describes the proposed program, not observed results or a proven causal pathway.
Scroll horizontally to see all columns →
| Component | Illustrative content | Question to examine |
|---|---|---|
| Inputs | Facilitator time, learning materials, member organizations and accessible delivery arrangements | Are these resources available and suitable for the participants? |
| Activities | Deliver workshops and guided practice | Do participants have a meaningful chance to practise? |
| Outputs | Workshops delivered and participants completing defined requirements | Who participated and completed, and who could not? |
| Short-term outcome | Participants can explain and demonstrate the method in an appropriate exercise | What assessment would provide suitable evidence? |
| Intermediate outcome | Participants use the method in a relevant work setting | Is there an opportunity to apply it, and what happens afterward? |
| Longer-term contribution | More effective professional practice | How do we assess this broader change and other influences? |
Key assumptions include access to suitable work tasks, organizational support and continued relevance of the method. A well-attended workshop does not establish those conditions. They deserve evidence and discussion.
For a worked numerical review of a similar fictional program, see the logframe example. It distinguishes planned targets, completion, follow-up coverage and reported use.
How to build your logic model
- Agree the purpose and audience. Decide whether the model supports program design, a proposal, an evaluation or a management conversation.
- Describe the problem and context. Include affected perspectives and relevant evidence, not only the delivery team's assumptions.
- Name the intended changes. Work backward from important outcomes to the activities and resources that might support them.
- Check the links in both directions. Ask whether the proposed activities could lead to the outcomes and whether essential steps are missing.
- Add assumptions and other influences. Make the reasoning visible rather than relying on arrows alone.
- Choose priority evidence questions. Identify what is most uncertain or important to a decision.
- Review with the relevant people. Record disagreements and revisions before treating the model as a shared plan.
A first draft can help start the conversation, but there is no universal completion time. Complex programs may need substantial consultation and revision. Do not skip that work to meet an arbitrary “one afternoon” promise.
Connect the model to measurement without overloading the diagram
Keep the main visual readable. Put indicator definitions, sources, timing and responsibilities in a companion table or data dictionary. The model and measurement plan should refer to the same outcomes, but they serve different reading needs.
Scroll horizontally to see all columns →
| Model question | Possible evidence | Limit to retain |
|---|---|---|
| Was the course delivered? | Delivery and completion records | Completion is not proof of skill use |
| Could participants demonstrate the method? | An appropriate exercise and assessment method | Performance in an exercise may differ from workplace practice |
| Was the method used later? | Suitable follow-up or operational evidence | Coverage, self-report and opportunity to apply affect interpretation |
| Did professional practice improve? | A suitable evaluation of the broader outcome | Other influences may explain part or all of the change |
Not every source is a participant survey. Inputs and outputs may use administrative records, while organizational or wider outcomes may need other data. Person-level matching is appropriate for some questions, not a requirement for every box.
A result is not the same as proof of the whole model
Fictional example. If 80 people complete a course, that supports the completion measure. If 50 answer a later survey and 30 report using the method, the report should state 30 of 50 respondents with the relevant eligible-cohort coverage. It should not imply that all 80 applied it successfully.
Even a well-measured increase does not automatically establish causality. The evaluation needs to consider alternative explanations and use methods appropriate to the question. A source-linked record makes evidence inspectable; it does not supply a counterfactual.
Continue to outcome evaluation for assessing results and theory of change for a fuller discussion of the reasoning.
Logic model, theory of change and logframe
Scroll horizontally to see all columns →
| Tool | Useful role | What to avoid assuming |
|---|---|---|
| Logic model | A clear representation of program components and intended relationships | That it must be strictly linear or cannot include assumptions |
| Theory of change | An explanation of how and why change is expected in context | That every program needs the same six-box layout |
| Logframe | A structured matrix of results, indicators, evidence and assumptions | That completed cells prove the pathway works |
These tools overlap and terminology varies. Choose the representation that helps the team reason and communicate. Use the theory of change template for a more detailed reasoning worksheet and the logframe template for the monitoring matrix.
Use shared outcomes without forcing identical local activities
A program operating across schools, chapters or service sites may have a common intended outcome but different local activities. Show those differences instead of making the model imply uniform delivery.
Agree the limited shared definitions needed for valid comparison and map local collection to them. Keep additional local questions where they support local decisions. Incompatible units, observation periods or assessment methods should not be combined simply because the outcome headings match.
Maintain the model as the program learns
Review the model when important evidence, activities or context changes. Keep a version and a short explanation of what changed and why. A static diagram can remain the approved reference while operational evidence continues to develop.
The ownership challenge is keeping that reference connected to collection and analysis without repeated reconstruction. Sopact supports connected records, quantitative context and reviewed qualitative analysis. Staff own the definitions and judgments; automated processing can assist with applying approved categories and rerunning eligible analysis after revisions.
See the qualitative and quantitative workflow comparison for the practical staff-effort argument. Include setup and review in the estimate rather than treating automation as the removal of all work.
Use the model to write a clearer report
Explain what was delivered, which changes were observed, what remains uncertain and what the team will do next. Do not present the diagram's intended outcomes as achieved results.
Use How to Write an Impact Report and report examples to connect the program story with evidence. Keep the full measurement method available alongside the readable summary.
Watch: understand the reasoning behind the model
This introductory theory-of-change video provides context for the links between activities and intended change. Use it alongside the template, including the assumptions and evidence questions.
Frequently asked questions
Can I use this logic model template in Excel?
Yes. Download the CSV and open or import it in Excel or Google Sheets. Replace the starter content and save your working version in the format you prefer.
What is the difference between outputs and outcomes?
Outputs describe direct delivery, such as sessions or completions. Outcomes describe intended changes, such as using a skill. Evidence of delivery does not automatically establish the later change.
Can a logic model include assumptions?
Yes. Assumptions and context can appear in the model or accompanying notes. They are not exclusive to a theory of change.
Must a logic model be linear?
No. A simple chain is one useful layout. Complex programs may need branches, feedback relationships or accompanying explanation.
Is a logic model useful before data is collected?
Yes. It helps clarify design and identify evidence needs. Later review should distinguish the intended pathway from observed results.
Does connected data prove the model is correct?
No. It helps inspect evidence. Judging the proposed causal links requires suitable evaluation and consideration of alternative explanations.
Choose your next step
King Center
Related practice: connecting program feedback to learning. The logic model is a fictional teaching example, not a result from this customer story.
Read the customer story →