How to close the feedback loop: acknowledge, clarify, decide, deliver, follow up

Collecting feedback is the easy part. The hard part is what happens after someone hits send. When replies never come, the people who wrote in may stop writing in, and the ones who keep trying can get more frustrated with each silent cycle. That is the risk closing the loop is meant to remove.

Closing the loop means every piece of feedback gets an answer, a decision, and a follow-up. It does not mean you build everything people ask for. It means nobody is left wondering what happened to what they sent.

This guide walks through five stages: acknowledge, clarify, decide, deliver, and follow up. It names who owns each stage, shows how to decline and defer without going silent, and ends with a checklist you can run every week.

What closing the loop means

A closed loop has three properties:

1. A reply. The person who sent feedback hears back from a human, even if the answer is no.
2. A decision. The feedback is accepted, declined, or deferred, with a one-line reason.
3. A follow-up. When the change ships, the requester is told, or the item is archived with a note.

The opposite of a closed loop is a growing inbox. Feedback arrives, gets marked read, and never moves. The dashboard fills up and the team stops opening it, because nothing in it ever changes.

Closing the loop is a habit, not a product feature. You can run it with a spreadsheet and a weekly meeting. This guide works either way.

The five stages

Run the stages in order. Each one has an exit condition, so you always know when an item is done with a stage.

1. Acknowledge

Goal: confirm the feedback arrived, and from which page or screen.

• Log the item with its source page, widget or channel, and date.
• Send a first reply. One or two sentences is enough: "Thanks, I've logged this. I'll come back to you once we've looked at it."
• Mark the item as read.

Acknowledge fast, then take your time on the decision. The acknowledgement buys you the room to think. It does not commit you to a fix.

The feedback documentation defines the status read as "viewed by a team member," and lists the workflow statuses new, read, resolved, and archived. Setting that status is part of your own process. These are the documented values, not behavior we have tested.

2. Clarify

Goal: turn a vague report into something you can decide on.

Not every report is clear enough to act on. Some describe a symptom without the steps that caused it. Some ask for a feature without saying what problem it solves. Do not guess. Ask one focused question.

This is the same triage step that tools like Savio describe: when feedback does not make sense, ask the person who sent it for clarification before you link it to work. See Triaging customer feedback for that framing. The practice is general; it is not a FeedValue behavior.

Good clarification questions:

• "What were you doing when this happened?"
• "What did you expect to happen instead?"
• "Which part of the page were you on?"

Bad clarification questions:

• "Can you be more specific?" (asks for work without pointing at anything)
• "Is this a bug or a feature request?" (asks the reader to classify for you)

Record the answer on the original item so the context stays in one place.

3. Decide

Goal: accept, decline, or defer the item, with a reason.

Decide against the same priorities you use for everything else. If you score feature work, use that score here. RICE weighs reach, impact, confidence, and effort into a single number, which is useful when you compare unlike requests. See the RICE scoring model from ProductPlan, which documents the method and credits Intercom as its origin.

Not everything needs a score. Scoring suits feature work with clear reach and effort. It fits poorly with a single urgent bug. Sort those two kinds of items apart before you rank anything.

Every item leaves this stage in one of three states:

• Accept — you will work on it. Note what will change.
• Decline — you will not work on it. Note the reason.
• Defer — it is real, but not now. Note what would move it up.

If two items describe the same thing, link the newer one to the older with a duplicate reference. That way the count of people who asked stays with the canonical item.

4. Deliver

Goal: tell the requester what changed, and when.

When the change ships, send the requester a note that says what shipped and where to find it. A short line is enough: "Thanks — the change you asked about now does [what changed]. You'll find it under [where]." Fill the brackets with your own details.

Then mark the item resolved. The documented FeedValue status for an addressed item is resolved.

Delivery needs its own check. Shipping the change and telling the requester are separate steps. Record the follow-up so your team can see whether the person who reported the problem received an update.

5. Follow up

Goal: confirm the fix worked, and close items that are done.

