Ask most teams what’s wrong with their feedback program and they’ll point at the survey - too long, too generic, response rates dropping. That’s real, but it’s rarely the actual failure point. The more common failure looks like this: the survey goes out, responses come back, someone builds a dashboard or a deck, the team nods at it in a meeting, and then the next cycle starts before anything changes. Collection worked. Reporting worked. Nothing happened in between.
Earlier this year, we finished a three-year rebuild of SurveyRock from the ground up (the full story is here). Since then, we’ve kept building toward this exact gap: not more ways to ask questions, but better ways to figure out which answers matter and make sure a person is actually on the hook for doing something about them. Two pieces shipped this month that we think are worth walking through, plus a layer underneath both that doesn’t show up in a screenshot but matters just as much if you’re running a real program with real stakes.
Which of the things you asked about actually matter
A standard NPS or CSAT program asks a dozen or twenty questions alongside the core score. Somewhere in there is the thing that’s actually dragging the number down - but finding it usually means crosstabbing one question against the outcome at a time, eyeballing the differences, and hoping you picked the right pair to check first.
Key driver analysis looks at every eligible question at once and ranks which ones move together with the outcome you’re tracking - NPS, a rating, a slider score - instead of you guessing which pair to check next. It’s built specifically for survey data, which is almost always correlated in ways that trip up a naive approach: people who rate your support highly tend to rate delivery highly too, and a method that doesn’t account for that will hand you a ranking that looks confident and isn’t.
The part we spent the most time on isn’t the ranking itself - it’s what the feature does when the data doesn’t support one. Too few complete responses, two questions answered almost identically, an outcome nobody actually varied on: instead of returning a ranking anyway, it says so. We’d rather tell you we can’t answer than hand you a number you’d act on and shouldn’t. And every result comes with its caveats attached, not buried in a methodology page you’d have to go find - low sample size on a specific driver, incomplete overlap between two questions, a driver where nearly everyone gave the same answer. One honest note: this tells you which questions move together with your outcome, not which ones cause it. A ranked list is a place to start looking, not a regression model, and we’d rather say that plainly than let the ranking imply more than it proves.
Then something has to happen
A driver result, a theme that keeps coming up, a detractor’s answer everyone agrees someone should follow up on - on their own, these are still just findings. They sit on a dashboard until the next cycle replaces them, and the program running them looks a lot like a reporting exercise dressed up as action.
Actions is what we built instead: a way to raise a follow-up directly from a theme, a key driver result, a suggestion in an executive summary, an insight, or a single response - and give it an owner, a status, and a due date. The evidence it came from stays linked, so whoever picks it up sees the actual finding, not a paraphrase of it. Assign one to a teammate and they get an in-app notification and, by default, an email; a daily digest lists anything due today or overdue, so it doesn’t wait for someone to remember to check. And because we capture the relevant metric the moment you raise the action, you can look back later and see whether the number moved once the work was done - always labeled as movement, not proof, because a lot can change between two survey cycles besides the one thing you fixed.
It’s on every plan, not gated to whichever tier happens to include “advanced” features this quarter. Free accounts can keep three open at a time; every paid plan is unlimited. The reasoning is simple: a lot of feedback work happens one person at a time - someone running a program without a dedicated team behind them - and the value of “someone owns this and it doesn’t disappear” shouldn’t need a paid seat to unlock. It’s useful on day one, before you’ve assigned anything to anyone.
The part that doesn’t show up in a screenshot
Neither of the two features above matters much if the wrong person can see data they shouldn’t, or if provisioning access to a growing team means someone hand-editing a spreadsheet of who has what. So alongside the product work, we shipped the access-control layer underneath it: custom roles instead of a fixed set of presets, groups that can hold permissions the same way an individual member can, per-user feature denials for the exception cases every real organization has, and a way to see exactly why a given person can or can’t see a given piece of data - not just a yes or no.
Contact fields can now be marked sensitive, and once marked, their values are withheld from anyone without the specific permission to see them - at every read path and at export, enforced from one chokepoint rather than trusted to each feature separately. And for Enterprise teams that provision access through an identity provider rather than by hand, SCIM 2.0 support means Okta or Entra can create, update, and deprovision workspace members directly, with the usual guarantee that deprovisioning someone reassigns their surveys instead of orphaning them.
None of this is exciting in a demo. It’s the kind of work that matters the first time a security review asks how access actually works, or the first time a workspace grows past the point where everyone just knows who’s supposed to see what. We’d rather have built it before it was the thing standing between a team and using the product, not after.
What this adds up to
None of these are dramatic on their own. Taken together, they’re the difference between a tool that helps you ask and report, and one that helps you figure out what matters and follow through on it - with the access controls to run it as a real program rather than a side project.
If you want to see either feature directly: Key Drivers and Actions both have their own pages, with more detail than fits here. And if you’re already running a program on SurveyRock and want to raise your first action from something you’re looking at right now, it’s live - no waiting for a future release.