Triggered Surveys Without the Chaos

A triggered survey fires automatically when something happens to a customer, instead of going out to a list on a schedule. The question itself takes twenty minutes to write. The rules around it decide whether the programme is still useful in six months, and that is the part most teams never build.

Every team starts the same way: a purchase completes, a survey goes out, the response rate beats the monthly batch several times over, and the obvious next step is more triggers. Eighteen months later there are fourteen of them, nobody owns four, two broke silently when an event was renamed, and a customer who bought something on Monday was surveyed on Tuesday, Thursday and Friday. None of that is a question design problem. It is governance, and this guide is about that half.

What a triggered survey actually is

A triggered survey is a survey whose send is decided by an event rather than by a calendar. Something happens in a system you already run, that system emits a signal, and a rules layer decides whether a specific person should be asked a specific question because of it. The survey itself is ordinary: the same question types and the same branching logic you would use anywhere, usually much shorter. Only the sending decision changes, and that is what moves the numbers.

The comparison worth making is with the scheduled batch, the quarterly survey sent to the whole database on the second Tuesday of the month. That one asks about a period, so the respondent averages months of experience into a single score.

	Scheduled batch	Triggered
Who decides the send	A calendar and a list	An event and a rules layer
What it asks about	A period, averaged from memory	One interaction, still fresh
Typical length	Ten to twenty questions	One or two, plus a follow-up
Volume pattern	A spike, then silence	A steady daily trickle
Who acts on it	Whoever reads the deck	The team named in the routing rule
Main risk	Nobody answers	Everybody gets asked too often

The response rate gap has a boring explanation. Relevance is the strongest predictor of whether somebody answers, and a message naming yesterday's order is relevant in a way "help us improve" never is. Recall is the second reason, since opinions decay fast, and length is the third, because a trigger only justifies asking about one thing. The same mechanics appear in how to reduce survey dropout.

None of this replaces the relationship survey. Transactional feedback tells you whether a process worked; it cannot tell you whether people would recommend the company, and it never reaches customers who stopped interacting, which is exactly the group most likely to leave. That distinction is drawn in CSAT vs NPS, and mature programmes run both.

The events worth triggering on

A good trigger event has three properties. It has a clear boundary, so both sides agree the thing is finished. It is attributable, so the answer points at a team or a process that can change. And it produces enough volume to learn from without surveying the same people constantly. Events that fail the first test, like "browsed a page", produce feedback nobody can act on.

The purchase or checkout is the usual starting point and is often used wrongly. When a payment clears, the only thing the customer can judge is the buying experience: whether the site was clear, whether payment worked, whether they found what they came for. They cannot judge the product yet, and asking produces a score that measures anticipation. Split the two and both answers get useful.

The delivery trigger is where the delay question gets sharp, because the wrong version is genuinely damaging. Firing on "shipped" asks somebody to rate a parcel they do not have. The carrier's "delivered" ping is better but still early, since it arrives when a parcel is left in a locker, at a neighbour's door or in a mailroom. Wait a day or two past confirmation, and suppress the survey entirely if a return, claim or ticket has been opened in the meantime, because those cases need a person rather than a questionnaire.

The closed support ticket is the cleanest trigger there is. The boundary is unambiguous, the experience is specific, and the right question is about effort rather than satisfaction, which is why the family around customer effort score lives here. It is also the one case where firing immediately is correct: send within minutes of the resolution, while the conversation is still in the customer's head.

The end of onboarding pays for itself fastest in software. Define it as a real completion event, the first project created or the first invoice sent, not as "seven days since signup", which surveys people who never started. Ask what nearly stopped them, since that names the friction quietly costing you activations; the note on onboarding covers the definition side.

The first use of a feature needs one adjustment: fire on the second or third use, not the first. A first interaction measures novelty and confusion in roughly equal parts, while the second tells you whether the thing was worth coming back to. Keep it scoped to features you are actively working on and switch it off when the work ships.

The subscription renewal is not a moment of celebration, it is a charge on a card. A satisfaction survey landing the same day invites people to answer the price rather than the product. Wait three to seven days, or skip renewal and use a tenure milestone, which carries the same information without the invoice in the frame.

The cancellation should never be an email. Ask inside the flow, at the moment of the decision, with one closed question and one optional open box; an email afterwards reaches someone who has mentally left and gets an answer rate in the low single digits. Keep the reason list short and mutually exclusive, since it is the only structured input most teams get into their churn rate and into the work described under customer retention.

The abandoned cart trigger has a trap in it. A survey and a discount email are different mechanisms, and sending both on the same day teaches people that walking away is rewarded. Pick one. If you pick the survey, wait about a day, ask what stopped them, and cap it hard so a habitual browser is not asked every week.

