Most teams do not have a feedback problem. They have a feedback tracking problem. The remarks arrive, they are read, several of them are genuinely useful, and three months later nobody can say which ones led to a change or whether anyone replied. The form is working. The tracker either does not exist or exists as a spreadsheet that one person updates and everyone else ignores.
A feedback tracker template is usually presented as a set of columns. The columns are the easy part and they are included below. The reason trackers fail is not the column list. It is that the tracker is separate from the place feedback arrives and separate from the place replies are sent, so keeping it current is unpaid manual work that stops the first busy week.
The three jobs a tracker has to do
Trackers get built for one reason and judged on three. Being clear about all three early prevents building something that satisfies only the first.
Nothing gets lost. Every piece of feedback is in one list, whatever channel it came through. This is the job people set out to do and the only one a spreadsheet does well.
Somebody owns each item. Not the team, a person. The most common failure in shared feedback is not a missed item but a visible item that two people each assumed the other was handling. An ownerless list produces this reliably, and it gets worse as the team grows rather than better.
The question "what changed because of this?" has an answer. In a quarter, someone will ask what the feedback produced. A tracker that cannot answer that question gets quietly abandoned, because the work of maintaining it has no visible return.
The third job is the one that decides whether a tracker survives. It requires linking a piece of feedback to what happened afterwards, which means the tracker has to record outcomes and not just arrivals.
There is a fourth job that gets added later and should be resisted at the start: prioritisation. Scoring every item by effort and impact sounds sensible and produces a column of guesses that nobody trusts enough to act on. Counting items by theme does the same work with real numbers, and it does it without requiring a judgement on arrival, which is when the least is known about the item.
The columns worth having
For a spreadsheet version, this is the full list. Eleven columns, and the order matters because a tracker is read left to right in a hurry.
- Date received. Plain date, not a timestamp. Sorting matters more than precision.
- Source. Form, email, phone, event, conversation. Counting the sources after a quarter tells you whether the form is actually the main channel or whether most feedback still arrives by other means.
- Who it came from. Name or email. Leave it blank for anonymous items rather than deleting the row.
- What they said. The text, not a summary. Summaries written on arrival lose the specific wording, which is exactly what is needed six weeks later.
- Theme. From a fixed list, not free text. This is covered below and it is the column most likely to be got wrong.
- Type. Bug, request, praise, complaint, question. Five values, chosen so that each one implies a different next step.
- Owner. One name.
- Status. Five values at most, listed in the next section.
- Reply sent. Date, or blank. A separate column from status because "handled internally" and "the person was told" are different states and conflating them is how the loop stays open.
- Outcome. What was done, in a sentence. Blank until something is done.
- Link. To the ticket, the document, the commit, the decision. This is what answers the quarterly question.
Columns 9, 10 and 11 are the ones cut from most templates found online, and they are the three that make the tracker worth maintaining. Without them it is an inbox with extra steps.
Five statuses, and no more
Status lists grow. Every new edge case suggests a new value, and a tracker with fourteen statuses cannot be filtered usefully by anyone who did not invent them. Five is enough for feedback.
| Status | What it means | What has to be true to leave it |
|---|---|---|
| New | Arrived, not yet read properly | Someone has read it and it has an owner |
| Acknowledged | The sender knows it arrived | A decision has been made about it |
| Accepted | Something will be done | The thing is done |
| Declined | Nothing will be done | The sender has been told, if a reply was expected |
| Closed | Done and the sender knows | Nothing, this is the end |
Declined is the status that is usually missing, and leaving it out is expensive. Feedback that will not be acted on still needs to be closed off deliberately, otherwise it sits in an open state forever and inflates the backlog until the backlog is ignored. Deciding not to do something is a decision, and recording it means the same suggestion arriving twice more does not get re-litigated from scratch.
Themes have to be a fixed list
The theme column is where trackers turn into unusable archives. If it is free text, twenty people write "pricing", "price", "too expensive", "cost concerns" and "expensive?" and the column can never be grouped. The tracker still holds everything and can no longer answer anything.
Start with five to eight themes taken from feedback already received, not invented in advance. Review the list once a quarter, and when a new theme genuinely appears, add it and recode the existing rows that belong to it. That recoding is fifteen minutes and it is what keeps the history comparable.
One theme per item, even when two apply. Multiple themes per row make counting ambiguous, and the ambiguity always surfaces in the one meeting where the numbers are being questioned. Pick the dominant one and put the secondary in the notes.
Where the spreadsheet version breaks
A spreadsheet tracker works well, up to a specific and predictable point. It is worth knowing the four places it gives way, because each one has a visible symptom.
Two people editing. Cloud spreadsheets handle simultaneous editing technically and not socially. Two people triaging the same list end up overwriting each other's status changes, and the fix is usually one person becoming the sole editor, which creates a bottleneck.
Copying from the inbox. Feedback that arrives as a notification email has to be pasted into the sheet by hand. This is the step that stops first. A week of it being skipped leaves the tracker permanently behind, and once it is behind, it stops being consulted.
Replying. The reply cannot be sent from the tracker. So the reply is sent from an email client, and whether it was sent lives only in that person's sent folder. Column 9 then depends on somebody remembering to come back and fill it in.
The history. A spreadsheet holds the current state. Who changed the status from Accepted to Declined, and when, and why, is not recorded unless someone types it into the notes.
Two of these four are about capture and two are about reply. That split is the useful way to think about the alternatives.
None of this argues against starting in a spreadsheet. For one person handling a dozen items a week it is the correct tool, and building anything more elaborate before the volume justifies it wastes the time the tracker was supposed to save. The point is to recognise the symptoms early, because the failure is gradual. A tracker does not break in a way that anyone announces. It simply stops being opened, and by the time that is noticed, several weeks of feedback exist only in an inbox.
What people use instead
| Approach | Capture | Reply | Priced by |
|---|---|---|---|
| Spreadsheet | Manual paste, or a form that appends rows | Not possible from the tracker | Free, or bundled with an office suite |
| Database tool such as Airtable | Form submissions land as records | Not built in, needs an add on | Editors, at 20 USD per user per month on the Team plan billed annually, with form submissions and read only collaborators not charged |
| Issue tracker | Manual, one issue per item | Comments, but not to an outside sender | Seats |
| Form tool with response management | Automatic, the form is the tracker | From the same screen as the answers | Usually seats, sometimes responses |
The middle two both handle capture and neither closes the loop, which is why teams using them tend to end up with a second list of who was replied to. The last row is different in kind: when the form and the tracker are the same object, there is no paste step to skip and no second list to reconcile.
That is worth being concrete about. If each response already carries an owner, a status and its own history, the tracker is not a separate artefact that somebody maintains. Filtering by owner or theme is a view of the responses rather than a copy of them, and the reply is sent from the response itself, which means column 9 fills itself in. The situations where this matters are the ongoing ones: feedback collected every month by a team of three or four, where the cost of the paste step compounds.
Feeding a spreadsheet automatically is a reasonable middle path and worth knowing about. Some form tools append each new response as a row and update that same row when its status changes, which keeps a familiar spreadsheet current without anyone copying anything. The reply still happens elsewhere, but the capture problem goes away.
Closing the loop is the whole point
The measure of a feedback tracker is not how much it holds. It is what share of items reached a state where the sender knows what happened. That number is calculable from the columns above: rows with a date in the reply column, divided by rows where a reply was expected.
Most teams who calculate it for the first time find it is somewhere under half. That is the finding worth acting on, and it is usually not caused by unwillingness. It is caused by the reply living in a different place from the record, so that sending it and recording it are two separate acts of memory.
There is a cheaper habit that helps immediately, before any tooling changes. Once a month, take the items closed in the last thirty days and send the people who raised them one line saying what was done. It takes under an hour, it produces more goodwill than the effort suggests, and it forces the outcome column to be filled in, because there is nothing to send otherwise.
What to change first
Add the three columns most templates leave out, which are reply sent, outcome and link, and then calculate what share of items expecting a reply received one. If that number is low and the cause is the gap between where feedback lands and where replies are sent, closing that gap matters more than any change to the column list, and Halict shows what it looks like when the two are the same screen.
Q1. What columns should a feedback tracker have?
Date, source, who it came from, the exact wording, a theme from a fixed list, a type, an owner, a status, the date a reply was sent, the outcome, and a link to whatever was done. The last three are usually missing from templates and they are the ones that let the tracker answer what changed as a result.
Q2. Is a spreadsheet good enough for tracking feedback?
It is good enough while one person maintains it and feedback arrives through one channel. It breaks when two people triage simultaneously, when items have to be pasted in from an inbox by hand, and when the reply has to be sent from somewhere else. The paste step is normally the first thing to stop during a busy week.
Q3. How many statuses does a feedback tracker need?
Five is enough: new, acknowledged, accepted, declined and closed. Declined is the one most often left out, which causes items nobody intends to act on to sit open indefinitely until the whole backlog gets ignored. More than five statuses makes the list impossible to filter for anyone who did not design it.
Q4. How do you group feedback into themes?
Use a fixed list of five to eight themes derived from feedback already received rather than invented in advance, and allow one theme per item. Free text in that column makes grouping impossible, because the same issue gets written five different ways. Review the list quarterly and recode existing rows when a genuinely new theme appears.
Q5. How do you make sure people hear back about their feedback?
Track the reply as its own field, separate from the status, so that handled internally and sender informed cannot be confused. Then measure what share of items expecting a reply actually got one. A monthly note to everyone whose item closed in the last thirty days covers most of the gap and takes under an hour.