How to automate a customer feedback workflow people answer

Automating feedback collection makes it trivial to ask, which is why most organisations ask far too often and get worse data than when it was harder. Response rates fall, the people who do answer are unrepresentative, and the results support whatever anybody already believed.

The constraint is that every request spends a small amount of goodwill. Deciding when it is worth spending, and demonstrably acting afterwards, is what keeps the channel working — and automating the asking without automating the acting is what closes it.

What we'll cover

• Asking is cheap, answering is not
• Timing, which decides what you learn
• Sampling rather than asking everybody
• Building it with CodeWords
• Closing the loop
• The feedback that is not about what you asked
• Routing it so it reaches somebody
• Asking a question worth answering
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Asking is cheap, answering is not

Every request costs the customer attention and costs you a small amount of goodwill.

Automation removes the natural limit. When asking required effort, nobody asked after every interaction; now everybody does.

Response rates fall as frequency rises, and the people who keep answering are the unusually engaged and the unusually annoyed.

That skew is invisible in the results, which look like data and are a biased sample.

Set a floor. A rule that nobody is asked more than once in a period, across all your surveys, is the single most effective thing here and almost nobody has one.

Count the asks per customer, centrally, since three teams each asking quarterly is asking monthly from the customer's point of view.

Timing, which decides what you learn

Immediately after an interaction captures the experience accurately and the outcome not at all — somebody rates a support conversation before finding out whether the fix worked.

A few days later captures whether it actually helped, at a lower response rate.

At a milestone — onboarding complete, first renewal — captures the relationship rather than an incident.

Never during. A survey arriving mid-problem is an insult, and the automation cannot tell unless somebody makes it check.

Check for open issues before sending, which is a small condition and prevents the most damaging version of an automated ask.

Match the timing to the question. Asking about an interaction and asking about the relationship need different moments, and sending both at once produces answers about neither.

Sampling rather than asking everybody

You do not need everybody. A random sample large enough to be meaningful tells you the same thing at a fraction of the goodwill cost.

Sample randomly, not by convenience, since asking only the customers a team happens to be in contact with is exactly the bias you are trying to avoid.

Stratify if segments matter — by plan, by tenure, by region — so a small segment is not invisible in the aggregate.

Always ask after an unusually bad experience, outside the sample, since that is the case where the individual response matters more than the statistics.

Report the response rate and who responded, not just the score, because a score from four per cent of customers is a score from four per cent of customers.

Stop asking the same people. Rotating the sample keeps the channel alive and keeps the data from becoming a panel nobody chose.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the sending, the suppression rules, and the routing can run across the product, the CRM, and the support tool.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what triggers a request, who is eligible, and where responses go.
3. Authorize the connections — the product or support tool, the CRM, and the survey or email tool.
4. Describe the exceptions: a customer with an open complaint, somebody asked recently, a response needing a person.
5. Run it against a small segment before anything reaches your whole base.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Closing the loop

The half that determines whether anybody answers next time.

Reply to negative feedback, from a person, within a day. This is the highest-return action in the entire process and it is where most workflows stop.

Acknowledge positive feedback too, briefly, since it costs nothing and it is what makes the relationship feel two-way.

Tell people when something they asked for ships. Somebody who suggested a feature and hears about it a year later becomes an advocate; somebody who never hears assumes nobody read it.

Report back in aggregate — what you heard and what you changed — which converts a survey from an extraction into an exchange.

Do not promise what you will not do. "We are looking into it" repeated three times is worse than a straight no.

Measure whether you close the loop, since it is the commitment most quietly abandoned when volume grows.

The feedback that is not about what you asked

Most valuable responses ignore the question. You asked about a support interaction and they told you about pricing.

Free text is where this lives, and a workflow that only records the score discards it.

Do not force it into categories. Classify to route, and keep the original text, because the wording is frequently the finding.

Read it periodically. Aggregated themes are useful and are not a substitute for somebody reading a sample of what customers actually wrote.

Route it by content, not by the survey it came from. Feedback about billing should reach finance regardless of which survey collected it.

Count themes over time, since a theme appearing eleven times this quarter and twice last is a signal that no individual response carries.

