A practical six-stage approach
The exact work differs by project, but recurring research can usually be structured around six stages:
1. Define the question and the value
Before discussing questionnaires or dashboards, define what the research should make possible.
What does the organiser need to understand? What should a participant learn about its own organisation? Is the goal market insight, comparison, member feedback, an assessment result or a combination?
The output matters at this stage too. If every participant should receive a relevant benchmark report, the data model has to support that from the beginning.
A clear purpose also helps remove questions that are interesting but not useful.
Define who will use the result
Many C2C programmes have more than one audience.
An association may need aggregated sector insight while participating organisations need individual comparisons. A consultant may need a client report while the client needs a dashboard. An assessment may need immediate participant feedback and structured information for later follow-up.
These audiences do not necessarily need the same output or the same access.
2. Design the research model
Once the purpose is clear, the substantive research structure can be designed.
This includes definitions, questions, variables, calculations, reference groups, validation rules, periods and the logic behind the results.
The customer may already have this methodology. C2C can also contribute benchmarking and research experience where useful.
The division should remain explicit: subject-matter expertise belongs with the party that actually owns it.
Design backwards from the result
A useful way to design research is to start with the output.
What should the participant see? Which comparison or conclusion must be supported? Which data are needed to calculate or explain it?
Working backwards can prevent the questionnaire from becoming a collection of unrelated questions.
For assessments, the same principle applies: define the useful feedback first, then determine the scoring and questions needed to support it.
Choose the right comparison
Benchmarking requires more than calculating an average.
The design may need total-group comparisons, reference groups, historical development, consistent panels or another agreed reference point.
Not every project needs all of these.
The comparison should be chosen because it improves interpretation, not because the platform can calculate it.
Plan confidentiality and access early
Who may see individual submissions? Who may validate them? Does the organiser need company-level data, or only aggregated results? Which outputs may be exported?
These questions should be answered before launch.
For some research programmes, the association has access to individual member data because it performs the validation. In other models, such as VvDN's market monitor, the association deliberately does not access individual submissions.
The access model should follow the purpose of the research.
3. Configure the Survey Tool
The research model is then translated into the Survey Tool.
This can include questionnaires, data imports or connections, validations, calculations, comparison groups, dashboards, reports, emails, reminders and participant roles.
Configuration is not the same as forcing a project into a standard template.
The objective is to make the agreed research process repeatable without losing the methodology behind it.
Use the simplest suitable data route
Some information is best entered in a questionnaire. Other data already exist in a customer's operational system, AMS or another source.
Where appropriate, C2C can use structured imports, endpoints or tailored integrations to bring those data into the research process.
The right solution is the one that reduces unnecessary work while preserving data quality and explainability.
Build validation into the process
Data quality should not depend entirely on a final manual check.
Input rules, plausibility checks, relationships between fields and comparisons with earlier periods can help identify information that needs attention.
But automated validation does not replace substantive judgement.
A value can be unusual and still be correct.
4. Test the complete participant journey
Testing should cover more than whether a questionnaire opens.
A realistic test follows the complete process: invitation, access, data entry or import, validation, calculations, comparison, dashboards, reports and communication.
Different participant types and edge cases should be tested where the research model creates different paths.
The purpose is to find both technical issues and methodological surprises before live data make them harder to correct.
Test the output with realistic data
A report can look correct with one simple test record and still fail when the underlying data vary.
Testing should therefore include realistic differences between participants, missing or exceptional values and the range of outputs the research is expected to produce.
For a benchmark, check whether the comparison remains understandable. For an assessment, check whether the feedback matches the configured scoring logic.
5. Run the research
Once launched, the work shifts from design to operation.
Participants are invited, progress is monitored, reminders are sent, submitted data are reviewed where required and results are released according to the agreed process.
The amount of C2C involvement depends on the collaboration model.
Three ways to divide the work
Customer-operated - The customer manages participants, content, validation and outputs using the Survey Tool. C2C provides the technology and support where needed.
Shared operation - The customer retains substantive control while C2C supports selected activities such as implementation, data collection, validation, reporting or process management.
C2C-operated - C2C operates a larger part of the recurring process. The customer retains ownership of the research purpose, methodology where applicable, and stakeholder relationship.
The model can change over time
A customer may need more support during the first implementation and become more independent later.
The opposite can also happen: a customer may understand the system well but choose to outsource operational work because internal capacity is limited.
The objective is not to force every customer into the same service model.
It is to make the research sustainable.
6. Learn, improve and repeat
The end of one research period is the starting point for the next.
Which questions created confusion? Which validation rules identified real issues? Which reports were useful? Did definitions need clarification? Has the market changed enough to require a new variable?
Recurring research improves when these lessons are incorporated deliberately rather than rebuilding the process from memory each year.