How to design the columns of a meeting tracker

A meeting tracker in TrackHeros is a table that fills itself from your meetings: you define the columns, choose which Google Meet and Microsoft Teams calls feed it, and after each one is summarised the rows are filled or updated. This guide is for freelancers, consultants and project leads designing one. It covers what decides whether the table is useful or noisy: each column's description, type and rule, and which column names the row. The feature itself is on Trackers.

What makes a good column in a meeting tracker?

A good column has one job, a name people actually use, and a description that says what counts, what does not and when to leave the cell empty. If two colleagues would fill it differently from the same meeting, the AI will be inconsistent too.

Three tests catch most problems:

• Could it be filled from words spoken aloud? "Hours spent" rarely is. "Estimate given" usually is.
• Is it one thing? "Status and next step" is two columns.
• Would you look it up? A column nobody filters, sorts or reads is width without value.

How do you write a column description?

Write it as an instruction: what belongs, what does not, and when to leave the cell empty. TrackHeros reads the description, not just the name, to decide what goes in each cell, so a one-word description gets one-word judgement.

Column	Weak description	Better description
Deadline	The deadline	The date the item is due, when a date is stated or agreed. Not estimates given as durations.
Owner	Who owns it	The one person said to be responsible for the item. Leave empty if nobody was named.
Status	Status	Where the item stands, only when the meeting says so: started, waiting, being reviewed, done, dropped.
Cost impact	Cost	Extra cost quoted for the change, with its currency. Not the price of work already agreed.

Three phrases do most of the work: "only when…", "not…" and "leave empty if…". They matter because an empty cell is a correct answer. TrackHeros is told to fill only what the meeting actually says and to leave everything else empty. A description that invites inference ("the likely owner") is asking for exactly what the system is built to refuse. More on that in does a tracker guess values that were not said?

The tracker's own description matters too. When a tracker reads every meeting of a client, meetings plainly unrelated to its subject are skipped, and the subject is what you wrote. "Change requests from Client A outside the signed statement of work" skips the social catch-up; "Client A stuff" gives it nothing to judge by.

Which type should each column have?

The type of the thing as it is said aloud: a date for a date, money for a figure with a currency, a status for a fixed set of options, a list for things that come and go. The type decides what the table can sort and compare.

Type	Use it for	Example value
Text	Names, short descriptions, anything in words	"Two sprints, roughly"
Number (with unit)	Counts, hours, percentages	12.5 h
Money	Rates, budgets, quotes: amount and currency	1,200 EUR
Date	Deadlines, go-live dates	17 March 2026
Status	Options you define; some marked as final	Proposed, Agreed, Done
Person	One named owner or contact	Priya
List of people	Interviewers, decision makers, attendees	Tom, Priya
Yes / no / unclear	A question the meeting may or may not settle	Unclear
List	Blockers, strengths, pain points	Staging access; SSO keys
Link	An address for a document or repository	A URL

Two choices trip people up. A number column holds one figure, so a range ("five or six weeks") belongs in text, with "as said" in the description. And "yes / no / unclear" exists because "is this in the original scope?" is often left open, and then the honest value is unclear. The full list, with what each holds, is in what field types can a tracker have?

Which rule should each column follow?

Latest value wins for anything that moves, keep the first value for anything that should not, lists for things raised and resolved, and fill by hand only for what the AI should never touch. The rule decides what happens when a later meeting says something different.

Rule	What it does	Use it for
Latest value wins	The newest meeting's value is current; older ones stay in history	Status, deadline, owner
Keep the first value	A later, different value is shown as a conflict for you	Date first requested, original quote
Lists	Items added when raised, removed when said to be resolved	Blockers, concerns, open questions
Fill by hand only	Never filled by the AI	Your rating, internal notes

Latest value wins is the default, and it loses nothing. Every earlier value stays in the cell's history, and an older meeting read late never overwrites a newer value: it lands in history, labelled as older. Two columns fill themselves: "last discussed" and "meeting date". How disagreements are handled is in what happens when two meetings disagree?

Which column should name the row?

The one people use to refer to the thing: a feature's name, a candidate's full name, a request's short title. It has to be a text, person or link column, and its value should not change over the row's life. This only applies to a table whose rows are updated meeting after meeting; a table with a new row for every meeting has no key.

When a later meeting mentions the same thing, its row is updated rather than duplicated, and the key is how TrackHeros knows. That is why a status or a date makes a poor key: they move. If one column is not enough, as with the same candidate interviewing for two roles, a row can be named by up to three columns together.

Spoken names drift. Differences of capitals or a leading "the" are matched for you; a new name that may mean an existing row, such as "the auth endpoint" for "Login API", is flagged as a possible match and you choose "same as" or "new row". Rows are never merged automatically; you can merge two by hand and both histories are kept. Choosing between the two shapes of table is covered in one row per meeting or one table that updates?

How many columns should a meeting tracker have?

Fewer than you think. Five to eight is plenty for most tables. Every column is a question asked of every meeting; one nearly always empty only makes the table wider.

Start from what you look up. If the question you keep asking is "when is it going live, and who is holding it up?", the columns are item, go-live date, owner and blockers. A "notes" column is the minutes again in a narrower box; the meeting minutes already hold that.

You can add a column later, and change a type without losing values; whether your plan lets you go beyond a template's columns is on pricing. The six templates stay short; tracker templates for freelancers shows each one's columns.

How do you test the columns before saving?

Preview the definition on one recent meeting. It shows what the tracker would take from that meeting, and nothing is saved. Pick a meeting where you already know the answers.

A cell filled with something you would not have written means the description is too loose: add a "not…" line. A cell left empty when the meeting plainly said it means the description is too narrow, or the meeting said it less plainly than you remember. Check the quote before blaming the column.

When the definition is right, create the tracker and have it read your recent past meetings in scope, oldest first, so the table starts with history rather than empty. The editor shows how many it will read.

How does TrackHeros fill the columns after a meeting?

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. After a meeting in a tracker's scope is summarised, it reads that meeting against your columns and fills or updates the rows. Nothing is filled during the call.

Every value cites the transcript lines it came from, and the quote you see is rebuilt from the stored transcript, never written by the model. New and changed values wait for review by default: accept, edit then accept, or reject. Meetings held in French, Hindi or German are read through the same transcript as the notes, and text values are written in the notes' language; the full list is on languages. Every tracker belongs to one client's workspace, and how many you can have is on pricing.