They Already Answered. Why Does Your Scheduled Agent Keep Sending the Survey Again?
They Already Answered. Why Does Your Scheduled Agent Keep Sending the Survey Again? A customer buys a product, receives it, and fills in the feedback survey on Tuesday. On Thursday, the same survey arrives again. The following week, it arrives a third time. The customer is not annoyed by one extra email. The customer is annoyed by the message behind it: this business did not notice the answer it already received. Nothing in the workflow looks broken. The run started on time, the list loaded, t
They Already Answered. Why Does Your Scheduled Agent Keep Sending the Survey Again?
A customer buys a product, receives it, and fills in the feedback survey on Tuesday. On Thursday, the same survey arrives again. The following week, it arrives a third time. The customer is not annoyed by one extra email. The customer is annoyed by the message behind it: this business did not notice the answer it already received.
Nothing in the workflow looks broken. The run started on time, the list loaded, the message went out, and the log shows success. The failure is quieter. The agent never learned that this particular survey, for this particular order, was already completed. Every run works from the list it was given, and the list still says "not answered."
Why completion gets lost between runs
A scheduled survey agent usually starts with a list of people to contact, not a record of what each person already did. That distinction is where the duplicates come from.
First, completion lives in a different tool than the list. The survey platform records the finished response. The scheduled agent reads a customer list, an order list, or a segment built days earlier. If no step carries the completion back from the survey tool to the list the agent reads, the next run has no way to know the survey is done. The survey tool did its job. The agent simply never asked it.
Second, the list gets rebuilt from an old snapshot. A fresh export, a re-imported audience, or a segment copied from last month can quietly drop the completion flags. The agent sends to the list it was given, and the list is stale. This is why duplicates often appear in waves: one bad rebuild can re-send a whole batch of surveys to people who already answered.
Third, "sent" gets confused with "completed." Many workflows track whether a survey was sent, not whether it was finished. A customer who opened the link and submitted answers looks the same as a customer who never opened it, because both rows say the survey went out. A run that only checks the send flag will keep chasing people who already responded, while also missing the people who genuinely never replied.
Fourth, the same person appears under more than one identity. A customer answers from a personal email, while the survey list uses a work email. A customer completes the survey on a phone, while the agent matches on a different account record. When the match fails, the completion belongs to a stranger as far as the agent is concerned, and the real customer gets asked again.
Fifth, several agents each keep their own list. The post-purchase agent, the support follow-up agent, and the win-back agent may all send versions of a feedback request. A completion honored by one agent is invisible to the others, so the customer hears from the next agent in line as if the first conversation never happened.
What a completion record needs to carry
Stopping duplicate surveys is not about sending fewer surveys. It is about recording completion in a form the next run can actually check. A useful record answers five questions: who answered, which survey, for which order or support interaction, when, and through which channel.
The "which interaction" part matters most. A customer who completed a survey about a March order should still be asked about a June order, because that is a different experience. A record that only says "this customer completed a survey" will suppress the wrong surveys along with the duplicates. The key is survey plus interaction, not survey alone.
Partial answers need their own state too. A customer who started a survey and stopped halfway has not completed it, but sending the full survey again as if nothing happened is still a poor experience. Record the partial attempt, its date, and what was left unanswered, so the next run can decide whether a short reminder is appropriate or whether the window has passed.
The pre-send check that prevents most duplicates
Before a run sends anything, it should read the completion record for that exact survey and interaction. If the record says completed, the run skips that person and moves on. If the record is unclear, if the survey tool cannot be reached, or if the identity match is uncertain, the run should hold the message rather than send it and hope. An unsent survey is a delay. A duplicate survey to someone who already answered is a small trust failure, repeated until the customer stops answering surveys at all.
That check only works if the run also writes back what it learns. A completion discovered in a reply, a survey export, or a support thread should become a completion record before the run ends, so the next run starts from it. A check that reads a record nobody updates will always lag behind reality, and the lag is where the duplicates live.
It also helps to keep one suppression record that every agent reads, instead of one per workflow. When the post-purchase agent, the support agent, and the marketing agent all check the same record, a completion in one place protects the customer everywhere. When each agent keeps its own copy, a customer can be protected in one workflow and pestered by the next.
How Vilix AI fits this problem
This is the kind of shared state Vilix AI is built to hold. Vilix AI is a cloud-hosted memory layer, so there is nothing to install or maintain, and every tool connects to the same memory over MCP: the survey workflow, the support workflow, and the scheduled agent all read the same completion record, instead of each keeping its own stale copy.
Because Vilix AI stores full conversation history, not just extracted facts, the exchange where a customer answered, declined, or asked to stop stays retrievable in full, alongside the survey record. A later run can see not only that a survey was completed, but the context around it, which makes it much harder to send the wrong follow-up to the wrong interaction.
Getting started is low friction. Vilix AI offers a free plan forever, and a 7-day Pro trial with no credit card required. Data stays portable too: you can export everything or delete it anytime.
If your scheduled agent keeps re-sending surveys, the fix is rarely a better survey. It is a completion record that every run reads before it sends, written back by every run that learns something new. Put the answer where the next run will look, and the duplicate surveys stop.