Participation isn't updating

You launched a survey, people are answering, and yet the participation number on your screen looks stuck, lower than you expected, or slow to move. This is one of the most common things Survey Admins ask about, and in almost every case there's a simple, benign explanation.

This guide walks through the real reasons a count can lag or look "wrong," how CultureMonkey actually counts a response under the hood, and a step-by-step way to diagnose your own case. By the end you'll be able to tell the difference between a genuine problem and normal, expected behavior.

How CultureMonkey counts a response

Before troubleshooting, it helps to know exactly what "participated" means in the product, because the definition explains most of the confusion.

Every time an employee finishes a survey and hits submit, CultureMonkey creates a submission record and stamps that submission's ID onto the person's answers and onto their participant row. Participation is then counted as the number of distinct submissions, not the number of people who opened the survey or typed something into it.

You can see this directly in how the platform tallies things. The participation rate is computed as submitted responses over total invited participants, where a "submitted response" is specifically one that has a submission ID attached. Answers without a submission ID are simply not counted.

This single rule - no submission ID, no participation - is the root cause behind several of the scenarios below. Keep it in mind as you read on.

Reason 1: Processing and indexing lag

The most frequent cause of a slow-moving count is simply timing. When an employee submits, the response doesn't appear in your reports the instant they click. It travels through a short pipeline first.

Here's the journey a submitted response takes:

1. 1The submission is saved - the response and its submission ID are written to the primary database the moment the employee submits.
2. 2It's indexed for analytics - the response is then indexed into the search and analytics layer that powers your reports and breakdowns.
3. 3It's rolled into your reporting counts - the analytics store aggregates submissions into the participation numbers you see on the Dashboard and in Reports.

Each hop takes a little time, and indexing runs continuously rather than instantly. During an active launch with many people submitting at once, it's completely normal for the visible count to trail the true count by a short interval and then catch up in a burst.

If you need the closest thing to a live figure during an active send, use the live participation view described in Track participation during a live survey, which is designed for exactly this moment. Detailed report breakdowns, by contrast, are built from the analytics layer and will always lag the live view slightly.

When lag is the answer

• The number is increasing, just not instantly.
• You're mid-launch with lots of concurrent submissions.
• The gap closes on its own after a short wait and a refresh.

When it probably isn't lag

• The count has been completely flat for hours despite people telling you they submitted.
• The number never moves no matter how long you wait.

If you're in the second bucket, move on to the reasons below.

Reason 2: Autosaved responses don't count

This is the single most common source of a genuinely confusing gap, so it's worth understanding well.

If you've enabled save-and-resume, employees can leave a survey partway through and come back later without losing their answers. To make that work, CultureMonkey autosaves their in-progress answers as they go. That's a great experience for the respondent, but it has an important consequence for your counts.

An autosaved answer is saved without a submission ID. In fact, the way the product recognizes an autosaved answer is precisely that it has answer data but no submission attached. Because participation only counts responses that have a submission ID, an autosaved-but-not-submitted response contributes nothing to your participation number.

In practical terms:

• An employee who opens the survey, answers eight of ten questions, and closes the tab has autosaved answers on file but is not counted as a participant.
• The moment that same employee returns, finishes, and clicks submit, a submission is created, the submission ID is stamped on, and they are counted.

So a survey can have plenty of "activity" - people have clearly started - while the participation count stays lower than you'd guess from the buzz. Those are your partial, autosaved responses waiting to be completed.

The fix here isn't technical - it's a nudge. Send a reminder to people who've started but not finished, and watch the count move as those partial responses get submitted. For the full picture of how save-and-resume behaves, see Let employees save and resume a survey.

Reason 3: The survey is excluded from the Dashboard

If your count looks fine inside an individual survey's report but the survey seems to be missing from the Dashboard (or from Dashboard-level rollups), the survey may be excluded from the Dashboard.

CultureMonkey lets you keep specific surveys out of the aggregated Dashboard view. This is a deliberate setting, often used for pilot surveys, one-off pulses, test runs, or surveys whose results you don't want blended into your headline organization-wide numbers. Excluded surveys are held in an account-level list, and Dashboard rollups are built from the surveys that are not on that list.

The important thing to understand is that exclusion affects where the data shows up, not whether it was collected:

• The excluded survey still collects responses normally.
• Its own report still shows its own participation count.
• It simply doesn't feed the aggregated Dashboard figure.