Routing it so it reaches somebody

A negative response needs a person, promptly, with the context of what they were responding to.

Route by account ownership where one exists, since a named account's feedback should reach whoever knows them.

Feature requests go to product, with a count rather than individually, so the volume is visible.

Complaints about a specific thing go to whoever owns that thing, which requires a classification good enough to route but not perfect.

Do not send it all to one channel. A feedback firehose in a general channel is read for a fortnight and then muted.

Report what reached nobody. Responses that could not be routed are the ones that disappear, and they need a default with an owner like any other queue.

Asking a question worth answering

The survey design half, which automation makes easy to get wrong at scale.

Ask fewer questions. Response rates fall sharply with length, and a two-question survey answered is worth more than a ten-question one abandoned.

One free-text box where people can say anything, because that is where the useful material is.

Avoid leading wording. "How helpful was our excellent support team" produces answers about your phrasing rather than your support.

Do not ask what you will not act on. Every question implies a willingness to respond to the answer, and a question nobody reads is a small dishonesty repeated at scale.

Keep the wording stable. Changing a question changes the answers, and a trend across a changed question is not a trend.

Test it on colleagues first, which catches ambiguity cheaply and is skipped almost every time.

Making it survive

Suppress across surveys, centrally, rather than per survey — which requires one place recording when each customer was last asked.

Check for open issues before sending, always.

Respect opt-outs, including for transactional-looking requests, since a customer who asked not to be contacted did not mean except for surveys.

Handle the response that arrives late, weeks after the interaction, rather than discarding it.

Report the outcome. Requests sent, suppressed and why, responses received, and responses routed.

Limits worth knowing about

Response bias is unavoidable and is largest at the extremes — the delighted and the furious answer, and the indifferent majority does not.

Single-number scores compress a lot and are easy to move by changing who you ask, which is worth remembering when one becomes a target.

Small samples produce volatile scores, and a monthly figure from thirty responses will swing for no reason.

Survey tools and your CRM disagree about who was contacted unless something reconciles them.

Feedback is not a roadmap. It tells you about the experience people had, not what they would value next, and the two are different questions.

What to build first

The suppression rule: one central record of when each customer was last asked anything, enforced across every survey, with open complaints excluded. It costs nothing, it is the single most effective protection of response rates, and it prevents the version of automated feedback that actively damages relationships.

Two habits make the difference. Count asks per customer across all surveys rather than per survey, since three teams asking quarterly is monthly from the customer's side. And build the negative-response reply into the first version, because the loop-closing is what keeps people answering and it is always the part that gets deferred.

Frequently asked questions

Why are our response rates falling?

Almost always frequency. Automation removed the natural limit on asking, and the people who keep answering are the unusually engaged and the unusually annoyed — which biases the results while making them look like data.

How often should customers be asked?

Not more than once in a period, counted across every survey your organisation sends rather than per survey. Three teams each asking quarterly is monthly from the customer's point of view.

When is the right moment to ask?

It depends what you want to know. Immediately after an interaction captures the experience; a few days later captures whether it helped; a milestone captures the relationship. Never while an issue is open.

Do I need to survey everybody?

No. A random sample tells you the same thing at a fraction of the goodwill cost — stratified if segments matter, and always asking after an unusually bad experience outside the sample.

What is the highest-return part of the workflow?

Replying to negative feedback from a person within a day. It is where most automated workflows stop, and it is what determines whether anybody answers the next request.

What happens to the free-text responses?

Keep them and read a sample periodically. The most valuable feedback usually ignores the question you asked, and a workflow that records only the score discards exactly that.

Is feedback a roadmap?

No. It describes the experience people had, not what they would value next. Treating a feature request count as a plan is a common way to build things that were asked for and not used.

How many questions should a survey have?

Very few — a score and one free-text box covers most cases. Response rates fall sharply with length, and a short survey answered beats a thorough one abandoned.

Can I change the questions?

Only deliberately, because changing wording changes answers and a trend measured across a reworded question is not a trend. If you must change it, note the date and treat the series as two.

Related reading

• Automating product feedback categorisation
• Automated ticket routing
• Intercom and CodeWords