25 Questions for a Travel Agency Customer Satisfaction Survey Survey timeline
Answers “why did responses stop” by lining up collection against the edit history
Free agent skill for Claude Code, Codex, Cursor and Gemini CLI. It works through the SurveyNinja MCP server, with your permissions.
- Category
- Understand results
- Tags
- edit history, funnel
- Works with
- Claude Code, Codex, Cursor, Gemini CLI
- MCP tools
- 5, all read only
- Version
- 1.1, October 20, 2026
- Made by
- SurveyNinja
- Price
- Free
- Skill file
- SKILL.md
What it does
- Responses and edits on one line. The skill lays the flow of responses over the publication history and looks for matching dates.
- A one-sentence conclusion. “Responses stopped on this date, apparently because of that” instead of a forty-row table.
- A coincidence is not a cause. If an edit could not have had an effect, a matching date is not presented as the reason.
Example
You type
Why did the survey stop collecting responses?
What the assistant brings back
That version added a condition that sent part of the audience into a branch with no exit. After the fix on 1 September collection returned to its earlier level, so the link shows from both sides.
The dates are an example. The lines are built from your survey and its versions.
How it works
- Builds two linesResponses by day or week, and the publication history. Each explains little alone; together they explain almost everything.
- Looks for date matchesA drop right after a publication means an edit broke something. A drop with no edits points outside: the email campaign ended, the banner came down, the event passed.
- Checks the obvious separatelyA sharp drop to zero is a reason to see whether the survey was unpublished or closed, or the monthly response limit was reached. From outside it looks like people simply stopped answering.
- Does not pass coincidence off as causeIf an edit could not have affected collection, the assistant says so. An invented link is worse than an honest “nothing found”.
Try also
- Show how responses came in and when we edited the survey
- There was a drop in late August. Work out what it was tied to
What it will not do
- Do not pass a date coincidence off as a cause
- Do not compare weekdays with weekends
- Do not suggest a plan upgrade or lead to payment
The skill works with your permissions. Tools that change data are marked, so you check what the assistant is about to do before you confirm. To cut access, remove the connector in the assistant or delete the API key.
In short
How does the skill look for the cause?
It compares two lines: how responses came in, by day or by week, and when the survey was edited and published. Then it looks for matching dates.
What does a drop right after a publication mean?
Most likely an edit broke something: a logic branch, a required field or the link address.
And if nobody touched the survey?
Then the cause is outside: an email campaign or ad ended, a banner came down, an event finished. A steady decline is normal decay, because the audience the link reached has run out.
Responses dropped to zero. What gets checked?
Whether the survey was unpublished or closed and whether the account reached its monthly response limit; past it, new responses are saved but hidden. If you follow responses in Google Sheets, a webhook or Telegram, the integrations are checked too: a broken connection looks the same from outside.
Why not compare weekdays with weekends?
Most surveys have a weekly rhythm. Without noting it, such a comparison shows a drop where there is none.
What do I need to use it?
A SurveyNinja account and an assistant that supports MCP and loads skills from a folder, such as Claude Code, Codex, Cursor or Gemini CLI. The assistant connects with your own API key or through “Allow access”. The skill only reads the summary, the publication history, the plan and the integrations; it is a plain text file and runs nothing by itself.
The full skill
The SKILL.md file the assistant reads, exactly as it is in the archive.
Show the full text
Survey timeline
"Why did responses stop" is answered by lining up two things: how responses came in and what was done to the survey.
Reply to the person in the language they write in.
Two lines
Responses over time: get_quiz_summary gives responses per day (completed,
unfinished and screened out) and visits per day. Group them by week if collection
ran long. Unfinished ones are there only if the plan keeps them.
Edit history: get_quiz_versions. Every publication leaves a snapshot, so it is
visible when the survey changed and which version was live at each moment.
Line them up
Find matches by date:
- A drop right after a publication: something was broken by an edit, such as a logic branch, a required field or the link address.
- A drop with no edits: an outside cause. The email campaign or ad ended, the banner came down, the event finished.
- A spike is also useful: understand what worked and repeat it.
- A steady decline is normal decay: the audience the link reached ran out.
Check separately
If the drop is sharp and goes to zero, check whether the survey was unpublished or closed. An unpublished or closed survey stops accepting responses immediately, which from the outside looks exactly like people no longer answering.
Check whether the account has reached its monthly response limit with
get_workspace_tariff (the workspace_id comes from get_workspace_list). Past
the limit, new responses are still saved but hidden: they do not appear in the
summary, the report or the responses and are not sent to integrations, so it
looks as if people stopped answering. If so, state that as a fact and stop there.
If the person watches responses somewhere else (Google Sheets, a webhook,
Telegram) and those stopped, check get_quiz_integrations as well: a broken
connection looks the same from outside while responses keep arriving in
SurveyNinja.
How to present
Briefly and by date: period, what happened, what it lines up with. A few anchor points instead of a forty-row table.
One sentence of conclusion: "responses stopped on this date, apparently because of that". If no link is found, say so rather than inventing one.
What not to do
- Do not pass a date coincidence off as a cause when the edit could not have affected it.
- Do not compare weekdays with weekends without noting it: most surveys have a weekly rhythm.
- Do not suggest a plan upgrade or lead to payment. If a limit is hit, state the fact and stop.
More skills
All skills- A/B variant analysis Tells you whether the difference between variants is real or just noise
- Comparing with past results Compares a survey with its own past, because one figure means little and a change says a lot
- Completion funnel Shows which question makes people close the tab, and why
- Survey results summary Answers "so what did the survey say" with figures and a conclusion instead of a raw export
- Report and survey styling Tidies up what people see from outside: the survey theme, the report colors and the logo
- How many responses you need Tells you whether what you have is enough and how many more responses you need before conclusions hold
Connect SurveyNinja to your assistant
The MCP server works on every plan, Free included. Sign up, allow access and ask your assistant to build the first survey.