Members do not answer surveys because head office asked nicely. They answer when the answers come back to them — which makes response rate a governance decision, not a survey-design one.
Record shape D of the four in Connected Data Intelligence — a network where each member sees their own part. It leans hardest on checks 01 Self-driven, 03 Volume and 07 Assistant.
A global body with more than ninety member countries had been trying to get its annual member survey going for years. The survey itself was not the problem — it existed, and it was thorough. Roughly seventy-five to eighty questions, sent out once a year, to people who run national organisations in their spare time.
It never took hold. And the reason it never took hold is the thing most networks get wrong, so it is worth saying early: members do not answer surveys because head office asked nicely. They answer when the answers come back to them.
Because the data only travels one way. A member fills in eighty questions, the answers go to the centre, and a report appears months later describing the whole network in general terms. Nothing comes back that helps that member do their own job. So next year they deprioritise it, response drops, the report gets weaker, and the year after that even fewer people bother. This is not apathy. It is a rational response to being asked to do unpaid data entry for someone else's report.
The same body ran a satisfaction survey at its events for years. Five questions. One year they expanded it to around twenty and, in their own words, got horrible results, because nobody would fill it in. A separate survey after one event drew 285 responses from 1,600 competitors — enough to say something, not enough to stand behind.
Read those two facts together and the usual conclusion is "keep surveys short." That is the wrong lesson. Length was what broke the twenty-question version, but shortness is not what would have fixed the annual one. What fixes the annual one is giving each member something back.
The change that makes a member network survey work is not in the questions. It is deciding, before anything goes out, what each member gets to see afterwards.
At minimum, a member should be able to open their own answers — everything their organisation submitted, this year and every previous year, without emailing anyone for a spreadsheet. That alone changes the transaction. Filling in the survey stops being a favour and becomes how a member keeps their own record current.
The stronger version adds comparison: this member can see where they sit relative to the network without seeing which other member is where. "You are in the top third on this, below the middle on that" is genuinely useful to somebody running a national organisation, and it is the single most reliable reason they will answer next year. It is also perfectly safe, because it reveals a position, not a peer.
Networks tie themselves in knots over access because they treat it as one question. It is three, and they have different answers.
| The decision | The usual right answer |
|---|---|
| What can a member see of their own data? | All of it, always, without asking. This is the return path, and hedging on it defeats the point. |
| What can a member see of other members? | Their position against the group, never another member by name. Ranked lists with names attached will cost you honest answers permanently. |
| What can the centre see? | Everything — with named exceptions. Some fields are sensitive enough that even the centre should hold them narrowly, and specific figures are often better shown as a band than an exact number. |
Write those three down before the first survey goes out. Every argument you will have in year two is really an argument about one of them, and it is much easier to settle in advance than after somebody has seen something they should not have.
An eighty-question survey once a year has a structural problem: most of the answers do not change annually, but the member has to re-enter all of them anyway, which is exactly why they put it off.
The alternative is to leave it open all year and take a snapshot on a fixed date. A member updates the two things that changed in March when they change; on the first of the month you nominated, the system records where everything stood. Comparison across years still works, because you are always comparing the same date. The annual scramble disappears, and so does most of the burden that was driving the response rate down.
The one discipline this requires: the snapshot date is fixed and published. If it drifts, your year-on-year comparison quietly stops being like-for-like — which is check 04.
Research training teaches sampling, and for most research that is right. A member network is one of the cases where it is wrong.
With ninety members, a sample is not a sample — it is a hole. If twelve countries do not answer, you do not have a representative subset, you have a report that cannot say anything about twelve countries, and those twelve are very likely the ones with the least capacity, which is exactly the group your network exists to support. Non-response in a small population is not statistical noise. It is systematic, and it removes the members you most need to hear from.
So the target is everyone, and the number to watch is not the response rate but the list of who is missing — by name, updated as answers arrive, so somebody can pick up the phone while it still matters.
For a network of ten or fifteen members, that genuinely works and you should just do it.
It breaks at scale, and in a specific order. Somewhere around twenty or thirty members, sending each one their own view by hand becomes a job nobody has time for, so it stops happening — and the return path was the thing holding the response rate up. Then representatives turn over and the new person has no access to what their predecessor submitted, so they start from scratch and the history is effectively lost even though you still hold it. Then a second language enters the network and the comparison rules have to hold across both. And if members upload documents — a strategic plan, an annual report — those sit in a folder while the survey answers sit in a table, and nothing can read them together.
What a system is for here is narrow: giving ninety members their own live view without ninety manual exports, keeping the member's history attached to the member rather than to whoever happened to be their representative that year, and letting somebody ask a question of the whole network in plain language without waiting for the centre to build a report. Your team still decides the questions, the access rules and the snapshot date.
Use: Three members, two snapshot dates, and one member whose representative changes between them. Include one member who answers only half the questions.
Pass: Each member can open their own history without help. The new representative sees what their predecessor submitted. No member can see another member by name. The half-finished member shows up on a named list of who is missing what.
Fail: Anyone at the centre has to export and email anything for a member to see their own data.
Give them their own data back, and their position against the group. Reminders and shorter surveys help at the margin; the return path is what actually changes behaviour, because it makes answering useful to the member rather than only to the centre.
Their position against the group, yes. Named comparison, no. The moment members believe a ranked list with names on it will circulate, the honest answers stop, and you cannot get them back.
For anything that changes slowly, yes — the member updates only what moved rather than re-entering everything. The condition is that the snapshot date is fixed and published, otherwise you lose like-for-like comparison across years.
Nothing should break. The history belongs to the member organisation, not to the individual, so a new representative should open the record and find everything their predecessor submitted. If your set-up ties data to a person's login, plan for this before it happens.
Because in a population of ninety, the members who do not answer are usually the ones with the least capacity — the ones your network exists to help. Their absence is not random, so a sample quietly excludes exactly the group you most need to describe.
No, and if you do, something is wrong. Members should answer a survey and read their own results. Nobody in the network should have to learn how to build a report, and nobody should have to write instructions to a chatbot to get an answer out of their own data.
The uncomfortable thing about member surveys is that the fix is not in the survey. Networks spend years shortening questions, adding reminders and rewording invitations, and response keeps sliding — because none of that addresses the actual bargain. Filling it in has never once made a member's own job easier. Build the way the answers get back to them, and the response rate mostly takes care of itself.
Next: Back to the eight checks
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Try it in Sopact →
