Customer feedback tracker template (CSV, blank + worked sample)

A feedback tracker is one spreadsheet where every piece of customer feedback lands with the same shape. One row per issue. One column per decision you have to make: what it is, how the user feels, who owns it, where it duplicates something else, and what happens next.

This page gives you two files you can use today:

• Download blank tracker (CSV) — the empty tracker, headers only. Import it into Google Sheets, Excel, or Numbers.
• Download sample tracker (CSV) — the same tracker filled with fictional example rows. Use it to see how each field is meant to be filled.

Both files are plain CSV, so they open anywhere. To load one in Google Sheets: File > Import > Upload, then pick Replace spreadsheet for the blank file or Create new spreadsheet for the sample.

The sample rows are invented for illustration. They are not customer records, and they contain no real names, emails, or account data.

The columns, and why each one exists

A tracker is only useful if every column answers a question you actually ask. Here is what each column holds and how to fill it.

Column	What it holds	Example
item_id	A stable handle you assign, one per row. It does not change when you sort or delete rows, so duplicate references stay valid.	FB-001
received_date	The date the feedback arrived, as YYYY-MM-DD. Use it for sorting and for judging age.	2026-10-05
source_url	The page where the feedback was submitted. Keep the full URL so you can revisit it in context.	https://app.example.com/pricing
original_text	The user's words, unedited. Do not summarize or clean up here.	Where do I upgrade my plan?
category	What kind of feedback this is.	question
sentiment	How the user feels about it.	neutral
owner	One person responsible for the next action. Not a team.	sam
status	Where the item sits in your workflow.	new
duplicate_of	The item_id of the earliest entry for the same underlying issue. Blank if this row is the original.	FB-002
next_action	The single next step, phrased as a verb.	Reply with upgrade link

Reference rows by item_id, not by position

Every row gets its own item_id, such as FB-001. Assign it once and never reuse it. This is the only safe way to point one row at another: spreadsheet row numbers change the moment you sort or delete, which silently breaks any duplicate_of reference built on them. The sample file shows the pattern.

Use the same category names FeedValue documents

FeedValue's documentation describes its AI category field as one of six values: bug_report, feature_request, praise, complaint, question, and general. Reuse those exact names in your sheet. If you adopt FeedValue later, the two sides line up without a mapping table.

For sentiment, the same documentation lists positive, neutral, and negative. Match those too.

Keep category and sentiment separate

The two columns answer different questions, so do not collapse them. "Please add SSO" is a feature_request with neutral sentiment. A calm bug report can be negative without being angry, and a frustrated message can still be a question. If you merge the columns into a single "type", you lose the ability to ask either question later.

One row per issue

If a single comment raises two things, split it into two rows. Example: "The export fails, and by the way, please add scheduled exports." That is one bug_report and one feature_request. Copy the text into two rows, set each category, and note the split in next_action (for example, Split from single comment).

Keep original_text raw

Resist tidying the text. Summaries drift from what the user said, and the raw quote is the evidence you will want when you decide priorities. Summarize later, in a different column, if you need to.

Handling duplicates

The same issue arrives in many forms. There are three you will see:

1. Exact repeats. The same person submits twice, or the widget resends.
2. The same issue, worded differently. "Add SSO", "We need single sign-on", "SAML support please".
3. The same issue from different people. Twelve users, twelve separate rows.

The rule is simple: keep the first occurrence as the original, and point every later occurrence at it with duplicate_of. Put the original's item_id in the column, never a spreadsheet row number — row numbers change when you sort or delete. Do not delete duplicates.

Why keep them? Because duplicates are your volume signal. A feature requested by twelve people is a different decision from one requested by one. The duplicate_of column lets you count demand without re-reading every row. A quick count of rows that share the same canonical item_id tells you how many people asked.

Set the duplicate's status to archived once you have linked it, so the review queue stays clean. Keep the original in new or read.

A weekly review that takes about 20 minutes

Categorizing once is easy. Keeping the tracker honest is the hard part. Block one slot a week and run the same steps:

1. Filter status to new, then sort by received_date.
2. For each row: set category and sentiment, choose one owner, and write a single next_action.
3. Move the row to read once it has been triaged.
4. Scan for duplicates and fill duplicate_of.
5. Count the feature_request rows that share a canonical item_id. That number is your demand signal for the next prioritization pass.
6. Close anything that is finished: set status to resolved.

Pick one person to run this every week. Rotate the owner column freely, but keep the review itself on one calendar.

When a spreadsheet is enough — and when it is not

A CSV tracker is enough when:

• Volume is low enough that one person can read every item in a single sitting. Where that line falls depends on your team and your reading appetite, so set your own mark; if triage regularly spills past its slot, you have outgrown the sheet.
• You run one product or one small app.
• One or two people do the triage.
• Your feedback sources are simple.

You have outgrown the sheet when:

• You run several apps or products and need to separate them.
• Feedback arrives through many channels and you keep losing pieces.
• You need each user's history across submissions.
• You want category and sentiment assigned without doing it by hand.
• You need to update or remove many items at once.

Nothing bad happens if you start with the sheet and switch later. The column names here are chosen so the two line up.

Where FeedValue fits

FeedValue's documentation describes an embeddable widget that collects feedback in your app. The docs list per-submission fields that can include an AI category (bug_report, feature_request, praise, complaint, question, general), a detected sentiment (positive, neutral, negative), the source URL, browser and device info, any custom data fields you configure, and a status in the new / read / resolved / archived workflow. The docs also describe bulk status updates and bulk deletes.

Those details come from FeedValue's current documentation. They describe what the docs say, not an independently tested result. The tracker above is yours either way: category, sentiment, status, and source_url use the documented names so you can align the two, while item_id, received_date, owner, duplicate_of, and next_action are columns for your own process.

See how FeedValue collects and organizes feedback on the features page, or start free.

Related templates

• Feature request template — collect structured feature requests that are easy to prioritize.
• Feedback checklist — a pre-launch checklist for your feedback collection.
• Customer feedback categorization — how to assign category and sentiment consistently.

Sources: FeedValue documentation, Feedback guide. Field descriptions reflect the docs at the time of writing.