Follow up once, after the change has had time to be used. Ask whether it solved the problem. If yes, archive the item. If no, it reopens at stage 2 with the new detail attached.

Then run a weekly pass over everything still open. Items with no further action get archived. Items waiting on a reply get a second nudge, then move on.

Who owns each stage

Loop closure fails when everyone assumes someone else owns it. Assign one role per stage.

Stage	Owner	Exit condition
Acknowledge	Support or the triager on duty	First reply sent, item marked read
Clarify	Triager	The report is actionable, or the requester cannot add detail
Decide	Product manager	Accepted, declined, or deferred, with a reason
Deliver	Owner of the work	Release note sent to the requester, item marked resolved
Follow up	Support or triager	Confirmation received, item archived or reopened

On a small team one person may hold several rows. That is fine. What matters is that each row has a name, so a reply never depends on someone remembering.

Declining and deferring without going silent

A "no" that explains itself keeps the relationship. A "no" that never comes does not. Here are two example replies you can adapt. Both are fictional and refer to a generic app, not to any FeedValue feature or roadmap item.

Declined (fictional example)

Thanks for sending this in. We looked at [the request], and we're not going to build it. It would add [the extra system or upkeep] without solving [the underlying problem] for enough people who hit it.

If [the detail you care about] matters to you, I'd like to hear more. That's a separate problem, and it might have a smaller fix.

The reply says no, gives the reason, and leaves one door open without promising anything.

Deferred (fictional example)

Thanks for the report. This is a real problem and I've logged it. We're already committed to [current priority], so I can't put this on the current cycle.

What would move it up: if more people hit it, or if it starts blocking [the task] for anyone. I'll come back to you if either happens.

The reply confirms the item is real, says why it waits, and names the condition that would change the answer. Now the requester knows the loop is not closed because you forgot them.

Deferral is not a soft decline. If nothing will ever change the decision, decline it. If a named condition could, defer it and say what that condition is.

Running it manually is a fine plan

You do not need automation to close the loop. A spreadsheet with columns for source, text, owner, status, and next action is enough to start. The companion feedback tracker template lists those fields and includes a sample sheet.

Three more companion drafts cover the surrounding steps: categorizing customer feedback, prioritizing customer feedback, and feedback widget copy.

Manual follow-up is explicit and intentional. You reply by hand, you decide by hand, and you check back by hand. It is slower than a rule that fires on every new response, but it also means no reply goes out that a person has not read. If you want that control, staying manual is a valid choice.

The current documentation lists, for a response, an AI category, an AI sentiment, a status, and a source page, browser and device, plus any custom data fields you configure. The documented categories are bug_report, feature_request, praise, complaint, question, and general. The documented sentiments are positive, neutral, and negative. The docs also describe filtering by app, widget, date range, and status, and updating or deleting several responses at once. See the feedback documentation. These are documented fields, not behavior we have tested, and a given response may not have every optional field populated. How you use them is your process, not a product requirement.

Weekly review

Set one recurring block and run the same pass every week:

1. Clear the new queue: acknowledge each item and mark it read.
2. Work the clarify pile: send the questions you owe.
3. Decide the items that are ready: accept, decline, or defer.
4. Deliver the shipped changes to the people who asked.
5. Archive the closed items and nudge the quiet ones.

Set a cadence you can keep. A weekly pass is a common starting point, but pick the interval you can actually hold. Skip several weeks and the queue stops feeling like a queue and starts feeling like an archive nobody reads.

Get the checklist

The five stages, with owners and exit conditions, are in one file: Download feedback-loop checklist (CSV). Columns cover the stage, the step, the owner role, and the evidence that shows it is done. Paste it into a sheet and run it weekly.

If you would rather start from a template, the meeting agenda template helps turn the weekly pass into a short, repeatable meeting. The feedback emails template covers the acknowledgement, decline, and delivery replies.

Keep the replies next to the requests

A loop is easier to close when the request and its status live in the same place. The current documentation describes FeedValue as a dashboard that lists widget responses from your apps and tags each with a category, a sentiment, and a status. See what that looks like in the features overview, then start your free trial.