So if the Dashboard participation looks lower than the sum of your recent surveys, or a specific survey seems absent, check whether it's on the exclusion list before assuming responses went missing. For how the Dashboard aggregates surveys, see Read participation on the Dashboard.

Reason 4: A filter is quietly narrowing the count

Reports and participation views remember the filters you (or a colleague) last applied. A filter left in place is one of the easiest ways to convince yourself a count is broken when it's actually just scoped.

Common culprits:

• A demographic filter - team, location, department, manager, or a custom attribute - so you're seeing participation for one slice, not the whole population.
• A manager or reportee filter that limits the view to a single manager's team.
• A participation-band filter (for example, showing only groups below a certain participation percentage), which can hide fully-participating groups entirely.

Any of these will show a smaller number than the true total, and if you don't notice the filter is on, that smaller number looks like a stall.

1. 1Look for active filter chips or dropdowns - most participation views display the filters currently applied near the top.
2. 2Clear all filters or reset the view to its default, unfiltered state.
3. 3Re-read the count. If it jumps up, a filter was scoping your view all along.

Reason 5: Date-range and time-zone confusion

The last common cause is a mismatch between the window you're looking at and the window the data lives in.

Date-range filters. Some participation and over-time views let you constrain results to a date range. If the range doesn't cover when people actually submitted - or excludes the launch day - responses that genuinely exist will fall outside your window and won't be counted in that view. Widen the range to the full survey period and re-check.

Time zones. Your account, your browser, and your respondents may not all be in the same time zone. A response submitted late at night in one region can land on a different calendar date in another, which pushes it just outside a narrow "today" or "this week" range. Around midnight, and near the start or end of a survey window, this is an easy way for a handful of responses to seem to vanish.

A quick diagnostic checklist

When a count looks stuck, run through these in order. Most cases resolve within the first three steps.

1. 1Wait and refresh. Give the processing pipeline a couple of minutes, then reload. If the number is climbing, it was just lag.
2. 2Clear your filters. Reset the view to unfiltered and re-read the count. This is the highest-yield, lowest-effort check.
3. 3Check your date range and time zone. Make sure the window covers the full survey period, and remember that late-night submissions can shift by a calendar day.
4. 4Consider autosaved responses. If people have clearly started but the count is low, they likely have partial, unsubmitted responses. Send a reminder and watch it move.
5. 5Check Dashboard exclusion. If the survey's own report looks right but the Dashboard doesn't, confirm the survey isn't on the exclusion list.
6. 6Compare live vs. report views. During an active send, trust the live participation view for the freshest figure; reports lag by design.

app.culturemonkey.io/reports

Frequently asked questions

Someone told me they finished the survey, but they're not counted. Why?

The most likely reasons, in order: they autosaved but didn't actually click submit (very common), the response is still working through the processing pipeline (wait and refresh), or a filter or date range is hiding them from your current view. Clear filters and widen your date range first, then check whether they truly reached the submit step.

Do partially completed responses count toward participation?

No. A response counts only once it's submitted and receives a submission ID. Autosaved, in-progress answers are stored so people can resume, but they carry no submission ID and are deliberately excluded from participation, scores, and eNPS.

Why does the Dashboard show a lower number than the individual survey report?

Either a survey is excluded from the Dashboard (so its responses don't feed the aggregated figure) or a filter is applied to one view and not the other. The individual survey report is the source of truth for that survey's own count; the Dashboard is an aggregate across included surveys.

The count moved a lot all at once instead of gradually. Is that a bug?

No. Responses are indexed and aggregated in batches, so during a busy launch you'll often see the visible count catch up in bursts rather than tick up one at a time. It's the pipeline catching up, not an error.

Will resending or reminding people fix a stuck count?

It won't fix genuine processing lag (that resolves on its own), but it's exactly the right move when the real issue is autosaved, unsubmitted responses. A reminder prompts people to return and actually submit, which is what converts their saved progress into counted participation.

How current is the live participation view compared to reports?

The live view is designed to be as close to real time as possible during an active send, which makes it the best place to watch progress as it happens. Report breakdowns are built from the analytics layer and will always trail the live view slightly. See Track participation during a live survey.

Where to go next

• Watch progress in real time: Track participation during a live survey
• Understand autosave and partial responses: Let employees save and resume a survey
• See how the Dashboard aggregates surveys: Read participation on the Dashboard