Because projects sit on unspoken assumptions. The ToC makes those assumptions explicit and testable: what you expect to change, for whom, why, and under what conditions, so you can look for evidence, not just intentions.

Logframes assume linear chains. Your ToC is systems-based: the same action can touch multiple domains; outcomes can be positive and negative; and risks are linked directly, so it reflects how real change unfolds.

• Stage 1 – Actions & responsibilities: what you will actually do, by whom, by when. • Stage 2 – Outcomes for stakeholder groups: what may change in people’s lives (including potential harms) and why. Separating doing from changing keeps strategy clear and measurable.

Because “community” hides different realities. You select a specific group (e.g., women in Village A, youth members, field staff) and describe what should change for them, keeping people, power, and context at the centre.

Themes and sub-themes in the ToC are pre-mapped to relevant standards (e.g., SDGs, ESG, Carbon standards). One ToC entry can later be read through several lenses without extra rework, which is useful for assurance and external reporting.

They draw from coded standards, research, and practice; and all contain citations about their source. Indicators are checked against a SMART lens; where no benchmark exists, the rationale is explicit. You get structure you can trust without having to read every standard.

Project-level captures the big picture across all sites. Site-level reflects local realities and differences. The platform supports both, so you can compare patterns without losing local nuance.

For site-level ToCs, yes - there’s a lightweight consultation plan step (who, how, when, ethics). It keeps participation intentional and makes it easier to bring lived experience into design, not just into monitoring.

Stage-2 outcomes (by stakeholder + sub-theme) drive the survey builder (suggested questions/indicators), push risks into the Risk Register where relevant, and appear alongside results in the reporting portal, turning the ToC into a working spine.

It’s living infrastructure. Revisit it at agreed intervals (e.g., annually): add outcomes or risks surfaced by surveys and feedback; retire what no longer fits; document why you changed it. That is how learning becomes visible and defensible.

The platform uses “outcome” as the working term (change experienced by a stakeholder group) and maps entries to external language where needed. The priority is clarity on who changed, in what way, and why, not winning a terminology debate.

Start with a short working session: pick 2–3 priority stakeholder groups, list the actions you plan to do with them (Stage 1), then draft 3–5 outcomes per group (Stage 2), including any plausible harms. Your Account Manager will facilitate and keep it right-sized.

They’re the bridge between practice and assurance. You choose the domains that fit your work; under the hood they link to indicators and external frameworks, so one coherent ToC fuels surveys, risk, and multi-audience reporting.

They run the kick-off and review sessions, help separate actions from outcomes, spot gaps and over-claims, and make sure site-level participation is feasible. The result is a ToC your team owns, and that the platform can actually use.