One row per meeting, or one table that updates?

A table fed by meetings can take one of two shapes: a new row for every meeting, or the same rows updated meeting after meeting. This guide is for anyone setting up such a table from Google Meet or Microsoft Teams calls, by hand or as a TrackHeros tracker. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. It explains the difference with three worked examples, a standup log, a project tracker and an interview scorecard keyed by candidate, and ends with a one-minute way to choose.

What are the two shapes?

In the first, every meeting adds a row, and the row is that meeting's record. In the second, each row is a thing that outlives any one meeting, named by a key column, and a later meeting that mentions it updates the same row.

Shape	A row is	The question it answers
A new row for every meeting	One meeting	What happened at each meeting?
The same rows, updated	One thing, named by a key column	Where does each thing stand now?

Both are tables that fill themselves from your meetings, as described on the trackers page. You choose the shape when you define the tracker.

When is a new row for every meeting right?

When you will want to read a particular meeting's row later as a record of that day. Standups, one-to-ones and retrospectives fit: the meeting is the unit, and what changed between two of them is the point.

Here is a standup log for a client's team over three days in March 2026:

Date	Attendees	Done	Planned	Blockers
Monday 9 March	Lina, Omar, Jo	Login form	Password reset	Waiting on staging access
Tuesday 10 March	Lina, Omar	Password reset	Session timeout	Waiting on staging access
Wednesday 11 March	Lina, Omar, Jo	Staging deploy	Session timeout tests

The date fills itself from the meeting. Reading down the Blockers column shows how long staging access held the team up, which is the kind of fact a one-row-per-meeting table is good at. A standup tracker for developers builds this one in full.

When should the same rows update meeting after meeting?

When the question is "where does it stand now?". Features, change requests, decisions, deals and risks all outlive the meeting that first mentioned them, and a table with one row per mention would bury the current value under old ones.

Take the payments integration on a project tracker, discussed at three weekly calls:

Column	10 February	24 February	10 March
Status	In progress	Blocked	In progress
Deadline	3 March	17 March	2 April
Blockers		Sandbox keys from the bank	(removed: keys arrived)

The table shows one row, with In progress and 2 April as current. Each cell's history keeps the earlier values, each with the meeting, the speaker, the moment and the words used, so "when did the deadline move, and why?" is two clicks away. Blockers is a list: the item was added when raised on 24 February and removed when somebody said it was resolved.

What names a row in a table that updates?

A key column: the item, the request, the candidate, the company, the decision. When a later meeting mentions the same name, its row is updated rather than duplicated.

People rarely use exactly the same words twice. Differences of capitals or a leading "the" are matched for you. When a new row may mean an existing one, "the auth endpoint" against "Login API", TrackHeros flags it as a possible match, and you mark it the same row or a new row. Rows are never merged automatically, because two genuinely different things with similar names are common. Choose a key that people say aloud consistently, such as a feature's name rather than a ticket number nobody reads out.

Names never match across clients. A tracker that covers all your clients keeps a separate table for each, so Client A's "Phase 2" and Client B's "Phase 2" stay two rows in two tables, each labelled with its client.

How does an interview scorecard keyed by candidate work?

One row per candidate, updated at every interview they have. The Interview scorecard template is built this way, with the candidate as the key and its scope set to meetings whose title contains "interview".

Take one candidate, Daniel, through a screening call on Monday 2 March, a technical interview on Thursday 12 March and a final interview on Thursday 19 March 2026:

Column	After screening	After technical	After final
Stage	Screening	Technical	Final
Strengths	Clear on trade-offs	+ Strong SQL	+ Led a migration end to end
Concerns		No production Kubernetes	(removed after discussion)
Salary expectation	65,000 EUR	65,000 EUR (confirmed)	70,000 EUR
Recommendation			Strong yes

Strengths and concerns are lists, so they grow and shrink rather than being replaced. The salary repeated at the technical interview is a confirmation, not a change; the higher figure at the final is a change, with both quotes in the history. The recommendation stays empty until the interviewers state one. Comparing candidates becomes reading down a column; compare candidates across interviews does exactly that.

A scorecard with one row per interview is the other option: three rows for Daniel, each keeping that stage's assessment on its own. It suits a panel that wants each round judged separately, at the cost of reading three rows to learn his current expectation. One row per interview covers that set-up.

What goes wrong with the wrong shape?

The table answers the other question. A per-meeting table for a project hides the current status in the newest row that happens to mention each item; an updating table for standups keeps only the latest day in view and pushes every earlier standup into cell histories.

Mistake	What you see
One row per meeting for a project	Twelve rows mentioning the payments integration, none marked current
Updating rows for a standup log	One row, overwritten daily; yesterday is only in the history
A key that is too broad ("Backend")	Everything lands in one row and its cells contradict each other
A key that is too narrow (a sentence)	A new row nearly every meeting, and possible duplicates to sort

Which shape does each template use?

Five of the six templates keep the same rows and update them; the Standup log adds a row for every meeting.

Template	Shape	Row named by
Project tracker	The same rows, updated	Item
Change requests	The same rows, updated	Request
Interview scorecard	The same rows, updated	Candidate
Sales discovery	The same rows, updated	Company
Decision log	The same rows, updated	Decision
Standup log	A new row every meeting	(the meeting)

Tracker templates for freelancers lists every column.

How do you choose in under a minute?

Ask three questions. Will you read a single meeting's row on its own later? Is the question you keep asking "where does it stand now?" Does the thing have a name people say aloud in every meeting that mentions it?

A yes to the first alone means one row per meeting. A yes to the second and third means rows that update, keyed by that name. Two yeses that point different ways usually mean two trackers reading the same meetings. Either way, preview the definition on a recent meeting before saving it, and the rows it proposes usually show whether the shape fits. The hub guide covers scope, columns and review.