The tenure anniversary, often used to carry a periodic NPS question, is a trigger where the delay is the entire point. Ninety days after signup, then annually, gives every customer the same amount of experience before they are asked, which makes the scores comparable in a way a batch send never is. It behaves like a rolling pulse survey.

The delay is a design decision, not a default

Most tools ask for a delay and most teams leave it at zero. That is the most consequential unexamined setting in a triggered programme, because the correct delay differs for every event and ranges from minutes to months.

The rule underneath it is that the survey should arrive at the first moment the customer can honestly answer, and not a minute earlier. After a support conversation that is immediate. After a delivery it is when the box has been opened. After a first feature use it is after the second one. Firing instantly feels responsive and is usually just early, and an early survey does not simply get a lower response rate, it gets a wrong answer, because people answer about the part they can see.

Two constraints sit on top. Respect local time, since a survey generated at 03:00 in the recipient's timezone reads as automation nobody supervises. And decide what happens when later events overtake a queued survey, for example a delivery survey due tomorrow when a refund was processed tonight. Re-check suppression at send time, not only at trigger time; teams that check only at the moment of the event ship the most embarrassing sends in this category.

The rules an event passes before anything is sent

Between the event arriving and a message going out there should be a pipeline of checks. Every one of them exists because somebody once shipped a programme without it.

Deduplication comes first. Event delivery is retried by design, so any webhook producer will occasionally send the same event twice. Give every event an idempotency key built from the event and customer identifiers, store it, and drop repeats inside a generous window. Without this you will eventually send one person the same survey three times in a minute, which is the failure that gets a programme paused by someone senior.

Then check that this is a real customer. Test orders, seeded demo accounts, internal addresses and load-test traffic all emit the same events as real activity. Filter on account type and domain, and treat anything from a non-production environment as ineligible by default.

Then consent and reachability. The person needs a valid channel, a known language and permission to be contacted for research. Transactional and marketing consent are not the same thing and the boundary differs by market, so store a separate research preference rather than inferring one. Anyone who opted out stays out across every campaign, permanently.

Then the suppression list, where the judgement lives. Anyone who answered a survey in the last thirty days, or received one in the last fourteen, is suppressed. So is anyone with an open complaint, refund dispute or escalation, because a satisfaction question in the middle of an unresolved problem reads as tone deaf. During an incident every trigger pauses on a single switch, since the answers would measure the outage. Named accounts handled by a customer success manager go to that person instead, and employees, partners and press accounts never receive automated research.

Then the frequency cap, which gets its own section below, and after it sampling. On a high volume event you do not need everyone, and surveying a fixed percentage gives sufficient volume while leaving most of the base untouched; the note on sample size covers how much is enough.

Finally, priority. Two triggers will eventually fire for the same person on the same day and something has to decide. A workable order: cancellation beats everything, an open support issue beats a transactional survey, and a transactional survey beats a relationship or feature survey. The loser is dropped rather than delayed, because a queue of deferred surveys quietly rebuilds the problem the cap was meant to solve.

Frequency capping across every campaign, not per campaign

The most common structural mistake here is capping inside each campaign. Every individual trigger looks polite at once a quarter, and a customer who bought something, contacted support, received a delivery and renewed in the same fortnight gets four surveys because no single rule was violated. The cap has to be global, evaluated across all campaigns and channels, and stored in one place every sender consults.

Defaults that survive contact with reality: no more than one survey per person per thirty days across everything, extended to ninety days after somebody completes one, with a hard annual ceiling of four. Treat two consecutive ignored invitations as a signal and suppress that person for six months. Count invitations rather than completions, because the fatigue comes from being asked.

Enforcement matters more than the numbers. If the survey tool caps, the marketing platform caps, and a helpdesk automation sends a fifth survey nobody counted, you do not have a cap. Pick one system of record for when this person was last asked anything, write to it from every sender, and check it before every send. This is the operational face of survey fatigue, and its earliest symptom is not complaints but a slow slide in response rate across all campaigns at once.

Pass the context, never ask for it

A triggered survey is fired by a system that already knows the order number, the amount, the carrier, the agent, the plan and the tenure. Every one of those facts asked as a question is a question wasted, a tax on completion, and an invitation to an inaccurate answer, since people misremember details your database has exactly right.

Attach the context as hidden fields on the survey link or through the API that creates the response. What is worth attaching depends on the trigger, but the pattern is consistent.

