Make the unit unambiguous
W-8 shows why a count of bags cannot automatically be compared with kilograms. Document what the count represents and which conversion, if any, is approved for that item and context. A conversion valid for one product may not apply to another.
For services, define units such as completed visit, accepted task or service hour. State exclusions and the source used. A scheduled hour and an actual delivered hour are different observations.
Preserve original units with any calculated value and the conversion version. That allows a reviewer to inspect the calculation rather than trusting a transformed total alone.
How different instruments support a common comparison
Start with a question the participating teams genuinely share. For each required field, define the unit, eligible population, period, response options, missing states and calculation. Record how each local field maps to that definition, who reviewed the mapping and which version applies.
Partner A exports a delivery log; Partner B submits a form and supporting document. Agree the partner identifier, relevant transaction or site identifier, reporting period, unit and status meaning. Keep the source records and local operating detail.
For example, delivered can map to site accepted only when the source records the receiving site’s acceptance under the agreed rule. A dispatch confirmation alone does not support that mapping. Preserve the original status and ask for acceptance evidence; similarly, retain bags separately from kilograms until a documented conversion applies.
Before combining records, check coverage and overlap as well as definitions. State which teams supplied usable evidence, which are pending and whether the same person or transaction appears in more than one source. Report separate results when populations, methods or permissions make combination inappropriate.
In a Sopact workflow, the shared definitions provide context for analysis while the connected record retains local responses, files and history. Your team can review a source-to-field mapping instead of redesigning every local survey. Test that configuration with sample records before relying on a combined result; a data dictionary cannot supply missing evidence or make incompatible measures equivalent.
Define the status that supports the decision
Separate submitted, received, inspected, accepted, disputed and resolved where those states matter. Give each status an owner and the evidence required to use it.
An acceptance rule should fit the operational task. Do not copy a safety or quality threshold from a fictional exercise into a regulated process. Use the organization’s responsible experts and applicable standards for those requirements.
If a partner uses a different term, map it explicitly and test whether the meanings really align. Shared labels can conceal different local processes.
Keep broader claims within the evidence
A confirmed delivery supports a delivery claim. It does not by itself demonstrate improved learning, health, livelihoods or client outcomes. Those questions need additional collection and an appropriate evaluation approach.
Compare partners only where their work, definitions and opportunities are sufficiently alike for the intended decision. A high exception count may reflect better reporting rather than worse performance.
Use the dictionary during collection and review. When a definition changes, record the effective date and assess whether the next report can still compare with prior periods.
Work through the Relay example
This is a fictional teaching example. Adapt the fields and rules to the question your own workflow needs to answer.
| Definition | Include | Comparison limit |
|---|---|---|
| Quantity | Unit and approved conversion | Do not infer bag weights |
| Timing | Dispatch, receipt or acceptance date | Do not mix event clocks |
| Status | Owner and evidence requirement | Closed is not always accepted |
| Outcome claim | Required supporting evidence | Delivery is not wider impact |
Build this part of your plan in more detail
These lessons address the next practical questions in this module. Choose the detail your workflow needs, then return to complete the exercise.
- Impact Metric Definitions: A Practical Worksheet and Example
Define the common unit before aggregating partner submissions.
- Turn Reporting Requirements into Evidence: A Practical Mapping Guide
When audiences request different reports, map each requirement to an approved measure, source and unresolved gap.
More practical questions in this module (1)
- How to Build a Data Dictionary for Program and Impact Data
Define the units, statuses and rules behind partner comparisons.
Add this part to your plan
On workbook page 5, define one goods or service unit and two acceptance statuses. State a claim that your evidence does not support. Map one local field to a common definition. Give one example that must remain separate.
Download workbook (fillable PDF)Compare with a suggested answer
The definition preserves original units and any approved conversion. Acceptance has a source owner. The report states operational completion without claiming downstream outcomes that were not measured.
Self-check: Could two partners interpret the same request consistently?
Questions you may have
Can a single conversion be used for all suppliers?
Only where it is appropriate and documented for the items and reporting basis. Do not assume a universal conversion.
Do more reported exceptions mean worse performance?
Not necessarily. Reporting coverage and detection practices affect the count. Interpret it with context.
Apply the method to your work
Use the five-part plan to assess the sources, analysis and permissions your team needs. The solution page shows where a connected platform can support that workflow.
Explore the partners & suppliers solution →