How to Analyse Open-Ended Survey Responses Without Losing the Community's Voice
Open-ended feedback is messy because communities are complex. That is the point.
Finn Clark
Customer Success Manager
Open-ended responses are where the most valuable community insight often lives. They are also where analysis can go quietly wrong, especially when teams are tired, under pressure, and trying to turn hundreds of individual comments into a neat report by Friday.
The first mistake is treating open-text feedback as a volume problem. Yes, there may be hundreds or potentially even thousands of comments, but the real challenge is interpretation. A short response can carry a deeply important concern, while a long response can repeat something already captured elsewhere. Good analysis starts by protecting the meaning of each contribution before trying to summarise the whole dataset.
“These submissions were used to identify and classify relevant themes using qualitative theme analysis.” — Stats NZ, Sexual orientation: Findings from public consultation
A practical workflow begins with cleaning and organising the data. Bring responses into one place, remove duplicates where appropriate, separate administrative noise from genuine input, and keep basic source information attached. This matters because a theme without its source is just a claim. A defensible analysis should always let a reviewer trace an insight back to the words that shaped it.
From there, teams need a clear approach to coding. Deductive coding is useful when you already have known project objectives, risks, or decision criteria. Inductive coding is useful when you want the community's language to shape the themes. In practice, strong consultation analysis often uses both: a starting framework for consistency, with enough flexibility to let unexpected issues emerge.
“key messages from all submitters were extracted and categorised for ease of additional analysis.” — New Zealand Ministry of Health, Update of the New Zealand Health Strategy: Analysis of submissions
The review step is where nuance is protected. Themes should be checked for edge cases, minority perspectives, and emotionally strong comments that might otherwise be flattened into neutral language. This is also where teams should test whether sentiment, frequency, and importance are being treated as separate things. The loudest theme is not always the most important, and the most important concern is not always the most common.
Finally, analysis should feed reporting, not disappear into it. When writing the final report, show the theme, explain what supports it, include representative evidence, and be clear about caveats. A good report does not pretend the community spoke with one voice. It shows decision-makers where there was agreement, where there was tension, and what that means for the decision ahead.
Open-ended feedback is messy because communities are complex. That is the point. With the right workflow, teams can move faster without stripping away the human detail that makes consultation worth doing. Tools like Communiti Analysis help by keeping themes, evidence, sentiment, and source material connected, so the final insight is not just efficient, but something the team can stand behind.