• Transaction identifiers. Order, ticket, shipment or subscription id, so a low score traces back to the exact case without asking anyone.
• Attributes of the event. Order value, product category, delivery method, support channel, handling time.
• Who was involved. Agent, team, store or region, which is what turns scores into coaching rather than commentary.
• Customer attributes. Plan, tenure, value band, language, so results can be cut by segmentation instead of read as one average.
• The trigger and variant names. Without them you cannot tell which trigger produced a response once several are live, or compare variants in an A/B test.

Two limits. Keep personal data out of query strings, since links are forwarded, logged and pasted into tickets; pass an internal identifier that means nothing outside your systems. And never call a survey anonymous while it carries an account id, a rule set out in the note on anonymous surveys.

Route the answer to where somebody acts

A response that lands only in a survey dashboard is a response nobody will act on, because the people who fix things do not open survey dashboards. Routing is as much a part of the design as the question, and it should be written before the first send.

Write the score back onto the customer record in the CRM, as a field on the contact and on the account, so the next person who opens that record sees it. Sales teams behave differently towards an account that scored two last week, and that behaviour change is worth more than any report. Push the full response into the warehouse as well, so it can be joined to revenue and retention later.

Then define the alert path for bad answers. A low score on a support ticket should open a follow-up task in the helpdesk, linked to the original ticket, assigned by the same rules that assign tickets, with a target response time attached. A low score from a high value account should notify a named human within the hour rather than appear in a weekly digest. The rule to hold to is that every negative response has an owner and a deadline before the trigger goes live, otherwise you have built a machine that collects complaints and ignores them.

Most of this is configuration rather than engineering: the survey tool emits a webhook or writes through an existing connector, and the helpdesk or CRM does the rest, which is what the integrations are for. What cannot be automated is closing the loop, and telling somebody what changed after they complained is the strongest driver of whether they answer next time.

Measure each trigger separately

Aggregate reporting destroys triggered programmes. One blended satisfaction number across nine triggers moves for reasons nobody can name, usually because the volume mix shifted rather than because anything got better. Report per trigger, and compare each trigger only against its own history.

Worth watching for each one: the response rate, the completion rate among those who started, the score distribution rather than the mean, and the volume of events suppressed and why. That last one is the diagnostic nobody builds and everybody needs, because it is how you discover a cap is eating eighty percent of your delivery surveys. Reading completion rate separately matters too: an invitation nobody opens is a channel or timing problem, while a survey people start and abandon is a question problem.

Two habits keep it honest. Look at distributions, since a mean of four can hide a hardening cluster of ones, and read open text in themes with counts attached rather than by anecdote, using the approach in thematic analysis. Low volume triggers will never produce clean weekly numbers, so read them quarterly.

What actually breaks

Triggered surveys fail in a small number of repeatable ways, and none of them are about question wording.

Double-firing on retried webhooks is the classic. A producer does not get an acknowledgement in time and retries, or an order moves through three status changes that all map to the same trigger. Idempotency keys and a dedupe window fix it, and nothing else does. Test it by replaying one event three times before going live, because in production it will happen on a Saturday.

Test events reaching real customers is the one that causes actual damage. A quality assurance script runs against production, a demo account is created with a colleague's real address, a migration replays two years of historical events and everyone who ever bought anything gets a survey about an order from three years ago. Guard against it with an environment flag checked at send time, an allowlist for non-production sends, and a rate limiter that halts any campaign exceeding a plausible hourly volume.

Silent death is the most expensive failure because nobody notices. An engineer renames an event, a field changes type, a token expires, and the trigger stops. A dead trigger looks exactly like a trigger with no eligible events, so alert on the absence of volume: if something that normally produces two hundred sends a week produces none for two days, it should page a human.

Timezone and locale drift produces the small embarrassments: a survey at 4am, an English survey to someone who has used your product in Portuguese for two years, a delay of "24 hours" landing on a public holiday.

Untracked proliferation is the slow one. Each new trigger is easy to add and nothing forces anyone to remove an old one, so the count only grows. Every live trigger needs a named owner, a purpose, a review date and a kill switch, and any trigger whose data nobody has read in two quarters should be switched off rather than maintained.

The honest weakness: easy to start, hard to govern

This is the part vendors do not say. Triggered surveys are trivially easy to launch and genuinely hard to run well, and the difficulty is administrative rather than technical. Nothing about the first trigger is complicated. The complexity is emergent, and it appears when there are nine of them, owned by three teams, sending through two systems, with overlapping audiences and no shared cap.

The cost also lands in a different place from the benefit. Marketing gets the response rate; engineering gets the webhook retries and the on-call alert; support gets the follow-up tickets a low score generates. Programmes decay when the party carrying the cost is not the party reading the results, which is why the useful governance artefacts are boring: one register of every live trigger with owner, event, delay, cap and last review date, a quarterly review that removes as many triggers as it adds, and one person who can pause everything during an incident.

