Project status across all your clients, in one view that never mixes them

Freelancers and consultants with several projects running at once want one place to see where each stands, without opening six workspaces to find out. This guide is for them. It covers TrackHeros trackers, tables that fill themselves from Google Meet and Microsoft Teams meetings, in their all-clients form: defined once, kept separately for each client, and shown together. It explains why the tables sit side by side but are never merged, and what that protects.

How do you see project status across all your clients?

Create one tracker and scope it to all your clients. TrackHeros keeps a separate table for each client, fills each from that client's meetings, and shows them together on the Trackers page with a client label on every row.

You define the columns once. Take the Project tracker template, with item, description, status, owner, deadline, priority, blockers and last discussed, and every client gets a table with exactly those columns. A client you add next month gets its own table automatically. Your private "No client" space is not included. Which plans include all-clients trackers is on pricing.

How do you set up an all-clients tracker?

Start from a template, from a sentence, or from nothing, then choose all your clients as the meetings that feed it. Five decisions cover it:

1. Columns. The Project tracker template is the usual start. You can also describe the table in a sentence ("every deliverable, its status and who is waiting on it") and edit the draft, or start blank.
2. Scope. All your clients.
3. Preview. Run the definition on one recent meeting before saving, to see what it would record. Nothing is saved by the preview.
4. Review. Changes wait for you by default. You can let confident values apply on their own; removals, conflicts with a kept first value, changes to cells edited by hand and possible duplicates still wait.
5. History. Have it read your recent past meetings in scope, oldest first, so each client's table starts with what has already been said. The editor shows how many it will read.

The column descriptions do most of the work, because they are what decides what goes in each cell. Designing the columns of a meeting tracker covers how to write them.

Why not keep one table for every client?

Because one shared table would eventually put two clients in one row. Two projects that each have a "Login API" are two pieces of work with different owners, dates and blockers, and a row that merges them is wrong for both clients.

The damage would be quiet. The deadline you read is Client B's, the blocker is Client A's, and the quote behind it comes from a meeting the other client never attended. Once that row is pasted into a status email it has also crossed a line you promised each client you would keep.

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. Trackers follow the same rule as notes, transcripts and recordings: every tracker belongs to one client's sealed workspace. The all-clients tracker does not bend that rule. It is one definition, a sealed table per client, and one view that reads across them. Why the workspaces are built that way is on client isolation.

What does the combined view look like?

One list of rows with a client label on each, so every row says whose it is. Two rows can carry the same item name and still be two rows, because they belong to different clients.

Client	Item	Status	Owner	Deadline	Last discussed
Client A	Login API	In progress	Omar	Fri 20 Mar 2026	Tue 17 Mar
A fintech client	Login API	Blocked	Dana	Fri 27 Mar 2026	Wed 18 Mar
A fintech client	Card export	Done	Dana		Mon 16 Mar
Client C	Admin dashboard	In review	Priya	Tue 31 Mar 2026	Thu 19 Mar

The tracker's page has search and filters for rows changed recently, changed several times, with conflicts, or waiting for review. Opening a cell shows its history, and that history holds only the meetings of the row's own client: who said each value, when in the meeting, and the words they used.

Before a client's weekly call, read down that client's rows: the open ones are most of the agenda. The weekly client status meeting guide shows what to do with them.

What happens when two clients use the same name?

They stay two rows. Rows from two clients are never merged, even when the names match exactly, and possible duplicates are only ever looked for inside one client's table.

Within one client, a new name that may mean an existing row, such as "the auth endpoint" next to "Login API", is flagged as a possible match, and you choose: same as, or new row. Nothing is merged on its own even then, and answering same as keeps the new row's history under the existing row. Across clients there is no question to ask, so none is asked. A duplicate inside one client is visible and easy to fix; a merge across two clients would be a leak.

Which meetings fill each client's table?

That client's meetings, each read after its notes are ready. A meeting filed under Client A can only write to Client A's table; it has no route to another client's rows.

A meeting belongs to a client because the calendar it came from does: every connected Google or Microsoft account is bound to one client, as described on connecting several accounts. Meetings held in French, in Spanish or switching between either and English go through the audio pass first and are read once that pass is done, from the same transcript as the notes; the spoken languages TrackHeros recognises are on languages. Very short meetings are skipped, and a tracker reads only meetings its creator could open.

When is a one-client tracker the better choice?

When the clients need different columns, or when only some meetings matter. An all-clients tracker gives every client the same columns, which suits a status overview and little else.

A retainer client whose work is mostly support requests and a build client whose work is features do not fit one set of columns well; give each a tracker of its own. The same goes for a table that should read only one client's standups or interviews: scope it to that client, narrowed to meetings whose title contains "standup" or "interview", or to the recurring meeting itself. The standup tracker guide shows that shape.

Who can see an all-clients tracker?

You, until you share it. A tracker is private to the person who made it, and to the admins of a company account. Who it can be shared with, and what they can then change, is in who can see a tracker.

Can you ask questions across all the tables?

Yes, through the assistant, which reads trackers but cannot change them. In the read-only chat across all clients, "which projects have a deadline before the end of March?" is answered from the tables, and every value comes with its client and the meeting it came from.

Values from different clients are listed side by side, never blended into one narrative, which is the rule for every cross-client read in TrackHeros. The same goes for search across clients, covered in searching across all your clients' meetings. A question that needs one client's whole story belongs in that client's own chat.

What happens to a client's table when the work ends?

Deleting a client deletes its trackers, including its table in an all-clients tracker, with every value and quote it held. The other clients' tables are untouched, because nothing of theirs was ever in it.

Deleting the tracker itself deletes every client's table, and deleting your account deletes everything. What happens to backups is set out in the privacy section of the homepage. If you want the history first, each client's current table and full history download as CSV, one client per file, on the plans listed on pricing. More on what happens to trackers when you delete a client.