The Loop's first principle is a posture, not a schedule: measurement is continuous, not annual. You don't design the perfect system up front — you start with the step that already pays and add one data-collection step at a time.
What you will build: Write a one-page plan connecting a decision, its evidence and an owned action.
To build a useful learning cycle, choose a decision your team makes repeatedly, identify the evidence needed for it, and schedule a review while action is still possible. Assign an owner to both the review and the response. Then check what changed and adjust the next collection round.
In our service example, the decision is which unresolved issues need follow-up and which recurring barriers need a wider service change. A monthly check-in may serve that decision. An urgent service problem needs a separate response route; it should not wait for the next survey analysis.
A complete small cycle is more instructive than a large collection exercise with no plan for using the results. Start where a real decision and available evidence make the test useful. That might be a member return, service check-in, application review or portfolio reporting cycle; intake is not always the best starting point.
If several sites or chapters contribute, do not impose an identical questionnaire merely to make aggregation easier. Agree on the limited core required for the shared decision: for example, reporting period, service category, resolution definition and the unit being counted. Let teams retain useful local questions.
Reuse suitable registration details instead of asking for them in every survey. Refresh information such as role or location when it changes. Keep a data dictionary that explains definitions, valid values, missing data and which local fields can be mapped to the shared core. Different questions are comparable only when the evidence supports the mapping.
The team records 200 eligible accounts, 120 responding accounts and 84 reporting resolution. It reviews unresolved responses with appropriate permissions, examines the comments for recurring barriers and asks the service owner to select a next action. It also records the 80 accounts without a usable response as missing evidence.
Suppose several comments mention confusing setup instructions. That is a finding to inspect, not proof that rewriting the instructions will solve every issue. The team can test clearer instructions, define who receives them and plan a suitable follow-up. It should distinguish an operational improvement test from a study intended to establish causal effects.
Record the wording, category and calculation versions used for each round. If “resolved” gains a new meaning, do not silently join old and new rates as if nothing changed. Assess whether older records contain enough evidence to apply the new definition; otherwise disclose the break.
Sopact’s connected collection and analysis approach can help reduce repeated exports, coding and reconstruction. Test the work that remains: exception handling, unclear responses, permission decisions and the review of AI-assisted interpretations.
Draft six lines: decision; existing evidence; new collection; review date; action owner; follow-up check. Ask a colleague to identify one missing assumption. In the next lesson, use the service example to check whether your reported figures can be reproduced correctly.
Start with a decision your team needs to make. Decide what information belongs together, how you will check it, and who is responsible for acting.
See context in action →