Coverage is the second limitation. Triggers only reach people who did something, which excludes the disengaged, and disengagement is the strongest predictor of churn there is. A programme built entirely on triggers shows healthy scores while quietly losing customers who stopped interacting months ago, so keep one periodic survey pointed at the whole base. The third is that short surveys buy their response rate by asking less: one question after a delivery tells you a parcel arrived badly and not why. Triggers are a monitoring instrument, and treating them as a diagnostic one will disappoint you.

Building one, step by step

The order below is deliberate, because most of the failures above come from doing these steps in the wrong sequence.

• Name the decision first. Write down what you will do differently depending on the answer, and who will do it. If nobody can answer that, the trigger should not exist.
• Pick one event with a clean boundary, write its exact definition, then set the delay from the customer's side and the suppression and cap rules before you write the question.
• Write one question plus one conditional follow-up. A microsurvey is the right shape, the wording traps are listed in feedback form questions, and the general method is in how to create an online survey.
• Match the channel to the event. Email suits post-delivery and post-purchase, as in email surveys; in-product moments belong in in-app feedback; a cancellation calls for an inline or popup form in the flow itself.
• Wire the context fields and the routing before the first real send, including who owns negative responses.
• Test with replayed events, including duplicates, an event for a suppressed customer, and one in a second language, then ramp with sampling and review at thirty days against the decision you wrote in step one.

Doing this without an engineering project

The survey half needs no custom code. A hosted survey handles the questions, the branching, the hidden fields that carry order and ticket context, the language versions and the reporting, while your systems keep only the event and the rules. That split makes a first trigger a two-day job instead of a sprint, and starting from a ready-made template removes most wording mistakes before you reach the timing ones.

SurveyNinja covers that half: logic that sends low and high scores down different paths, hidden variables for every piece of event context, connectors and webhooks so responses land in the CRM or helpdesk where somebody acts on them, and filtered reports so each trigger can be read on its own; see the feature list for the mechanics. The free plan has no cap on responses, which matters more here than in any other format, because a trigger wired to a busy event produces a steady daily stream and a quota is the worst thing to hit mid-quarter; the pricing page has the details. Build the survey, wire it to one clean event, and give it a delay somebody actually thought about.

Frequently asked questions

What is a triggered survey?

A survey whose send is decided by an event rather than a calendar. Something happens in a system you already run, that system emits a signal, and a rules layer decides whether a specific person should be asked a specific question because of it. The survey itself is ordinary and usually very short; only the sending decision changes.

How is a triggered survey different from a scheduled batch survey?

A batch survey goes to a list on a date and asks people to average a period from memory. A triggered survey asks one person about one thing that just happened to them. That relevance is why response rates are typically several times higher, and why the answers point at a specific process instead of a general feeling.

Which events are worth triggering a survey on?

Events with a clear boundary and an owner: a completed purchase, a confirmed delivery, a closed support ticket, finished onboarding, the second use of a new feature, a renewal, a cancellation, an abandoned cart and a tenure anniversary. Events like a page visit fail the boundary test and produce feedback nobody can act on.

How long should you wait before sending a triggered survey?

Until the first moment the customer can honestly answer. After a support conversation that is immediate. After a delivery it is a day or two past confirmation, because the carrier ping arrives before the parcel is in anyone's hands. After a first feature use, wait for the second. After a renewal, wait three to seven days so the charge is not the most recent thing that happened.

How often is too often to survey the same customer?

More than once every thirty days across all campaigns combined, and more than four times a year in total. Extend the interval to ninety days after somebody completes a survey, and suppress anyone who ignored two invitations in a row for six months. Count invitations rather than completions, because the fatigue comes from being asked.

Why do triggered surveys send duplicates?

Because event delivery is retried by design and several status changes often map to the same trigger. The fix is an idempotency key built from the event and customer identifiers, stored and checked so repeats inside a generous window are dropped. Replay the same event three times in testing, since it will certainly happen in production.

What context should be attached to a triggered survey?

The identifier of the thing being rated, its attributes such as value or channel, whoever was involved such as agent or store, and customer attributes such as plan and tenure, plus the trigger name. Pass them as hidden fields so nothing is asked that a system already knows, keep personal data out of query strings, and never call a survey anonymous if it carries an account id.

What is the main weakness of triggered surveys?

They are easy to start and hard to govern. Each trigger takes minutes to build, nothing forces anyone to retire one, and after a year several teams are sending to overlapping audiences with no shared frequency cap. They also only reach people who did something, which excludes the disengaged customers most likely to leave.