Feedback trends rarely announce themselves. A CSAT score may drift a point or two per week, until three weeks later, when someone pulls up the dashboard for a quarterly review to find a huge data jump with no explanation. The same thing can happen with open-text feedback: a complaint that showed up in 3% of responses in January is showing up in 15% responses by March, but nobody noticed because it’s nobody's job to read each response every day.
So how can you close the feedback gap? Luckily, Sprig MCP makes it easy to set up a continuous feedback monitoring system by connecting Sprig MCP with Slack.
How does it work?
Sprig MCP is a Model Context Protocol connector that links Sprig survey data to AI assistants including Claude, ChatGPT, Gemini, and Copilot. When both Sprig and another tool are connected to the same AI client, you can run workflows at the same time. Like by connecting Sprig's MCP server to Slack in your AI client, you can set up a recurring check on an ongoing survey that will compare current feedback against a baseline and then post to a dedicated monitoring channel when there is a notable change or trend.
What will make this useful, instead of annoying, is the design of the trigger. You’ll need to configure the trigger in such a way that only real data shifts lead to notifications, so you can tell meaningful signals apart from noise and make sure the channel doesn’t get ignored or muted.
What you need before you start
- Sprig MCP enabled by a workspace admin (see here for step by step instructions).
- Slack connected to the same AI client.
- A study, or set of studies, with enough ongoing response volume to establish a baseline.
- A dedicated Slack channel for monitoring.
Designing the prompt
Before you write your prompt, there are a few key parameters you’ll need to define:
- What you're watching: e.g. a score like CSAT or NPS for a specific study, or a theme's share of open-text responses.
- A baseline: You’ll need to establish what "normal" looks like for the metric being measured by looking at the recent past, so a change is measured against something concrete.
- A trigger condition: e.g. a threshold breach, a percentage change, or a theme newly showing up at volume.
- A restraint rule: Post only when the condition actually fires, and only once per real event, not once per check.
- What every alert should include: e.g. the number, the sample size, a representative quote or two, or a link back to the study, so someone can decide whether (and how) they should take further action.
As for the actual prompt, let’s start with an example of how not to write it. It may be tempting to write something like this and call it a day:
"Check the [study name] study every day. If CSAT looks bad or people are complaining about the same thing a lot in the open-text responses, post it in #feedback-monitoring."
A prompt like this may seem to work at first, but will eventually break down. Here’s why:
- No comparison window: "Looks bad" is a different judgment call on every run instead of a consistent measurement.
- No sample-size floor: A handful of grumpy respondents could sound the alarm unnecessarily.
- No check against repeating itself: A dip that lasts a week gets re-announced five times.
- No format spec: The AI is free to write anything from a one-line ping to a rambling summary, which will make the channel more difficult to skim and evaluate.
Every one of those gaps would show up within the first couple of weeks. Now let’s look at an example of a well-designed prompt:
"Check the [study name] study. CSAT here is the percentage of respondents giving a positive rating. Compare the trailing 7-day CSAT to the prior 7-day CSAT. Only report if it's dropped by more than 5 percentage points AND both windows have at least 30 responses. Also check whether any open-text theme's share of responses has grown by more than 5 percentage points, comparing the trailing 2 weeks to the prior 2 weeks. Before posting, check the #feedback-monitoring channel for an existing message about this same study and metric posted in the last 14 days – if one exists and the situation hasn't materially changed, don't post again; if it has gotten worse or recovered, reply in that thread instead of starting a new message. When you do post, send it to #feedback-monitoring and include the metric, both time windows and their sample sizes, one or two verbatim quotes, and a link back to the study."
Every clause in this prompt is intentional. For example, day-over-day comparisons are too jumpy for most feedback volumes, while month-over-month is too slow to be useful as an early warning. A trailing 7-day window against the prior 7 days is a reasonable default, though the right size depends on how much volume a given study actually gets: a high-traffic in-product survey might support a 3-day window, while a lower-volume study needs closer to two weeks to say anything meaningful.
Using this well-designed prompt, if a score drops on Monday and stays down through Friday, nobody wants five alerts that all say the same thing. The fix is state-awareness: only surface genuinely new information, like a threshold crossed for the first time, a metric getting meaningfully worse than it already was, or a recovery back to normal. Since the underlying data connection reads information rather than remembering what it already told you, the prompt has to build that memory back in explicitly by having the AI check the channel itself for a prior alert before deciding whether to post again and updating an existing thread instead of starting a new one when nothing's materially changed.
A monitoring channel gets skimmed, not read closely, so in this prompt, the last clause is about optimizing. It spells out exactly what belongs in the message so the AI doesn't fill that space with a pile of ten quotes or a long narrative summary instead. Format left unspecified tends to drift toward "more," and “more” is exactly what defeats the purpose of a channel meant to be read in five seconds.
Choosing a cadence
The feedback monitoring cadence itself should not be included as part of the system prompt because something outside the prompt has to actually trigger each run. Most AI clients that support MCP connections offer some way to schedule a prompt to run repeatedly (e.g. a built-in scheduling feature), but the exact mechanism will vary by client, so you should check what your specific setup supports.
Once you've got a way to run the prompt on a schedule, a daily check is a reasonable starting point, as it’s frequent enough to catch something within a day or two of it starting but infrequent enough that it doesn't turn into a stream of near-identical updates. If you find that running the prompt once daily is too much or too little, you can always adjust as needed.
The takeaway
All you really need to make this type of feedback monitoring system work is an AI client with Sprig and Slack connected, a metric, a baseline, and a threshold. The craft is in tailoring your prompt to give you the right balance of frequency and content in the messages that get sent to your monitoring channel. Of course, you'll keep refining the prompt as you see which alerts are worth the ping and which aren't. But if you can get your prompt right, you’ll end up with a feedback channel people actually trust.
.png)
%20(1).png)