Reading survey results without seeing individual responses

When you send a survey to your network, you never open a spreadsheet of who answered what. You open a question-by-question breakdown: a count of how many people answered, and, once enough of them h…

7 min read·Updated July 14, 2026
On this page

What this article covers

When you send a survey to your network, you never open a spreadsheet of who answered what. You open a question-by-question breakdown: a count of how many people answered, and, once enough of them have, a bar for each answer option showing how the network split. This article explains exactly how that breakdown is built, why it sometimes isn't there yet even after responses have come in, and why that gap is a deliberate privacy floor rather than a bug.

This is the same privacy boundary that runs through all of HQ: memberships own their own business data, and HQ works from aggregates. Surveys is one of the clearest places to see that boundary in action, because you can watch a question move from "count only" to "full breakdown" as more of the network answers.

Where to find it

Open Broadcast from the HQ sidebar, then the Surveys tab in the pill strip under the page title (hq.verinode.ai/surveys loads it directly). Click any survey tile to open its detail modal, that's where the per-question breakdown lives. Every HQ user, admin or not, can open a tile and read its results; only admins can author, send, or close a survey. For how to build and send a survey in the first place, see Surveys: multi-question network pulses.

How a response becomes a result

An operator answers a survey from their own IQ surveys section. That answer is never written straight into anything HQ can query. On a nightly schedule, a network rollup reads every response submitted since the last pass, tallies them up per question, and writes back only the tallies, a per-question count of respondents and, for most question types, a distribution of how many people chose each answer. Nothing about who answered, or which answer any one person picked, is part of that write.

That's why a brand-new response doesn't appear in the detail modal the instant someone submits it. The modal is reading the rolled-up numbers from the last overnight pass, not a live feed of individual answers. If you send a survey and check back an hour later, the response count may not have moved yet even though someone already answered; it will show up on the next pass.

This also means HQ-side code has no path to the raw answers at all, by design. The only bridge between an operator's individual response and anything HQ can see is that nightly aggregation step, and it never carries an operator's identity or their answer verbatim past that point, only the counts.

What each question block shows

Open a survey's detail modal and each question renders as its own block: the question's label, its type and whether it was required or optional, and the number of responses received so far, for example "3 · required · 14 responses."

Below that, one of three things happens, depending on the question type and how many people have answered:

  • A response count with no breakdown yet. If nobody has answered a given question yet, the block reads: "No responses yet. These counts update on the next pass once operators answer from their IQ surveys section." That just means the next nightly rollup, there's nothing for you to configure or trigger.
  • A count-only message, breakdown withheld. Once at least one person has answered but not yet enough to clear the respondent floor (see below), the block reads: "Response breakdown stays hidden until at least [N] operators answer, so individual responses can't be identified. [X] of [N] so far." You get the count, not the split.
  • The full breakdown. Once enough operators have answered, each answer option gets its own row: the option label, a horizontal copper progress bar sized to its share of responses, and the count and percentage written out, for example "Yes · 9 (64%)." Rows are sorted alphabetically by answer label, not by count, so the order stays stable as more responses come in.

Rating and Yes/No questions get a full histogram, one row per value or option, once they clear the floor. Free-text questions never show their content to HQ at all, on any question count, regardless of the floor; the only thing HQ ever sees for a free-text question is how many people wrote something in, not what they wrote.

The respondent floor, and why it exists

Before a question's breakdown appears, enough distinct operators have to have answered it. Below that floor, Verinode deliberately does not compute or store the per-answer split at all; only the response count is kept. This is the same reasoning behind small-sample suppression in any statistics practice: a distribution built from a couple of responses can put a name to an answer just from context (if it's an owner of a small network and their operations manager both know only they two answered, "1 said No" tells you who). Waiting for a wider crowd removes that risk before the numbers ever reach HQ, rather than trying to redact them after the fact.

The floor is a flat number, the same for every survey sent within your network. Verinode does not publish the exact figure here because floors like this are reviewed as part of the platform's broader anonymization policy and can be tuned network-wide over time; what stays constant is the guarantee, breakdowns never surface below a level where a response could reasonably be attributed to one person.

Two things follow from that:

  • The count is never withheld, only the split. You always know how many people answered a question, even while the breakdown is hidden. That count is not identifying on its own.
  • A late responder can tip a question over the floor mid-survey. If a question is sitting at "X of N so far" and one more relevant answer comes in on the next nightly pass, that question's breakdown can appear where it wasn't visible the day before, while a sibling question on the same survey (if fewer people answered it) can stay count-only. Each question is judged on its own respondent count, not the survey's total.

Two different things that can look similar: network pulses and team templates

Every survey tile in the Surveys tab is one of two patterns, shown by a · template suffix on the status label:

  • Network pulse (no suffix): the survey HQ sent straight to every active operator. This is what this article describes, the detail modal shows the aggregated response breakdown described above.
  • Team template (suffix "· template"): a ready-made question set franchisees use to run with their own crews. HQ's view of a template tile never includes anything about how a franchisee's team answered it internally, not even in aggregate. All HQ sees is how many franchisees have adopted the template.

If you're looking at a template tile and wondering why there's no breakdown at all rather than a count-toward-the-floor message, that's the answer, templates don't feed HQ any response data because the responses were never sent to HQ in the first place.

Status and what it changes

A survey's status, shown at the top of the detail modal, doesn't change how results roll up, only what actions are available:

  • Draft: not yet sent, no responses possible yet.
  • Active: sent and accepting responses; an admin can close it early.
  • Closed: no longer accepting responses, either because its close date passed or an admin ended it manually. The last aggregated result stands; results don't disappear or reset when a survey closes.

How to use this in practice

Read a survey's results the same way you'd read any small-sample statistic: trust the count, and treat an early partial breakdown (right after the floor clears) as a starting read that firms up as more responses land on later nightly passes. If a question is still count-only days after sending, that's telling you something too, not enough of the network has weighed in yet, which is itself worth following up on through your usual channels rather than through the survey.

Verinode surfaces what the network told you in aggregate; deciding what to do with a result, whether that's a follow-up conversation, a policy change, or a new initiative, is on you.

Note

This is a description of the current Broadcast → Surveys behavior. Question types today are limited to rating scales, yes/no, and free text in the authoring flow; a checkbox (multi-select) type is supported by the underlying aggregation and would summarize the same way, one histogram row per selected option, once clear of the floor.

Tip

If you need a fast single-question read instead of a full survey, Polls, the tab next to Surveys, is a one-question pulse with a short auto-close window built for that. It rolls up through the same nightly process and holds the same respondent floor.

Data sources

  1. 1.Survey question counts and answer distributions. Aggregated nightly from your network's own survey responses.
  2. 2.Respondent floor methodology. Verinode's operator data-use and anonymization policy.
Was this helpful?